PHP2Shell: PHP RCE Bug Triggers Millions of Exploit Attempts (CVE-2026-109618)

TL;DR

PHP2Shell is the name researchers and vendors use for a pair of engine-level remote code execution bugs in PHP's request lifecycle.

• Two memory-safety bugs in the PHP engine itself, CVE-2026-109618 (out-of-memory handling corrupts request state) and CVE-2026-109619 (stale global state survives into the next request), let an unauthenticated remote attacker execute code as the web worker. The bugs sit below any application: a clean WordPress, Drupal or Joomla install is exposed the same way.
• Every unpatched PHP installation that serves web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team rates both Critical, CVSS v4.0 9.2, and confirmed complete remote code execution over HTTP against mod_php with default limits.
• Exploit attempts surged within hours of disclosure and reached millions by October 22 (Cloudflare). Amazon's MadPot honeypots saw a first attempt on October 17, four days before disclosure.
• CISA added both flaws to its Known Exploited Vulnerabilities (KEV) catalog on October 26, with a federal patch deadline of October 29.
• On October 24 Adel Karimi confirmed remote code execution against honeypots: "This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process." A public exploit won the StealMyBitcoin challenge on October 25. As of October 27, no compromise of a real-world victim is publicly confirmed (Sophos, Previdian, Wordfence).
• Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now; the KEV listing makes this a deadline. PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 embed affected PHP; Palo Alto Networks has released 11 hotfix lines and expects the rest by October 30. If you cannot update today, the mitigations below only buy time.

Am I affected?

You are affected if both of these hold:

• The installation runs PHP 5.4 or newer and serves web requests through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. CLI-only installations that never parse request bodies are outside the demonstrated paths.
• For PHP 8.2 to 8.5, the version is older than the October 21, 2026 security release for its branch. PHP 7.4, 8.0 and 8.1 are end of life and affected in principle; the security team published minimal source backports for them. PHP 5.4 to 7.3 are also affected in principle, per Sysdig, with no backport from the PHP project.

Even if your application never calls request-body APIs, do not assume you are safe: the confirmed mod_php exploit triggers during request startup, before any application-specific code runs.

Check what you run, on the host and inside every container and CI image:

php -v
php -i | grep -E '^(memory_limit|post_max_size|session.upload_progress.enabled)'
apachectl -M 2>/dev/null | grep -i php      # Apache mod_php loaded?
php-fpm -v                                  # FPM pool version
docker ps --format '{{.Image}}' | sort -u   # images behind running containers
docker exec <container-name> php -v         # PHP inside a running container
docker images | grep php                    # locally pulled PHP image tags

For CI, check the image the pipeline actually builds, for example docker run --rm <registry>/<image>:<tag> php -v.

Palo Alto Networks lists PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 as affected through their embedded PHP. Exposure is through the management plane only: the HTTPS web UI and the XML API. PAN-OS serves these on the management interface, or on any data plane interface with a management profile attached. GlobalProtect portals and gateways, Clientless VPN and the captive portal are not affected.

Eleven hotfix lines are released as of October 27; the full list is in the advisory's table and the Timeline below. The remaining nine lines carry ETAs of October 27 to 30, 2026. Palo Alto rates its own product impact High, CVSS 8.7. Its Cortex XCORE SaaS was affected and remediated on October 21.

The exposure is measured, not estimated. Qualys analyzed anonymized data from 12,000 customers:

• Only 199,000 PHP instances were patched within 12 hours of disclosure.
• Roughly 110 million instances, 71 percent of the PHP instances Qualys measured, run end-of-life PHP 5.4 through 8.1, which will never receive a vendor patch.
• Another 44 million run supported branches whose fixes had not yet been applied.

Censys tracks the internet-facing side of that lag in a public dashboard and counted more than 32.51 million PHP services still running an affected version as of October 27.

How do I fix it?

Update to the fixed release for your branch. Prefer your distribution's packages so the SAPI integrations stay consistent:

# Debian and Ubuntu (upgrades every installed php* package and Apache's mod_php)
sudo apt update
sudo apt install --only-upgrade $(dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2}')
# RHEL, CentOS Stream, Rocky, Alma, Fedora
sudo dnf update 'php*'
# Containers: rebuild on a fixed tag and recreate the service
docker pull php:8.4.27
docker compose build --pull && docker compose up -d

