Security Awareness | 22 October 2026
Two critical vulnerabilities in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, were patched on 21 October 2026. Together they are known as PHP2Shell.
Both can allow an unauthenticated remote attacker to run code on a web server, and each was rated CVSS v4.0 9.2. Because the flaws are in PHP core rather than in any one application, a website can be exposed even when its own code is clean. Exploitation attempts were reportedly seen before public disclosure, so patching should not wait.
PHP2Shell is a pair of memory-safety bugs in how PHP handles request-owned data. Both are use-after-free style issues, where PHP keeps using memory after it has been released.
- CVE-2026-109618 (RCE via out-of-memory corruption): when a memory allocation fails, PHP can be interrupted while internal request data is only partly initialized. Request cleanup may then treat the invalid data as valid, leading to memory corruption and code execution.
- CVE-2026-109619 (RCE via stale global state): request-owned internal state can survive after its memory has been freed, and a later request on the same worker may reuse it. Researchers linked this bug to multipart upload progress tracking in the session extension; on PHP 8.5, saved fatal-error backtraces and OPcache state are also involved.
The impact is serious because no login is required, PHP processes the request before any application code runs (so application authentication cannot stop it), and the session upload-progress feature is enabled by default.
Reports describe PHP versions from 5.4 through 8.x as affected. PHP states that all PHP installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php.
PHP published its advisories and fixed releases on 21 October 2026 after details leaked ahead of the planned coordinated disclosure, which forced an accelerated release. Amazon Threat Intelligence reported an exploitation attempt on its honeypot network on 17 October, four days before disclosure. Researchers also warn that fake and malicious "PHP2Shell exploit" tools are circulating, so never run unverified exploit code.
The fix is to update PHP on the server; it cannot be fixed in application code. If you cannot patch immediately, the following only reduce risk and are not a fix:
- Set session.upload_progress.enabled=0 and restart PHP workers. This closes only the confirmed session path of CVE-2026-109619.
- On PHP 8.5, set fatal_error_backtraces=0.
- Limit or filter large multipart POST requests at the web server, reverse proxy or WAF.
- Take internet-facing systems that cannot be fixed offline or isolate them, as the UK NCSC has urged.
Start with the PHP version running on each server. Run php -v on the command line, and remember that the version used by the web server (PHP-FPM or Apache) can differ from the command-line version, so check both. Compare the result with the fixed versions listed below. Distribution packages often carry backported fixes without changing the version number, so also check your vendor’s security notice or changelog for CVE-2026-109618 and CVE-2026-109619.
Confirm that the web server was restarted after the update. A patched package on disk does not protect a worker process that is still running the old code. Finally, look beyond the main website: staging servers, internal tools, admin panels, webmail and control panels often run PHP too and are easy to forget.
Because exploitation attempts were reported before the patch existed, patching alone does not tell you whether a server was already targeted. Treat internet-facing PHP servers that ran vulnerable versions between mid-October and the time you patched as potentially exposed, and work through a short checklist:
- Preserve evidence first: take a snapshot or copy of web server and PHP logs before restarting or rebuilding anything.
- Review access logs for unusual multipart POST requests, repeated worker crashes or out-of-memory errors in the PHP error log.
- Look for recently created or modified PHP files, unfamiliar scheduled jobs and unexpected outbound connections from the web server.
- Rotate database credentials, API keys and any secrets stored in configuration files on the affected host.
- If you find signs of compromise, rebuild from a known-good image rather than cleaning the server in place.
Project: PHP (php-src)
Vulnerabilities: CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state), known as PHP2Shell
Severity: Critical (CVSS v4.0: 9.2 for each)
Affected versions: PHP from the 5.4 era through 8.x, including 8.5.11, 8.4.26, 8.3.35, 8.2.34 and earlier
Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (21 October 2026), or your vendor’s patched packages
Published advisories:
CVE-2026-109618: GHSA-w8hw-w9fx-j79w
CVE-2026-109619: GHSA-6wmf-4rv5-p3rp
- Patch PHP now to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution’s patched packages), and restart PHP-FPM or Apache so the update takes effect.
- Take inventory of every PHP runtime you operate, including containers, third-party images and appliances that bundle PHP. Prioritize internet-facing systems.
- Ask your host to confirm the fix if your provider manages PHP.
- Do not rely on application-layer defenses: logins and WAF rules help, but the bug triggers inside PHP first.
- Plan for end of life: PHP 8.2 reaches end of life on 31 December 2026, and older versions need a vendor backport or an upgrade.
- Hunt for compromise: because attempts predate disclosure, review web logs, check for unexpected PHP files and processes, and rotate secrets on exposed systems.
PHP2Shell shows that critical risk does not always come from application code. A flaw in a language runtime can expose every site built on it, whatever its own security posture. Fast patching, a clear inventory and layered defenses are the best response.
Credit for the discovery and analysis goes to the researchers who worked on these issues and to the PHP maintainers for their rapid response. Always assess systems only with authorization. Users running affected versions should upgrade to a fixed PHP release as soon as possible.
Sources: PHP security advisories; NCSC-NL php2shell repository; Help Net Security; JFrog Security Research; Datadog Security Labs; Sansec; AlmaLinux; ELLIO; Brandefense.
.png)
