PHP2Shell: does your website need a PHP update?
A PHP warning is a reason to check the serving environment. It is not proof that every website is affected or that every owner needs to pay for a repair. Confirm what runs your site and what your host has already patched.
Last updated . Written by Zack Wilde. Prices quoted are Wilde Digital's own published starting rates as of October 22, 2026; they are not market averages.
What happened on October 21, 2026?
The official PHP advisory describes CVE-2026-109618 and CVE-2026-109619, critical flaws that can allow an unauthenticated attacker to execute code. PHP installations serving web requests are in scope; risk is highest for Apache mod_php. PHP-FPM and other serving arrangements also need attention. The PHP Foundation explains the release.
The fixes are in upstream PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Those are the release versions named in this dated advisory, not a recommendation to stay on those exact versions indefinitely. A distribution or hosting vendor may backport the fixes while retaining an older-looking version number.
Does your website actually serve PHP?
WordPress, WooCommerce and many custom applications use PHP. A static website or a JavaScript application does not become affected just because it has a contact form. Inspect the actual application and hosting environment, including separate backends; a page footer or missing PHP header cannot settle the question.
Managed providers may already have acted. Automattic states that its hosted platforms are protected. That does not establish the status of a self-hosted WordPress installation elsewhere. Your provider must confirm your own environment.
What should you ask your hosting provider?
Ask: “Does the PHP runtime serving my website have the fixes for CVE-2026-109618 and CVE-2026-109619? If the displayed version is older than the upstream fixed releases, which vendor package or backport includes them, and have the relevant running workers been restarted?”
Keep the dated response or package evidence. A command-line PHP version can differ from the runtime serving the site; a reassuring public header alone is insufficient. If evidence is unavailable, record the status as unverified rather than guessing that it is safe or vulnerable.
How do you update without breaking the site?
Agree the exact website, hosting environment and important user journeys. Confirm a usable backup and restore path, then test the supported update in staging where available. Prefer maintained upstream or vendor packages, verify the serving runtime after the update, and check relevant forms, logins, checkout and error logs under authorized test arrangements.
A security patch within a supported PHP branch and migration from an obsolete PHP branch are different jobs. Older themes, plugins and custom code may need separate compatibility repairs. Updating WordPress, a theme or a plugin alone does not replace the PHP runtime patch. PHP says temporary mitigations are not a complete fix.
When is paid help useful?
Paid help is useful when patch status is unclear, no one owns the update, or compatibility failures block a supported release. If the host has documented the patch and the website works, additional PHP2Shell remediation may be unnecessary.
Wilde Digital’s PHP assessment is $200 USD fixed assessment for one website on one hosting environment. It delivers findings and next steps, not the patch itself. The fee is credited once toward an agreed repair for that assessed scope; implementation is quoted separately.
Evidence of compromise changes the job. Patching does not prove an attacker has been removed. Forensic investigation, malware removal and recovery need a separate specialist scope; this offer is not a breach-response service.
Common questions
- Can an online scan prove my site is patched?
Not reliably on its own. Headers can be hidden or misleading, and provider backports can retain an older version label. Use authorized access or provider evidence for the actual serving runtime and record what remains unverified.
- Do I need a PHP fix for a static or JavaScript site?
These flaws require an affected PHP runtime. Check for separate PHP backends and integrations before concluding the issue is not applicable. A static or JavaScript frontend alone is not evidence of PHP exposure.
- Is a firewall rule enough?
No. The official PHP advisory says only an update is a complete solution to these vulnerabilities. Temporary mitigations may reduce particular attack paths, but they do not replace patching.
Want this applied to your business?
Send the site and the problem. You get an honest read on what is worth doing first, whether or not it is something Wilde Digital sells.