Restart every PHP worker and the web server after the update. If you build from source or run an end-of-life branch, use the security team's 7.4, 8.0 and 8.1 backports, or move to a supported branch.

If you cannot update yet, these measures from the PHP advisory reduce specific attack paths. None of them makes an installation safe, and the advisory says so explicitly.

For CVE-2026-109618, remove the controllable memory limit and shrink the input surface:

; PHP-FPM pool (for example www.conf); php_admin_value stops apps from overriding it
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M   ; use 32M if you need file uploads

With Apache mod_php, set the same values in the Apache configuration:

php_admin_value memory_limit -1
php_admin_value post_max_size 8M

Also:

• Keep upload_max_filesize below post_max_size.
• Enforce limits at the web server or proxy for decoded request size, input field count, multipart part count, header count and nesting depth, including requests without a usable Content-Length.

Do not use RLIMIT_AS or RLIMIT_DATA: forcing mmap() to fail reaches the vulnerable bailout path directly.

For CVE-2026-109619, in php.ini:

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

In a PHP-FPM pool, use the pool syntax instead, then restart the workers:

php_admin_value[session.upload_progress.enabled] = 0
; PHP 8.5 only:
php_admin_value[fatal_error_backtraces] = 0

Three more steps:

• Do not rely on ini_set(), .user.ini, error_reporting, @ or display_errors=Off; the advisory states the consumer runs before those take effect.
• Remove invalid or deprecated INI settings applied per request, and fix attacker-reachable fatal errors and execution timeouts.
• Consider pm.max_requests = 1 if performance allows.

That FPM setting only helps against CVE-2026-109619, because it stops a second request from reaching the same worker; it does nothing against CVE-2026-109618, which is triggered and consumed within a single request.

What is the root cause?

Both bugs are consequences of PHP's bailout mechanism, a longjmp() that aborts a request from deep inside the engine, combined with state that a long-lived worker keeps between requests.

CVE-2026-109618: PHP aborts the request with longjmp() on an out-of-memory (OOM) error. Request memory is sometimes reachable before it is fully initialized. If an allocation fails then, the advisory states, "PHP does not properly account for the early exit and leaves the request memory in an invalid state. The failed allocation does not need to be related to the invalid memory. The request shutdown procedure may then read or branch on it."

An attacker does not need a real memory shortage. Several multipart parsing quirks let one HTTP request exhaust memory_limit on demand:

• A multipart body without a usable Content-Length passes the initial post_max_size check while still feeding data.
• A single part can carry an unrestricted number of headers whose in-memory representation is much larger than the wire format.
• Empty file controls create metadata arrays without counting toward max_file_uploads.

CVE-2026-109619: the worker keeps global state (error, session, object and extension state) that temporarily points into request-owned memory, and must reset it before freeing the request heap. Two failure modes break that reset:

• A fatal error, including memory exhaustion or Maximum execution time exceeded, can abandon an operation before its reset.
• A late nonfatal diagnostic can repopulate cleared error state.

The heap is then freed while the worker's global still refers to it.

Two confirmed consumers read this stale state before the next request initializes:

• Warnings raised while INI settings are applied. With mod_php, .htaccess and Apache php_value run before php_request_startup().
• Session upload progress handling, which reaches session state before ordinary session initialization. It is enabled by default and needs no call to session_start().

How is it exploited?

The CVE-2026-109618 attack is a crafted multipart request that exhausts memory_limit during startup. A failed allocation bails out while request memory is half-initialized, and mod_php's shutdown then reads that invalid state before any application code runs.

A public PoC exists, but it is calibrated to the StealMyBitcoin challenge's Alpine build and aborts on other builds. No publicly released exploit works against production builds out of the box. VulnCheck documents its own chain that does work on production-configured x86-64 systems, described below. Working tooling also exists on attacker infrastructure. The confirmed mod_php path, step by step:

1. The attacker sends a multipart request crafted to exhaust memory_limit during request startup: no usable Content-Length, and a part with a very large header count, or empty file controls that create metadata arrays without counting toward max_file_uploads.
2. An allocation fails and PHP bails out with longjmp() while request memory is half-initialized.
3. mod_php unconditionally runs the request shutdown procedure even though startup failed, so shutdown processes the invalid state, before any application code has run.
4. A strategically arranged heap turns the reads and branches on invalid state into control-flow hijack, and the attacker runs code as the web worker account.

