Critical PHP Vulnerabilities in October 2026: Is Your Website at Risk?

What happened, and what should you do first?

The PHP security team disclosed two critical runtime vulnerabilities and issued fixes for the maintained 8.2 through 8.5 branches. Remote code execution means an attacker may be able to make the server run code that the site owner never approved. The risk is to the web server and, depending on the application and privileges, potentially to customer accounts or stored information.

If you own a business website, ask your hosting provider which web-serving PHP version is active and whether its build includes both fixes. If the answer is an affected version without a vendor backport, arrange the update urgently. Keep the application, framework and plugins current too, but those updates do not substitute for a PHP runtime fix.

This checklist is local to this page and is not saved or sent anywhere.

Which websites could be affected?

PHP runs behind WordPress, Drupal, Joomla, Laravel applications, custom PHP sites and products that embed PHP. The affected component is the server-side PHP runtime, not any one CMS or plugin. A site needs an actual runtime/version and environment check; using one of these platforms alone does not prove exposure.

PHP identifies web-serving integrations including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Its advisory considers mod_php especially urgent because a demonstrated path can occur before application code executes. Prioritize internet-facing sites and ask vendors about PHP bundled into appliances or managed products.

This is a risk pathway, not a claim that every vulnerable installation was compromised.

What are the two PHP vulnerabilities?

Both issues are in PHP's request lifecycle. A well-written application cannot assume its own validation will prevent every runtime-level attack. The official advisories contain deeper technical details; this guide deliberately omits exploit payloads.

How to check and patch the version serving your site

Look in your hosting control panel's PHP selector or version view, or ask managed-hosting support for the running build. In WordPress, Tools → Site Health → Info → Server can report the site's PHP version. An authorized administrator can inspect the web-server integration, PHP-FPM pool or container image and package changelog. A terminal's php -v may refer to a different CLI binary, so verify the process handling actual web requests. Do not publish a public, unrestricted phpinfo() page to discover it.

PHP 8.1 and older are outside PHP project's current supported branches. Some downstream distributions and long-term-support vendors may supply backports, and PHP published minimal source backports for selected older branches. A version string alone may not reveal a vendor backport: request the vendor's security bulletin or package changelog.

A safe update sequence

1. Identify every PHP runtime, service integration and container serving the website.
2. Coordinate the maintenance window with your host or operations team.
3. Take a backup and verify that restoration is possible.
4. Check application and extension compatibility against the destination release.
5. Install the vendor-supported patched release or documented backport.
6. Restart or replace affected PHP workers and containers.
7. Verify the version or patched package used by live web traffic, not just CLI.
8. Test sign-in, forms, checkout, scheduled jobs and key integrations.
9. Review web, PHP, authentication and endpoint logs.
10. Investigate unusual files, accounts, processes or outbound connections.

A runtime update does not remove malware from a server already compromised. If you have suspicious evidence, use an incident-response process rather than treating a successful version check as a clean bill of health.

How to protect customer accounts and information

Start with evidence. Determine whether application data, account sessions or secrets were actually exposed, rather than assuming either that they were stolen or that no harm occurred. Review user roles and look for unauthorized administrator accounts, changed permissions and unusual access to customer records.

• Accounts: protect administrator access with MFA and review privileged users. If credentials may have been exposed, reset them and rotate relevant service secrets.
• Sessions: invalidate sessions when compromise of session material is credible, then monitor for renewed anomalous sign-ins.
• Data: identify what customer information the site stores and whether logs show access, export or alteration.
• Resilience: keep restorable backups and verify recovery on a trusted system.
• Communication: tell affected users what is known, what remains under investigation and what protective action is appropriate. Assess breach-notification obligations for the relevant jurisdiction and facts; there is no universal response that fits every incident.

If you suspect the site was already compromised

Engage the hosting team and incident responders. Contain affected systems as appropriate while preserving logs, disk evidence and a timeline. Examine unexpected accounts, processes, web files, scheduled jobs and outbound connections; identify the entry point and any persistence. Patch the vulnerable runtime, remove attacker footholds, rotate exposed secrets, then validate recovery from a trusted state. Determine whether customer information was accessed or modified and follow applicable reporting requirements.

Do not destroy evidence by repeatedly reinstalling components before the incident team has captured what it needs. Likewise, do not announce a confirmed breach solely because an affected PHP version appeared in an inventory.

Hardening beyond this incident

The emergency action is the PHP security update. Longer-term controls make future vulnerabilities less damaging but are not substitutes for the two CVE fixes.

The OWASP Cheat Sheet Series is a useful reference for these defense-in-depth practices.