Two critical vulnerabilities in the PHP core, collectively referred to as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), were disclosed and patched on 21 October 2026. Both are rated 9.2 (Critical) under CVSS v4.0 and allow unauthenticated remote code execution on affected servers. The flaws exist in PHP itself rather than in any specific application, framework, or plugin, so they affect a wide range of internet-facing PHP deployments.
PHP released fixed versions the same day the details became public: 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older branches (including 7.4, 8.0, and 8.1) received source patches where applicable but are end-of-life and will not receive official binary updates. Exploitation has been observed in the wild.
What the Vulnerabilities Are
The two CVEs stem from memory-safety issues in how PHP handles request setup and cleanup, particularly around multipart form processing and session upload progress tracking (a feature enabled by default).
- CVE-2026-109618 involves out-of-memory conditions during request initialization. When PHP aborts early, subsequent cleanup can treat partially initialized state as valid, enabling memory corruption that can lead to code execution.
- CVE-2026-109619 involves stale internal state that can persist across requests on the same worker after a fatal error. A later request can then interact with freed memory (a use-after-free), again opening a path to remote code execution or information disclosure.
Both issues can be reached without authentication and, in certain configurations (especially Apache with mod_php), before application code runs. PHP-FPM deployments are also affected under some conditions. The vulnerabilities are independent of the application running on top of PHP, so WordPress, Laravel, Drupal, custom applications, and default installations can all be exposed if they use a vulnerable PHP version.
Who Is Affected
Vulnerable versions include:
- PHP 8.2.x before 8.2.35
- PHP 8.3.x before 8.3.36
- PHP 8.4.x before 8.4.27
- PHP 8.5.x before 8.5.12
- Earlier supported versions back to PHP 5.4 in many cases
Any server running an unpatched version and accepting web requests is potentially at risk. Cloud, shared hosting, and self-managed environments are all in scope. Major Linux distributions and repository maintainers (Ubuntu, Debian, AlmaLinux, Remi, and others) have shipped or are shipping patched packages.
Impact and Exploitation Status
Successful exploitation can give an attacker the ability to run arbitrary code as the web-server user. In addition to code execution, the issues can enable memory disclosure that may leak sensitive data such as credentials or keys held in process memory.
Reports from security vendors and researchers indicate that scanning and exploitation attempts began around the time of disclosure (and in at least one case earlier). Amazon, VulnCheck, watchTowr, and others have noted activity. Because the vulnerabilities are pre-authentication and affect core PHP, the window for opportunistic attacks is significant until systems are updated.
Recommended Actions
- Patch immediately. Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (or the corresponding distribution package). This is the only complete fix.
- Verify the running version. Check both the CLI binary and the version used by your web server (Apache mod_php, PHP-FPM, etc.).
- Rotate credentials if exposure is possible. If a server was internet-facing and unpatched during the disclosure window, treat credentials, API keys, and session secrets as potentially compromised and rotate them.
- Monitor for signs of compromise. Review web-server logs for unusual multipart or session-related requests, unexpected process activity, and new or modified files under the web root or temporary directories.
- Apply temporary mitigations only as a bridge. Disabling session.upload_progress or restricting file-upload endpoints can reduce some attack surface, but these steps are incomplete and should not replace patching.
- Inventory and prioritize. Identify all systems running PHP, including containers, serverless functions, and managed hosting environments, and schedule updates according to exposure.
Broader Context
PHP2Shell is notable because it is a core-language vulnerability rather than an application-level flaw. A large percentage of the web still runs PHP, and many installations lag behind current releases. The rapid disclosure-to-patch timeline and the appearance of public discussion and proof-of-concept material underscore the need for organizations to maintain the ability to update PHP quickly.
Official PHP advisories and the security releases are the authoritative source for technical details and fixed versions. Major security research teams (JFrog, VulnCheck, and others) have published high-level analyses that confirm the severity and the availability of patches.
Key takeaways
- CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) are critical unauthenticated remote code execution flaws in PHP core.
- Patches were released on 21 October 2026 for the 8.2, 8.3, 8.4, and 8.5 branches.
- The issues affect PHP itself, so any application running on a vulnerable version can be exposed.
- Immediate upgrading is the primary remediation; credential rotation and monitoring are prudent follow-ups if systems were exposed.
- End-of-life PHP versions will not receive official binary patches and should be upgraded to a supported release.
Organizations running PHP should treat this as a priority patching event. Verify versions, apply the fixed releases, and confirm that internet-facing instances are no longer vulnerable.