For CVE-2026-109619, the attack needs two requests on the same worker:

• Producer and consumer: a producer request publishes request-owned state and then dies fatally (OOM, timeout, parse failure). A consumer request reaches the stale state before initialization resets it.
• Strongest demonstrated case: a fatal error with fatal_error_backtraces enabled stores backtrace state that shutdown never resets.
• Session path: an upload initializes session and decoder state early, an OOM abandons the reset, and the next request's upload-progress handling consumes the dangling pointers.

Two vendors documented working tooling:

• SOCRadar: a self-described one-click exploit for PHP 8.4.26 under mod_php, found on an exposed attacker server. It recycles the worker, leaks addresses through the session cookie to defeat ASLR, and uses session upload progress to run a shell command. The server also held screening scripts against about 20 sites, none of which met the exploit's preconditions as of October 22.
• VulnCheck: a chain of both CVEs that leaks memory to bypass ASLR and achieves code execution on PHP 8.4.26 on x86-64 with ASLR enabled and display_errors=off, the production-recommended setting. VulnCheck says it knows of no other public or commercial exploit that does the same.

How does the CVE-2026-109618 exploit chain flow?

The OOM-to-code-execution sequence on mod_php, end to end:

What can an attacker do?

Successful exploitation gives unauthenticated remote code execution with the web worker's privileges: reading API keys, database credentials, environment variables and files the worker can reach, and a foothold to move further, as VulnCheck describes. Conditions it needs:

• Network access to the PHP endpoint, nothing else. No authentication, no user interaction.
• The conditions that push CVSS attack complexity to High: a worker that stays alive across requests and, for the OOM path, either a finite memory_limit the attacker can reach or an allocation that can be made to fail.
• Same-worker request pairing for CVE-2026-109619; extra workers and recycling lower reliability but do not remove the condition, per the advisory.

Which vendors are affected?

Products that embed PHP inherit the exposure, and the vendor advisory list has widened sharply. Palo Alto Networks confirmed PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 are affected through embedded PHP. It rates the impact to its own products High, CVSS 8.7, with 11 hotfix lines released as of October 27 and the rest expected October 27 to 30, 2026.

Beyond PAN-OS, advisories naming PHP2Shell impact now cover dozens of vendors, including:

• Network and security: Arista Networks, F5, Huawei, NETGEAR, SonicWall
• Infrastructure and storage: Broadcom, Dell, HPE, IBM, QNAP, Synology, Veeam
• Software and SaaS: Citrix, Ivanti, Okta, Salesforce, Splunk

CMS projects such as Drupal, Craft CMS and WordPress have published advisories too.

On the industrial side, SecurityWeek reports these statuses:

• Schneider Electric patched EcoStruxure Security Expert 1.48.4.0 and its ProLeiT LINEoptimize and EcoStruxure Control Engineering products.
• Siemens listed Ruggedcom APE1808 as affected through its embedded PAN-OS and published an unaffected-product list.
• An ABB manufacturing execution system embedding DokuWiki was flagged.
• B&R listed APROL releases up to R4.4-65 as affected.
• Rockwell Automation and Johnson Controls were still assessing.

If you operate appliances from any of these vendors, patch verification now means checking their advisories, not only your PHP versions.

Why does the fix work?

One commit, 3584a98bda ("Avoid state corruption via bailout", authored October 18, 2026, merged October 21), fixes both CVEs. Its message names the two changes exactly:

- Replace bailout on OOM with UnwindExit
- Properly reset various globals that may be accessed during startup

For the OOM path, the patch removes the longjmp() bailout as the OOM response. A soft OOM is now recorded and deferred to the next VM safe point:

EG(delayed_oom).message = zend_string_init(buf, strlen(buf), /* persistent */ true);
GC_MAKE_PERSISTENT_LOCAL(EG(delayed_oom).message);
zend_string_addref(script_filename);
EG(delayed_oom).filename = script_filename;
EG(delayed_oom).lineno = script_lineno;
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

The shutdown procedure can no longer observe partially initialized state, because OOM is handled at a point where the executor is consistent. The patch also adds a hard memory limit above memory_limit: by default twice memory_limit, or memory_limit plus 1 GiB when the limit exceeds 1 GiB. An allocation that would cross it ends the process at once with _exit() instead of unwinding.

