PHP2Shell (CVE-2026-109618, CVE-2026-109619): critical RCE, exploited in the wild. Fixed in 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Read the advisory
Security advisory · PHP engine

PHP2Shell: two critical remote code execution flaws in the PHP engine, fixed 21 October 2026.

Critical CVSS 9.2 · v4.0 CVE-2026-109618 CVE-2026-109619 Exploited in the wild

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution as the web-server account. The PHP project calls them out together as a single advisory; this toolkit tracks them as PHP2Shell. A working, unauthenticated exploit against Apache mod_php with default settings has been demonstrated. There is no complete configuration mitigation — updating is the only safe choice.

Fixed releases

8.5.12 8.4.27 8.3.36 8.2.35
Check your PHP version Patch playbooks

Sources: php.net release archive (2026), GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.

What happened

On 20 October 2026 the PHP project published advance notice of a critical security release, scheduled for 21 October 2026 at 14:00 UTC. The release shipped on schedule and fixes two independent memory-safety defects in the PHP engine. Both are reachable before any application code runs, both are rated CVSS v4.0 9.2 (critical), and both can lead to remote code execution by an unauthenticated attacker. The flaws have existed since PHP 5.4.0.

The two bugs are described in plain language below, at the level of detail the official advisories give. This page contains no exploit code, proof-of-concept, or trigger recipe.

Loading advisory detail… If this does not populate, see the official advisories linked above.

Are you affected?

Almost certainly, if you serve web requests with PHP older than the fixed releases. The vulnerable code paths run during request start-up and multipart request parsing, so they do not depend on your application’s code. Every server-side PHP engine (SAPI) that handles web requests should be treated as affected until patched.

Apache mod_php is the highest risk.

Both advisories confirm a working remote-code-execution exploit against mod_php with default settings, because directory-level .htaccess and php_value/php_flag directives are applied before request start-up. PHP-FPM, FrankenPHP, LiteSpeed (LSAPI) and php-cgi are affected or treated as affected — see the per-SAPI breakdown below.

Quick check

Is your PHP version patched?

Type the version from php -v (for example 8.3.12). This runs entirely in your browser against Shellproof’s php.net data — nothing is sent anywhere.

Run the full checker on /check for php.ini, composer.lock, webshell and exposed-key scans — all local to your machine.

Attack surface by SAPI

How each PHP server API is exposed, taken directly from the two advisories. “Highest” means a complete exploit has been demonstrated; “high” means affected or treated as affected without a complete public demonstration.

Loading per-SAPI risk tables…

What to do now

  1. 1. Update — this is the only complete fix

    Move every PHP install that serves web requests to its branch’s fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The PHP project is explicit that configuration changes are not a substitute. Linux distributions and LTS vendors received the patches in advance, so your vendor package may already carry the fix under its own version string.

    Open the patch playbooks for exact, copy-pasteable upgrade commands for your platform (Ubuntu/Debian, RHEL family, Alpine, Docker, cPanel, Plesk, Homebrew, Windows and more).

  2. 2. If you genuinely cannot update yet, apply interim mitigations

    These reduce exposure. They do not make the install safe.

    The advisories state plainly that there are no complete mitigations and that updating is the only safe choice. Apply these only to buy time, and remove them once patched (except settings you have no reason to keep on).

    Set these administratively so applications cannot override them — use php_admin_value/php_admin_flag in the FPM pool or php_admin_value in the Apache config, not ini_set() or .user.ini — then restart every worker (next step).

    Interim php.ini mitigations
    ; Set administratively, then restart every worker.
