PHP Security Updates and Vulnerability Fixes
Get help checking your website’s PHP patch status, planning the right update with your host, and testing the functions your business depends on. For business websites, WordPress and WooCommerce stores, agencies with several sites, and older custom PHP applications.
Scope: patch-status checks, update planning, host coordination, the update itself within an agreed scope, runtime verification, functional testing and a written summary. Malware cleanup and forensic investigation are separate. What is and is not included
What this means for your website
PHP is the software on your web server that runs your site’s code. It sits underneath WordPress, WooCommerce and many custom applications, and it is part of the hosting environment, not part of the site itself.
The hosting environment decides it.
The same site can be patched on one server and not on another. What matters is the PHP build your host runs for you.
A site that works can still need the update.
These vulnerabilities do not make a site look broken. A normal-looking site tells you nothing about patch status.
Your host may already have fixed it.
Linux distributions got the fixes in advance and many hosts patch for their customers. It is worth confirming, not assuming.
Updating the site and updating PHP are different jobs.
Updating WordPress, plugins or themes does not change the PHP runtime, and the reverse is also true.
To check it yourself, see how to check whether a PHP security update was applied.
Can you help with my type of website?
Probably, if it runs on PHP. These are the setups we work with; if yours is unusual, tell us and we will say plainly whether it fits.
WordPress and WooCommerce
Core, plugins, themes and checkout tested around the PHP change.
Other PHP CMS and ecommerce
Drupal, Joomla, Magento and other PHP platforms.
Laravel, Symfony and custom PHP
Code and dependency review against the target PHP version.
Managed and shared hosting
We work through your host, who usually applies the PHP fix.
VPS, dedicated and cloud servers
Server-level work: PHP packages, PHP-FPM and web server configuration, done by us or alongside your administrator.
Several sites or hosts
One inventory across sites, prioritized by exposure and importance.
Four ways an engagement can start
Patch-status and scope assessment
We find out which PHP build serves each site, whether it carries the fix, what your host has done, and what else is needed. You get a written answer and a scoped plan. Sometimes the answer is that your host has it covered.
Patching or upgrade implementation
The update itself: coordinated with your host or applied on a server you control, with backup, runtime verification, the agreed tests and a written summary.
Compatibility repair or legacy migration
Fixing plugins, themes or custom code that fail on a supported PHP version, or moving an older application onto one.
Full conversion to a custom build
When patching or upgrading an old platform is no longer worth it, we rebuild the site or application in custom code, keeping the URLs that earn traffic.
Unsure which you need? The PHP update planning guide walks through patch, upgrade or escalate, with a scoping worksheet. For full rebuilds, see how we migrate sites to custom code.
Which situation fits your website?
Choose the closest one. This is a self-reported checklist to point you to the right next step. It is not a scanner, and nothing is checked on your website.
Pick the option closest to your situation to see what it usually involves.
What the service includes
Specific deliverables, agreed in writing before work starts.
- Environment and runtime reviewWhich host, operating system, control panel and PHP build actually serve your site, and who controls each one.
- Hosting coordinationWe talk to your host or server administrator where the fix is theirs to apply, and get the confirmation in writing.
- Compatibility planningYour plugins, theme, extensions and custom code checked against the PHP version you are moving to.
- Backup and recovery planA current backup confirmed before anything changes, and a written plan for what happens if the change misbehaves.
- The update itself, within the agreed scopeA package update, a version switch in your control panel, or code fixes that a newer PHP version needs.
- Runtime verificationConfirmation that the patched build is the one serving web requests, with workers restarted, not just installed on disk.
- Functional testingThe business functions we agree on up front, checked before and after the change.
- Written completion summaryWhat was changed, how it was verified, what was tested, and what is still open.
Not included unless scoped separately
If your situation needs any of these, we will tell you plainly, and either scope the work separately or recommend a specialist.
- Malware cleanup. Removing files or code an attacker left behind.
- Forensic investigation. Working out whether, when and how a site was compromised.
- Full custom rebuilds. Converting a site or application to custom code is its own engagement (type D above), quoted separately.
- Hosting migrations. Moving to a new host or server when the current one cannot provide a patched PHP.
- Unsupported legacy remediation. Keeping PHP 7.x or older running safely while a replacement is built.
- Continuous monitoring. Ongoing watching of the site after the engagement ends.
How the work proceeds
Six steps, in order. Nothing changes on your server until steps 1 to 3 are agreed.
Step 1: Review the website and hosting situation
You tell us the site, the host and what prompted the request. We work out what runs where and who can change it.
Step 2: Confirm access, scope and patch requirements
We agree what is in scope, what access is needed and how it will be shared, and which PHP build the site needs to reach.
Step 3: Prepare the change and the recovery plan
Backup confirmed, compatibility checked, test list agreed, and a change window chosen with you.
Step 4: Apply the appropriate fix
Your host updates the packages, we switch the version in your control panel, or we make the code changes, depending on the setup.
Step 5: Verify the runtime and critical workflows
We confirm the patched build is serving requests, then run the agreed checks on forms, logins, checkout and anything else on the list.
Step 6: Provide documented results
You receive the written summary, including anything we could not verify and what we recommend next.
Timing. How long it takes depends on how quickly hosting access is arranged, how compatible your site is with the patched PHP, and the scope agreed. We give you a realistic plan after step 2. We plan changes to keep disruption low, but we do not promise zero downtime.
Ready to start with step 1?
Request PHP Security HelpWill this break my website?
Any change to a server carries some risk, and nobody can honestly promise otherwise. What reduces the uncertainty is checking compatibility before the change and testing the functions that matter right after it.
A security patch within the same PHP branch, for example moving from an older 8.3 build to a patched 8.3 build, is usually a smaller change than moving to a new branch. A branch upgrade is where older plugins and custom code tend to fail. We plan accordingly; see PHP version upgrades.
Before work starts we agree a test list with you. Every engagement does not automatically include every check. We pick the ones your business actually depends on.
Checks we commonly agree on
- Contact forms send and arrive
- Login and account access
- Checkout and payment workflows
- Booking and scheduling systems
- Site search
- File uploads
- Transactional email
- Scheduled jobs (cron)
- Integrations such as CRMs, shipping and payment gateways
PHP update, WordPress update and incident investigation
Three different jobs that are easy to confuse. Each answers a different question.
| Aspect | PHP runtime update | WordPress or application update | Incident investigation |
|---|---|---|---|
| What it changes | The PHP runtime on the server: the engine that runs your site’s code. | WordPress core, plugins, themes or your application’s own code. | Nothing at first. It examines logs, files and accounts to find out what happened. |
| Who usually does it | Your host on managed hosting; whoever administers the server on a VPS or dedicated server. | The site owner, a developer or an agency. | An incident-response specialist, working with your host. |
| Fixes the October 2026 PHP vulnerabilities | Yes, when the patched build is installed and the PHP workers are restarted. | No. WordPress has said no WordPress update is required or planned for these issues. | No. It looks for what may already have happened. |
| What it does not show | Whether the site was compromised before the patch was applied. | Which PHP build the server runs. | It does not patch anything by itself. |
WordPress statement: WordPress.org, October 21, 2026. More in does updating WordPress update PHP?
Who does the work, and how you can check us
We do not show client testimonials here. Our published client work is web development and search, and praise for a website build would not tell you anything about patching. This is what you can check instead.
The person responsible
Webvello was founded in 2024 by George Shvaya, who came to web work from IT networking and information security and studied Cybersecurity and Information Assurance at Western Governors University.
How we handle access
- We never ask for passwords in a web form or plain email.
- We ask for the least access the agreed work needs, ideally a separate account your host or CMS lets you create and remove.
- Access is arranged after the scope is agreed, and we ask you to remove it when the work is done.
- We do not scan or test your website from the inquiry form, and we never test attacks against it.
Real contact details
2281 Lava Ridge Ct, Roseville, CA 95661
(530) 553-8883 · hello@webvello.com
Mon-Fri: 9AM-6PM PST
PHP update completion summary
Sample structure, not a client record- Scope agreed
- [Sites and environments covered, and anything excluded]
- Environment
- [Host, operating system, control panel, how PHP serves the site (for example PHP-FPM or Apache module)]
- Before
- [PHP branch and package build serving web requests, with the source of that information]
- Change made
- [Package update by host / version switch / code fix, who made it, date and window]
- After
- [Package build now serving web requests, confirmed by the host’s package record and a runtime check]
- Worker restart
- [Confirmation that PHP workers were restarted or reloaded after the update]
- Business checks
- [Agreed list, for example: contact form sends, login works, test checkout completes, scheduled jobs ran]
- Backup
- [Backup taken before the change, where it is stored, and that a restore was possible]
- Not covered
- [What this work does not show, for example whether the site was compromised before the patch]
- Open items
- [Anything outstanding, with owner and suggested next step]
Common questions
How do I know whether my website uses PHP?
If your site runs on WordPress, WooCommerce, Drupal, Joomla or Magento, it uses PHP. Many custom business sites and shared-hosting sites do too. Your host’s control panel usually shows a PHP version setting. If you are not sure, send us the address and the host’s name and we will find out through the host and the site’s admin area.
Does updating WordPress fix this issue?
No. The October 2026 vulnerabilities are in PHP itself, which runs underneath WordPress. WordPress said no WordPress update is required or planned for them. You still need a patched PHP build from your host or server administrator, and you should keep WordPress, plugins and themes updated for their own fixes.
Has my hosting company already handled it?
Possibly. Many hosts patch PHP for their customers, and Linux distributions received the fixes in advance. Confirm it in writing rather than assuming. Ask your host whether the PHP build serving your site includes the fixes for CVE-2026-109618 and CVE-2026-109619, and whether the PHP workers were restarted afterward.
Can you help if I do not know my PHP version?
Yes. Most people do not know it, and the version number alone is not enough anyway, because Linux vendors often fix older-numbered packages. We find out which build serves your site and whether it includes the fix.
Can a PHP upgrade affect my plugins or theme?
It can. Moving to a newer PHP branch can expose plugins, themes or custom code that rely on behavior the new version changed or removed. A security patch within the same branch is usually lower risk than a branch upgrade, but it is still tested. That is why we check compatibility first and test the important functions before and after.
Can you help with an older custom application?
Often, yes. We review the code and the server, check whether a vendor-supported patched package exists for the PHP version it runs on, and set out the options: a backported package, a supported upgrade path, or code changes. If the application cannot run on any patched PHP, we explain what that means and how to limit exposure while a longer fix is planned.
What access is required?
It depends on the setup. Typically this means hosting control panel access or a contact at your host, an admin account on the site for testing, and sometimes server access. We agree what is needed before work starts and arrange it securely with the least access required. Never send passwords through this form or by plain email.
Can you work with our current developer or host?
Yes. On managed hosting the host usually applies the PHP fix, and our job is to coordinate, verify and test. If you already have a developer, we can handle the PHP side and hand them the compatibility findings.
What if we suspect the website has already been compromised?
Tell us when you get in touch. Do not delete files or restore a backup yet, because that can destroy the evidence needed to understand what happened. Ask your host to preserve logs. Patching closes the vulnerability but does not remove anything an attacker left behind. Investigation and cleanup are scoped separately from routine patching, and we will tell you plainly who should do them.
How is pricing determined?
By scope: how many sites, who controls the servers, how far the PHP version has to move, and how much testing your business functions need. We quote after we understand the situation and before any work starts. The quote states what is included and what is not. The planning guide lists the factors in detail.
How do you verify the work?
Two ways. First, the runtime: the host’s or vendor’s package record for the patched build, plus a check that this build is the one serving web requests after the workers restarted. Second, the business: the agreed functional checks run before and after the change. Both go into the written summary.
Can you help with multiple websites?
Yes. For agencies and portfolio owners we start with an inventory of sites, hosts, PHP builds and who controls each server, then sort them by exposure and business importance so the most important work happens first.
Need help understanding what your website requires?
Share your website address and what your host has told you. We will review the scope and discuss the next step with you.
What we need from you
Only your name, email and the website address. Platform, host and PHP version help if you know them; “not sure” is fine. No passwords or access details at this stage.
What happens after you submit
- A person on our team reads it and replies by email, with any questions.
- If it is a fit, a short call about your hosting, your site and what must keep working.
- A written scope and quote, stating what is included and what is not. Nothing changes on your site until you approve it.
Prefer to talk first? Book a Free Call, or phone (530) 553-8883.