For the stale-state path, the patch resets request-owned globals at the end of each request. Nothing the next request reads before its normal initialization still points into freed memory. For example, the executor shutdown now clears the error and exception state:

/* may be used by zend_error_zstr_at before init_executor */
EG(record_errors) = false;
EG(num_errors) = 0;
EG(errors) = NULL;
EG(error_handling) = EH_NORMAL;
EG(exception) = NULL;

The fix is complete for the demonstrated paths, and the advisory says the wider state reset is preventive: other error, exception, object and extension state families are covered by the reset, but whether they were reachable depends on each application's producers and consumers.

How do I check if I was compromised?

Watch for these five signals in logs and session files. Any of them warrants investigation, and none requires access to application code.

• In web server and PHP-FPM logs: bursts of multipart requests with missing or unusable Content-Length, repeated worker segfaults or OOM kills on requests that never reached application code, and Maximum execution time exceeded on attacker-reachable routes.
• PHP session files containing unexpected code: VulnCheck observed a China-based IP attempting to drop a web shell through server-side session files.
• Session upload-progress fields in multipart requests: the StealMyBitcoin-winning PoC triggers its OOM stage in upload-progress parsing, and observed scanning probes use these fields too. This makes session.upload_progress.enabled = 0 a mitigation with demonstrated relevance.
• Mirai-family follow-on traffic: Sophos tied attempts to the Potassium botnet variant, with connections to 134.199.154.64 on TCP port 50792 and DNS lookups for thunder.godofthunder.st; Wordfence published the source IPs it tracked.
• Environment-variable and credential enumeration from web workers, which several vendors describe as the goal of the scanning wave.

As of October 27, no compromise of a real-world victim is publicly confirmed. The exploitation evidence solidified on October 24 and 26, but the confirmed demonstrations ran against targets configured to be exploitable, not against victims.

Adel Karimi verified complete remote code execution against his single-worker mod_php honeypots on October 24. He reported "an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit's offsets appears in the subsequent execution payload".

The StealMyBitcoin challenge, a deliberately vulnerable PHP 8.4.26 target with a 0.0251 BTC prize, was won on October 25 after 19.28 hours. The public PoC leaks heap and code addresses, defeats ASLR and forges a HashTable to reach zif_system in at most 20 requests. Its offsets are calibrated to the challenge's Alpine build and abort at the code-leak stage on other builds.

Palo Alto Networks' Unit 42 reported on October 25 that a European government entity had been compromised through these flaws, then retracted the attribution the same day. It saw "an attack against a European government agency executed in the context of a vulnerable PHP application" but was "unable to confirm that initial access is associated with the specific PHP2Shell CVEs", the company told The Hacker News.

Timeline

• Since 2012: the vulnerable code paths exist from PHP 5.4 onward, per Sysdig's analysis.
• 2026-10-17: the first exploitation attempt later observed by Amazon's MadPot honeypot network, four days before disclosure.
• 2026-10-20: PHP publishes an advance notice of a critical release scheduled for October 21 at 14:00 UTC, both flaws rated CVSS v4.0 9.2.
• 2026-10-21: PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Previdian records its first exploit attempt at 13:05 UTC; Cloudflare counts tens of thousands of attempts within 45 minutes of publication, and millions by early October 22. Palo Alto Networks publishes its PAN-OS advisory.
• 2026-10-22: The UK confirms 32 digital services taken offline as a precaution and the NCSC issues about 50,000 warnings; Sophos documents a public proof of concept and the Potassium attempts.
• 2026-10-23: SOCRadar documents one-click exploit tooling on an attacker server; Censys counts more than 34.4 million PHP services still vulnerable; PHP publishes an informational advisory for the related, still-unfixed CVE-2026-115560, recommending session.upload_progress.enabled=0 until the next regular release.
• 2026-10-24: Palo Alto Networks updates its advisory with per-branch hotfix ETAs of October 27 to 30; Adel Karimi confirms complete remote code execution against single-worker mod_php honeypots, with a usable memory disclosure and an executed payload derived from the leaked addresses.
• 2026-10-25: This post is first published. Palo Alto Networks releases the first three PAN-OS hotfixes (10.2.18-h13, 11.1.16-h4, 11.2.10-h16); Unit 42 reports, then retracts the same day, a suspected government-entity compromise through these flaws; the StealMyBitcoin challenge, a deliberately vulnerable PHP 8.4.26 target, is won after 19.28 hours by a public ASLR-defeating PoC.
• 2026-10-26: Four more PAN-OS hotfixes are released (11.1.4-h38, 11.1.6-h40, 11.1.10-h36, 11.1.13-h16); CISA adds CVE-2026-109618 and CVE-2026-109619 to its KEV catalog with a federal due date of October 29.
• 2026-10-27: Palo Alto Networks releases 10.2.13-h27, 10.2.16-h12, 12.1.7-h11 and 12.2.4-h1, bringing the released lines to eleven; an oss-security thread shows operators of custom PHP 5.4 to 5.6 builds privately backporting the fix; this post is updated with the KEV listing and the vendor advisory list.