; These reduce exposure; they do NOT make the install safe.
session.upload_progress.enabled=0
fatal_error_backtraces=0        ; PHP 8.5 only
memory_limit=-1
post_max_size=8M
max_input_nesting_level=16

  3. 3. Restart every worker

    A running PHP worker keeps the old engine in memory. Neither the patch nor an interim php_admin_* setting takes effect until the process restarts. Reload or restart PHP-FPM, Apache (mod_php), FrankenPHP, LiteSpeed lsphp and any long-running php-cgi pools. Shellproof’s CLI flags workers that started before the current PHP binary as HOST-STALE-WORKER findings.

  4. 4. Rotate secrets that the worker could have leaked

    CVE-2026-109619 can disclose memory from a web worker, so treat secrets that lived in that worker’s process as potentially exposed on any unpatched, internet-facing server: application and framework keys (APP_KEY), database and cache credentials, API tokens, session secrets, and any private keys or wallet material handled in-process. Rotate them after patching and restarting.

    If you operate Solana or other crypto keys from a PHP host, the crypto & Solana guide covers finding exposed keys and checking whether a hot wallet has moved funds.

  5. 5. Scan for signs of compromise

    Because a demonstrated exploit yields code execution as the web account, assume an unpatched, exposed server may already have been touched. Scan your document roots for webshells, PHP inside upload directories, modified WordPress core files and exposed keys with the local checkers or the CLI (shellproof scan). Everything runs on your own machine; nothing is uploaded.

Timeline

Only events stated in the official sources. Times are UTC where the source gives them.

  • Advance notice published.

    The PHP project announced an upcoming critical security release addressing two vulnerabilities, both rated CVSS v4.0 9.2, and reserved the right to release earlier if either flaw became public or evidence of active exploitation appeared.

  • Scheduled release time.

    The release was scheduled for Wednesday 21 October 2026 at 14:00 UTC.

  • PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released.

    The security releases ship, fixing CVE-2026-109618 and CVE-2026-109619. The advisory states a working unauthenticated exploit against mod_php was demonstrated and urges all users to update immediately. PHP 8.1 and older receive no official release.

Frequently asked

I’m on PHP 8.1 or 7.x. Is there a fix for me?

No official release. PHP 8.1 reached its security end-of-life on 31 December 2025, and 7.x is long past it; the security releases cover only 8.2, 8.3, 8.4 and 8.5. The advisory notes that some distributions and LTS vendors provide backported fixes, so contact your vendor — but the durable answer is to upgrade to a supported branch. The PHP project also published minimal source backports for 7.4, 8.0 and 8.1, which some vendors ship.

My distro still shows an old version number. Am I unpatched?

Not necessarily. The advisory says Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. Distributions routinely apply security fixes without changing the upstream version string, so php -v alone can understate how patched a binary is. Shellproof’s CLI runtime check reads the vendor package changelog for the CVE IDs to confirm whether the fix is actually present — the version string on its own is not proof either way.

I use the Remi repository. Can I just update from there?

Not on release day. The advisory states that the volunteer-maintained rpms.remirepo.net would not have updates available on the release date, and urges operators who rely on it to switch to distribution packages or build from source so they can apply the fix immediately. Check the repository’s current status before relying on it.

How do I verify I’m patched after updating?

The official sources list the fixed versions but do not prescribe a verification procedure; the steps below are Shellproof’s recommendation. Run php -v on every SAPI binary and confirm it is at or above the fixed release for its branch (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35). On a distribution package whose version string did not change, confirm the fix in the vendor changelog instead — shellproof scan does this automatically. Finally, confirm every worker has actually restarted, since the old engine stays resident until it does. A patched binary behind a worker that never restarted is still running vulnerable code.

Should I rely on RLIMIT_AS, a cgroup memory cap, or a container limit?

No. The advisory for CVE-2026-109618 explicitly says not to use RLIMIT_AS or RLIMIT_DATA: making allocations fail drives PHP down the vulnerable out-of-memory path. A container or cgroup memory.max limit is an availability boundary only, not a security mitigation.

References

Shellproof is independent and not affiliated with the PHP Group. Every factual claim on this page is drawn from the sources above and from Shellproof’s curated advisory data (browse the data). Vulnerability data from php.net.