FAQ

Is PHP-FPM as exposed as mod_php?

Both are affected, but differently. mod_php is the confirmed target with no application-specific prerequisites, because it runs request shutdown even after failed startup. FPM exits a child when startup fails, which blocks that exact sequence, but the advisory validates a separate FPM path that publishes state during application execution and consumes it in a later upload-progress request, and source analysis leaves FPM susceptible to the OOM path as well.

Does disabling error display or logging protect me?

No. The advisory is explicit that global state is touched before PHP decides whether to report, display or log a warning, and before error_reporting, @ or display_errors take effect. These settings only change what you see, not what the engine does with stale state.

My site runs clean, up-to-date application code. Am I safe?

No. The bugs are in the engine, so application hygiene does not change exposure. Sysdig notes any WordPress, Drupal or Joomla site is exposed regardless of its code quality, and Censys counted more than 34.4 million PHP services still vulnerable on October 23.

What about the third bug, CVE-2026-115560?

It is real but narrow, and unfixed as of October 27. Exploitation requires an application that sets session.serialize_handler to php_binary or php_serialize in its configuration and switches it back to php at runtime with ini_set() before calling session_start(), with session upload progress still enabled. PHP is fixing it in the next regular release; until then, keep session.upload_progress.enabled=0, which the October 21 advisory already recommended for CVE-2026-109619.

Is there a working exploit in the wild?

Treat the bugs as exploited. CISA added both flaws to its KEV catalog on October 26, its confirmation of active exploitation, and Karimi's honeypots recorded complete RCE on October 24. No compromise of a real-world victim is confirmed yet.

VulnCheck's chain works against production-configured x86-64 systems. The StealMyBitcoin winner targeted a deliberately vulnerable build with calibrated offsets. Read each for what it proves, not as a victim count, and patch on the KEV deadline.

Do I need to patch if PHP is only used for CLI scripts?

The demonstrated attack paths require request-body parsing, so a CLI-only installation is outside them. Update anyway: the fixed versions carry the state-reset hardening, and CLI hosts often gain a web endpoint later.

Inventory your PHP exposure

Use Ostorlab Attack Surface Discovery to inventory the internet-facing domains and hosts you own. Check their PHP versions and appliance advisories against the affected ranges above, including end-of-life branches and embedded PHP, then verify the patches on each instance.

References

• PHP security advisory, "Security advisory: Critical remote code execution vulnerabilities, update now", October 21, 2026, with both CVE descriptions and the incomplete-workaround list: https://www.php.net/archive/2026.php#2026-10-21-5 (checked October 25, 2026)
• GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption", full OOM strategies, SAPI susceptibility and patch description: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w (checked October 25, 2026)
• GHSA-6wmf-4rv5-p3rp, "RCE via stale global state", producer and consumer model, confirmed cases and mitigations: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (checked October 25, 2026)
• CVE-2026-109618 record with the CVSS v4.0 9.2 vector and credits (Ryan at Calif.io, Wiz, OpenAI as reporters; Arnaud Le Blanc, Ilija Tovilo and Jakub Zelenka as remediation developers): https://cveawg.mitre.org/api/cve/CVE-2026-109618 (checked October 25, 2026)
• CVE-2026-109619 record with the CVSS v4.0 9.2 vector: https://cveawg.mitre.org/api/cve/CVE-2026-109619 (checked October 25, 2026)
• Fix commit 3584a98bda, "Avoid state corruption via bailout", replacing the OOM bailout and resetting startup-accessed globals: https://github.com/php/php-src/commit/3584a98bda (checked October 25, 2026)
• PHP informational advisory on session upload progress and CVE-2026-115560, October 23, 2026: https://www.php.net/archive/2026.php#2026-10-23-1 (checked October 25, 2026)
• CISA KEV catalog: CVE-2026-109618 and CVE-2026-109619 added October 26, 2026, due October 29, 2026, with the federal required action and the BOD 26-04 reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked October 27, 2026, via the catalog's JSON feed)
• The Hacker News, "CISA Confirms Active Exploitation of Two PHP2Shell Flaws Enabling Remote Code Execution", October 27, 2026, carrying Karimi's honeypot-RCE quotes, the Censys 32.51 million figure and the widened vendor advisory list: https://thehackernews.com/2026/10/cisa-confirms-active-exploitation-of.html (checked October 27, 2026)
• Adel Karimi's PHP2Shell honeypot evidence reports, including the October 24 confirmed-RCE dataset: https://github.com/0x4D31/honeypot-data (referenced via The Hacker News and SecurityWeek, checked October 27, 2026)
• StealMyBitcoin challenge site, documenting the October 25 win after 19.28 hours and the 0.0251 BTC prize, and the winning public PoC with its stage table and build-calibration caveats: https://stealmybitcoin.com/ and https://github.com/KillaBoi/StealMyBitcoin-PoC (checked October 27, 2026)
• SecurityWeek on industrial vendors checking their products for PHP2Shell, October 26, 2026, with the Schneider, ProLeiT, Siemens Ruggedcom, ABB, B&R, Rockwell and Johnson Controls statuses: https://www.securityweek.com/industrial-vendors-check-their-products-for-php2shell-vulnerabilities/ (referenced via The Hacker News, checked October 27, 2026)
• oss-security thread on privately backported PHP 5.4 to 5.6 patches for CVE-2026-109618, October 27, 2026: https://www.openwall.com/lists/oss-security/2026/10/27/1 (checked October 27, 2026)
• Palo Alto Networks advisory on the impact of CVE-2026-109618 and CVE-2026-109619 on PAN-OS, with eleven hotfix lines released as of the October 27 changelog and the rest ETA'd October 27 to 30: https://security.paloaltonetworks.com/CVE-2026-109618 (checked October 27, 2026)
• The Hacker News carrying Unit 42's October 25 retraction of the government-entity compromise attribution, with the spokesperson statement: https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html (checked October 26, 2026)
• Sophos on the public proof of concept and the unsuccessful Potassium Mirai-variant attempts: https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619 (via The Hacker News, October 23, 2026: https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html, checked October 25, 2026)
• VulnCheck on the ASLR-bypassing exploit chain and the session-file web-shell attempt: https://www.vulncheck.com/blog/php2shell-vulnerabilities (checked October 25, 2026)
• SOCRadar on the one-click mod_php tooling found on an attacker server: https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/ (checked October 25, 2026)
• Previdian telemetry for both CVEs, first event October 21 at 13:05 UTC, no successful RCE observed: https://previdian.com/CVE-2026-109618#telemetry (checked October 25, 2026)
• UK Parliament record confirming 32 digital services unavailable and the NCSC's approximately 50,000 warnings: https://hansard.parliament.uk/Lords/2026-10-22/debates/14CB4C6D-4E16-4377-8FCF-C2CF77BB5CC0/details (checked October 25, 2026)
• Censys count of more than 34.4 million vulnerable PHP services as of October 23, 2026: https://php2shell.censys.com/ (checked October 25, 2026)
• SecurityWeek, "Mirai Botnet Operators Join PHP2Shell Attacks as ASLR Bypass Exploits Emerge", October 23, 2026, carrying Qualys's patching analysis of 12,000 customers (199,000 instances patched within 12 hours; about 110 million instances, 71 percent, on end-of-life PHP 5.4 through 8.1; 44 million more on supported-but-unpatched branches): https://www.securityweek.com/mirai-botnet-operators-join-php2shell-attacks-as-aslr-bypass-exploits-emerge/ (checked October 26, 2026)
• Qualys analysis of the October 2026 critical release: https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities (via SecurityWeek, October 23, 2026)
• Amazon on exploit attempts from October 17 against its MadPot honeypots: https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html (checked October 25, 2026)
• Sysdig on the vulnerable code dating back to PHP 5.4 (2012): https://www.sysdig.com/blog/php2shell-cve-2026-109618-and-cve-2026-109619-detecting-unauthenticated-remote-code-execution-in-php-core (checked October 25, 2026)