CVE-2026-109618 & CVE-2026-109619: PHP2Shell Unauthenticated PHP RCE (CVSS 9.2)

This week in our InSEKurity of the Week series: not a bug in a product that runs on PHP, but a bug in PHP itself. On October 21, 2026, the PHP project shipped emergency releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, which researchers chained into an exploit called PHP2Shell. Both score CVSS 4.0 9.2, both are reachable without authentication, and the PHP security team describes the result in one line: unauthenticated remote code execution with the privileges of the web worker.

The detail that makes this different from the usual “critical RCE in a web app” is where the bug lives. Both flaws sit in the interpreter’s request lifecycle — in how PHP handles running out of memory, and in what state a worker carries from one request into the next. On Apache with mod_php, PHP confirmed an exploit path where the malicious request does its work before any application code runs. Your login page, your framework’s CSRF check and your carefully reviewed controllers are never consulted. If the server parses the request, the server is in scope.

And the disclosure did not go to plan. The CVE IDs leaked on October 20, PHP pulled its release forward by a day, Cloudflare had WAF rules live hours before the patch, and honeypot operators reported exploitation attempts before the fixed tarballs were on php.net. Public proof-of-concept code turned out to be far less reliable than the headlines — but “hard to weaponize reliably” is a statement about this week’s PoCs, not about next week’s.

🚨 Summary

CVE IDs: CVE-2026-109618 (“RCE via OOM corruption”) and CVE-2026-109619 (“RCE via stale global state”), together known as PHP2Shell
CVSS 4.0 Score: 9.2 Critical for both (scored by the PHP security team), vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Other ratings: Red Hat rates the issue Important (CVSS 3.1 8.1); Red Hat notes NVD scores it 9.8
CWE: CWE-416: Use After Free, CWE-755: Improper Handling of Exceptional Conditions, CWE-824: Access of Uninitialized Pointer, CWE-1325, CWE-1419
Vendor Advisories: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, published 2026-10-21
Affected Software: PHP below 8.2.35, 8.3.36, 8.4.27 and 8.5.12; all of 7.4, 8.0 and 8.1 (no official release, source backports only); the vulnerable code path dates back to PHP 5.4.0 (2012)
Affected SAPIs: Everything that serves HTTP — Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php
Attack Vector: Network — a crafted multipart/form-data request to any PHP endpoint
Authentication Required: None. Application-level authentication does not help, because PHP processes the malicious request before the application does
Impact: Remote code execution as the web worker user (e.g. www-data), plus memory disclosure of other requests’ data
Patch Status: Available for 8.2-8.5; Linux distributions and LTS vendors received patches in advance and ship backports that often keep the old upstream version number
Workarounds: PHP published configuration changes that reduce exposure but do not make an installation safe
Exploitation Status: Exploitation attempts observed in the wild (Amazon, Cloudflare, watchTowr), including one attempt four days before disclosure. Public PoCs are reported to work only against narrow OS / PHP / web-server combinations
CISA KEV: Not listed (checked against KEV catalog version 2026.10.23). CISA issued an alert on 2026-10-21 urging immediate patching

🖥️ What is PHP?

PHP is the server-side scripting language behind a very large share of the web. It is not one product you can find on an asset list — it is a runtime embedded in other products: WordPress, Drupal, Joomla, Magento/Adobe Commerce, Shopware, WooCommerce, Nextcloud, MediaWiki, Roundcube, phpMyAdmin, WHMCS, and every in-house Laravel or Symfony application. Wiz headlined its write-up on these bugs as affecting “70% of the Internet”; Palo Alto Networks’ Cortex Xpanse counted more than 22.6 million exposed instances that may be vulnerable.

PHP runs inside a web server in one of a handful of ways, called SAPIs. With mod_php, the interpreter is loaded into every Apache worker process. With PHP-FPM, a separate pool of long-lived worker processes receives requests from nginx or Apache over FastCGI. FrankenPHP and LiteSpeed (LSAPI) are newer alternatives. All of them share one property that matters here: a worker process does not start fresh for each request — it handles hundreds or thousands of requests in sequence and resets its internal state in between.

Typical Use Cases

Content management systems and corporate websites (WordPress, Drupal, Joomla, TYPO3)
E-commerce platforms handling customer and payment data (Magento/Adobe Commerce, Shopware, WooCommerce)
Collaboration and file-sharing platforms (Nextcloud) and webmail (Roundcube)
Hosting control panels and billing systems (Plesk, WHMCS) and admin tools (phpMyAdmin)
Custom business applications built on Laravel, Symfony and similar frameworks

Why an Engine Bug Is Different

When a CMS plugin has an RCE, you patch the plugin. When the interpreter has one, every application on that interpreter is exposed at once — including ones whose code is perfectly clean. Researchers at Calif reported unauthenticated code execution against stock installs of Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. The vulnerable code also hides in places that never show up as “PHP” in an inventory: container images, appliances, and applications that ship their own bundled interpreter.

🔍 Technical Analysis

Vulnerability Description

PHP handles certain fatal conditions — most importantly running out of memory — by aborting the current operation with longjmp() and jumping straight to request cleanup. That is fast and simple, but it means an operation can be abandoned halfway. PHP2Shell abuses two consequences of this design:

CVE-2026-109618 — RCE via OOM corruption. If PHP hits its memory limit while internal request data is only partially initialized, request cleanup later treats the half-built data as valid.
CVE-2026-109619 — RCE via stale global state. Request-owned state that lives in worker-wide globals can survive after its backing memory has been freed. A later request handled by the same worker may use that stale pointer before normal initialization resets it — a cross-request use-after-free.

Both can be triggered by a crafted multipart/form-data request — the same request type every HTML upload form sends.

Root Cause Analysis

Counters updated before the allocation that can fail (CVE-2026-109618). Datadog Security Labs traced the reference case to hash-table insertion in _zend_hash_str_add_or_update_i() (Zend/zend_hash.c), used while PHP converts form fields into $_POST. The function increments the table’s element counters before allocating the new key. If that allocation exceeds memory_limit, PHP raises a fatal error and abandons the insertion — leaving a counted bucket whose key and value were never written.
Cleanup trusts what it finds. At request shutdown, PHP destroys $_POST by visiting every counted bucket and interpreting its contents as a PHP value. The uninitialized bucket contains whatever was left in that memory — which an attacker can influence through heap grooming.
Limits do not stop the OOM. The advisory lists several multipart parsing behaviours that push a request into out-of-memory while staying within apparent limits: a missing or unusable Content-Length, unlimited headers per part, and empty file controls that do not count against max_file_uploads but still create metadata arrays. Nested field names such as files[a][b][c] reach the vulnerable string-key path.
mod_php runs cleanup even after startup failed. Under Apache mod_php, shutdown runs even when request startup failed, so the corruption is reachable before any application code executes. PHP-FPM kills the child when startup fails, which blocks that particular sequence — PHP considers FPM susceptible via other paths but reports no complete FPM exploit for this CVE.
State that outlives its request (CVE-2026-109619). Error, session, object and extension state kept in globals is not always reset before the request heap is freed. A fatal error (OOM, execution timeout, failed require, uncaught error) can abandon an operation before its reset runs; late shutdown diagnostics can even repopulate error state after it was cleared. A later request on the same worker then reads freed memory. PHP confirmed two consumers: PHP 8.5’s fatal_error_backtraces (on by default, confirmed RCE on mod_php) and session upload progress (on by default, works even without session_start(), confirmed RCE on mod_php and PHP-FPM).

The pattern underneath both CVEs is the same: an error path that leaves the process in a state the normal path never expected, followed by code that assumes the normal path ran. The fix replaces the immediate longjmp() on OOM with a soft limit that defers the error to the next safe point, plus a hard limit that terminates the worker with _exit() instead of running cleanup — and resets request-owned global state earlier.

Attack Vector

The public research describes three stages. The request below shows the shape Datadog documented for detection purposes — it is not an exploit:

# ILLUSTRATIVE ONLY -- request SHAPE for detection and log review.
# Based on Datadog Security Labs' description of public PoCs; NOT a functional exploit.
# The signals: a multipart body that uses PHP_SESSION_UPLOAD_PROGRESS, hundreds of
# parts, deeply nested machine-generated field names, and oversized fill values.

POST /index.php HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----XYZ
Cookie: PHPSESSID=<attacker-chosen value>

------XYZ
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"

x
------XYZ
Content-Disposition: form-data; name="files[R00001][a][a][a]"

<filler>
------XYZ
... (~900 further parts in under 1 MB, until memory_limit is exhausted)

Reach the interrupted operation. A crafted request drives PHP into an allocation failure during request initialization, before the target script runs.
Control the leftover memory. Heap grooming shapes what the abandoned bucket or the stale pointer refers to. Wiz described a memory-disclosure technique that leaks heap data back in the PHPSESSID response cookie, which supplies the addresses needed to defeat ASLR.
Turn cleanup into code execution. Shutdown cleanup is redirected into a shell command call, which runs as the web worker user. In Datadog’s lab (mod_php, Apache prefork, memory_limit=16M) the full chain completed in about 3.1 seconds, could return an ordinary HTTP 200, and did not need to crash the worker.

Multiple workers lower the success rate per request, because the attacker’s follow-up must land on the same worker — but they do not remove the condition.

Exploitation in the Wild

2026-10-17 — Amazon Threat Intelligence observed an exploitation attempt against its MadPot honeypot network, four days before public disclosure.
2026-10-20 — The CVE IDs and details leaked on social media ahead of the planned 22 October disclosure; watchTowr publicly confirmed the bugs were real.
2026-10-21, 03:02 UTC — Cloudflare’s WAF rules were blocking exploit attempts, about nine hours before the patch was published; Cloudflare reported “early attacks emerging” from 07:43 UTC.
2026-10-21 — watchTowr reported exploitation attempts against both CVEs in its Attacker Eye honeypot network; Amazon reported further attempts from what appeared to be multiple actors.
Reliability is the open question. The PHP security team said it “did not identify any functional exploits” among the PoCs at disclosure. Rapid7 found each public PoC worked only for a specific OS / PHP / web-server combination; a researcher cited by Sansec found most needed a separate local file inclusion bug in the target. Tenable warns that some circulating “exploit” code is itself laced with malware.
2026-10-25 — Unit 42 retracted an earlier update linking a government intrusion to PHP2Shell; it could not confirm the initial access vector.
No CISA KEV listing as of catalog version 2026.10.23, and no confirmed public compromise attributed to these CVEs at the time of writing.

Post-Exploitation Impact

Code execution as the web worker (www-data, apache, nginx) — enough to read every file the application can read, including .env files, wp-config.php, database credentials and API keys.
Memory disclosure of other requests: the leak primitive can expose passwords, session tokens, API keys and potentially TLS private keys handled by the same worker.
Database access using the application’s own credentials — customer records, orders, payment-adjacent data in e-commerce platforms.
Web shells and persistence in writable upload or cache directories, surviving the patch if nobody looks.
Payment skimming on shops: injected checkout JavaScript is the classic monetization of Magento and WooCommerce compromises.
Pivoting from a DMZ web server into internal networks, and lateral movement across tenants on shared hosting where one PHP installation serves many customers.

📊 Impact Assessment

Immediate Impact

Unauthenticated RCE against the runtime, not the application: clean, fully patched application code does not protect you.
Authentication and WAF-in-the-app do not apply — the malicious request is processed before your code is loaded.
Silent success is possible: an attack can end with an HTTP 200 and no crash. A complete attempt may leave only two to four memory-exhaustion errors on one worker.
Hidden inventory: bundled interpreters in containers and appliances do not show up in dpkg -l on the host.

Affected Versions

PHP branch	Affected	First fixed release
8.5	< 8.5.12	8.5.12
8.4	< 8.4.27	8.4.27
8.3	< 8.3.36	8.3.36
8.2	< 8.2.35	8.2.35 (branch EOL 2026-12-31)
7.4, 8.0, 8.1	All	No official release — PHP published minimal source backports; use a distribution / LTS vendor package or upgrade
5.4 - 7.3	All	No fix — upgrade

Distribution packages often carry the fix without changing the upstream version number. A few examples from the vendors’ trackers:

Distribution	Package	Fixed version
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1 (DSA-6574-1)
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1 (DLA-4848-1)
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS (ESM)	php7.4	7.4.3-4ubuntu2.29+esm5

So php -v printing 8.3.6 on Ubuntu 24.04 does not mean you are vulnerable — and printing 8.3.36 on a self-compiled build is the only way that version string proves anything.

A follow-up issue, CVE-2026-115560, was published by PHP on 2026-10-23. It requires an unusual configuration (an application switching session.serialize_handler to php at runtime with upload progress enabled); PHP will publish the full advisory with the next regular release and recommends session.upload_progress.enabled=0 in the meantime.

Affected Environments

Apache with mod_php — highest risk; the confirmed pre-application exploit path. Common on Debian/Ubuntu LAMP stacks and shared hosting.
PHP-FPM behind nginx or Apache — confirmed exploitable via the session upload progress path; Red Hat notes standard RHEL deployments use FPM, which makes exploitation harder in practice, but not impossible.
Shared hosting and control panels (Plesk, cPanel-style setups), where a single compromise can affect many customers.
Container images built FROM php:* — the official Docker php image gets no fix for 8.1 or older, and running containers keep the old binary until rebuilt and redeployed.
End-of-life PHP (7.x, 8.0, 8.1), still widespread on legacy line-of-business applications.

Attacker Profiles

Opportunistic mass scanners — the moment a portable exploit appears, internet-wide spraying of every PHP endpoint is cheap.
Magecart-style skimming groups targeting Magento, Shopware and WooCommerce shops for card data.
Initial access brokers and ransomware affiliates, for whom a DMZ web server is a foothold to sell or pivot from.
Targeted intrusion sets using PHP-based webmail, file sharing and intranet portals as an entry point into government and enterprise networks.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

Inventory every PHP runtime — and which SAPI serves the web. The CLI version is not necessarily what Apache or FPM runs.

# CLI interpreter version -- may differ from the one your web server loads.
php -v

# Debian/Ubuntu: installed PHP packages with their exact package versions.
dpkg -l 'php*' | grep '^ii'

# RHEL/AlmaLinux/Rocky/Fedora: installed PHP packages.
rpm -qa 'php*'

# Is mod_php loaded into Apache? (Debian/Ubuntu, then RHEL family)
apache2ctl -M 2>/dev/null | grep -i php
httpd -M 2>/dev/null | grep -i php

# Which PHP-FPM services are running?
systemctl list-units --type=service 'php*-fpm*'

Check whether your distribution package already contains the backport. Version numbers alone can mislead (see the table above); the package changelog cannot.

# Debian/Ubuntu -- adjust php8.3 to your installed branch. A non-zero count = fixed.
zgrep -c CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz

# RHEL/AlmaLinux/Rocky -- prints the changelog lines naming the CVEs if fixed.
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Patch — this is the only complete fix. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s backported package. PHP 8.1 and older: use a distribution or LTS vendor fix, or upgrade to a supported branch.
```
# Debian/Ubuntu -- pull the security updates for all installed packages.
sudo apt update && sudo apt upgrade

# RHEL/AlmaLinux/Rocky/Fedora -- upgrade all installed PHP packages.
sudo dnf upgrade 'php*'
```

Restart every worker. A patched package on disk does nothing while old workers keep the old code in memory.

# Debian/Ubuntu: restart FPM (adjust the version) and/or Apache for mod_php.
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

# RHEL family: FPM and Apache.
sudo systemctl restart php-fpm httpd

# Confirm nothing still runs the old libraries.
sudo needrestart -r l           # Debian/Ubuntu: list services that need a restart
sudo dnf needs-restarting -s    # RHEL family: list services that need a restart

Rebuild and redeploy containers. Check what is actually running, not what the Dockerfile says:

# Print the PHP version inside every running container (or "no php").
docker ps --format '{{.Names}}' | while read -r c; do
  printf '%s: ' "$c"
  docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'
done

If you cannot patch today: reduce exposure. PHP is explicit that these settings do not make an installation safe — they block the confirmed paths only. Set them where applications cannot override them, then restart every worker.

; PHP-FPM pool, e.g. /etc/php/8.3/fpm/pool.d/www.conf (Debian/Ubuntu layout).
; php_admin_* values cannot be overridden by ini_set() in the application.

; CVE-2026-109618: remove the controllable memory_limit failure.
; Side effect: one request may now consume all memory -- pair with a
; container/cgroup limit. Do NOT use RLIMIT_AS / RLIMIT_DATA instead.
php_admin_value[memory_limit] = -1

; CVE-2026-109619 (and CVE-2026-115560): disable session upload progress.
php_admin_flag[session.upload_progress.enabled] = off

; PHP 8.5 only: disable fatal error backtraces (confirmed RCE path).
php_admin_flag[fatal_error_backtraces] = off

# Apache with mod_php -- same settings in the vhost or server config.
# Not in .htaccess and not via ini_set(): they must apply before request parsing.
php_admin_value memory_limit -1
php_admin_flag session.upload_progress.enabled off
# PHP 8.5 only:
php_admin_flag fatal_error_backtraces off

PHP also recommends a conservative post_max_size (8M without uploads, 32M with) with upload_max_filesize below it, and limits at the proxy for decoded body size, part count, headers per part and nesting depth — including for requests without a usable Content-Length.

Block multipart at the edge where you can afford it. Every known trigger is a multipart/form-data request. Sansec published these stopgaps; they break file uploads and some checkout forms, so remove them after patching:

# nginx -- inside the server {} or location {} block for the PHP site.
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

# Apache (mod_rewrite) -- refuse multipart request bodies with 403.
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Detection Measures

There are no reliable network IoCs yet; the traces are in PHP error logs, web server error logs and process lineage. Datadog notes that in Unknown on line 0 means PHP failed during request initialization — before any script ran.

# PHP fatal OOM during request startup. With mod_php on Debian/Ubuntu, PHP errors
# land in the Apache error log by default; for FPM, check the error_log you configured.
grep -E 'Allowed memory size of [0-9]+ bytes exhausted.*Unknown on line 0' /var/log/apache2/error.log

# Apache worker crashes (segfaults) -- AH00052 is Apache's "child pid ... exit signal" message.
grep 'AH00052' /var/log/apache2/error.log

# Process tree of everything running as the web user -- a shell under a
# PHP/Apache worker is the strongest indicator of successful exploitation.
ps -u www-data -o pid,ppid,lstart,cmd --forest

# Sigma rule -- shell spawned by a PHP-serving web worker (Linux process creation).
# Convert with sigma-cli for your SIEM; tune out applications that legitimately exec().
title: Shell Spawned by PHP Web Worker (possible PHP2Shell post-exploitation)
status: experimental
description: Detects sh/bash/dash started by Apache, PHP-FPM, FrankenPHP or LiteSpeed PHP workers.
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent_name:
    ParentImage|endswith:
      - '/apache2'
      - '/httpd'
      - '/frankenphp'
      - '/lsphp'
  selection_parent_fpm:
    ParentImage|contains: '/php-fpm'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
  condition: (selection_parent_name or selection_parent_fpm) and selection_child
falsepositives:
  - Applications that legitimately call exec(), system() or proc_open()
level: high

Further signals worth hunting in WAF or proxy logs that capture request bodies: multipart requests carrying PHP_SESSION_UPLOAD_PROGRESS or PHPSESSID as a form field where the application never uses them; hundreds of parts in a small body; deeply nested field names like files[R00001][a][a][a]; <?php or |O: inside upload filenames; and Set-Cookie: PHPSESSID= response values that are unusually long or contain binary data. A cluster of two to four memory-exhaustion errors on one worker in a short window, followed by silence, deserves an investigation even without a crash — and an absence of log entries does not prove safety.

Long-term Security Improvements

Move off mod_php. Running PHP inside every Apache worker gave this bug its strongest exploit path. PHP-FPM with a separate pool per application limits both exploitability and blast radius.
Inventory runtimes, not just applications. Track interpreter versions in containers, appliances and bundled installs. A CMS version list did not tell anyone this week which servers ran PHP 8.1.
Retire end-of-life PHP. 7.4, 8.0 and 8.1 received only minimal source backports here; the next engine bug may not get even that. PHP 8.2 itself reaches end of life on 2026-12-31.
Least privilege for the web worker. Read-only code directories, no shell for the service account, outbound egress filtering so a reverse shell cannot call home, and secrets injected at runtime instead of sitting in readable config files.
Rebuild pipelines that actually rebuild. Container images pinned to an old digest stay vulnerable forever; make base-image updates and redeploys routine, not emergency work.
Log what you need for the next one. Ship PHP error logs, web server error logs and process-creation telemetry off-box; this week, they were the only places evidence appeared.

⚠️ Why is this Critical?

It is the runtime, not the app. Every PHP application on an affected interpreter is exposed, however well its own code is written.
No authentication, before your code runs. On mod_php the confirmed path completes before the application sees the request.
Default configuration is enough. PHP validated mod_php RCE with default input and memory limits; session upload progress and PHP 8.5 backtraces are on by default.
Fourteen years of releases. The vulnerable code path dates to PHP 5.4.0 — legacy systems that nobody touches are in scope and often unfixable.
The disclosure leaked. Attempts were seen four days before the patch and hours before the release; there was no quiet patch window.
Version strings lie in both directions. Backported distribution packages look old but are fixed; self-built binaries and containers look current on paper but may not be.
Silent success. An exploit can return HTTP 200, leave no crash, and only a handful of OOM lines in a log few teams read.
Today’s unreliable PoC is tomorrow’s portable one. Researchers already expect more variants of the same error-path pattern.

📅 Timeline and Disclosure

2026-08-01 — Calif finds multiple RCE paths during a PHP audit.
2026-08-11 — Calif reports the first bug to the PHP security team; coordinated disclosure starts.
2026-08-24 — Wiz Research independently reports the vulnerabilities to PHP.
2026-10-17 — Amazon Threat Intelligence observes an exploitation attempt against its MadPot honeypots.
2026-10-20 — CVE IDs and details leak ahead of the planned 22 October disclosure; watchTowr confirms the bugs; PHP announces an emergency release for 21 October, 14:00 UTC; CERT-EU publishes advisory 2026-018.
2026-10-21 — Cloudflare WAF rules live from 03:02 UTC; 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, plus source backports for 7.4, 8.0 and 8.1; CISA issues an alert; Ubuntu publishes USN-8948-1; several Dutch websites, including the NCSC’s, go offline as a precaution.
2026-10-22 — Rapid7 publishes its PoC analysis: public exploits work only under narrow conditions.
2026-10-23 — PHP publishes an informational advisory for CVE-2026-115560; CISA KEV catalog version 2026.10.23 does not list the PHP2Shell CVEs.
2026-10-25 — Unit 42 retracts its attribution of a government intrusion to PHP2Shell.

📚 Resources and References

🤝 SEKurity Supports You

Most vulnerability management is organised around products: the CMS, the shop, the VPN appliance. PHP2Shell is a reminder that the layer underneath the product is attack surface too — and that it is the layer least likely to have an owner. The web team owns WordPress; the platform team owns the base image; nobody owns the PHP 8.1 interpreter baked into a container three years ago.

The useful questions this week are concrete. Which of your servers run mod_php, and which run FPM? Which PHP binaries are inside your containers and appliances, and when were those images last rebuilt? Would your logs have shown four OOM errors on one worker on Tuesday night — and would anyone have read them? And if an attacker did land as www-data on your shop server, what could that account read, and where could it connect?

We test web applications and the infrastructure under them from the position a real attacker starts in — unauthenticated, on the internet — and we follow a foothold through to what it is actually worth. If your PHP estate has never been looked at below the application layer, this is the week to start.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your web applications and web infrastructure is our drive.

Sources

PHP — Security advisory, release announcements and informational advisory (October 2026 archive) — fixed versions 8.5.12/8.4.27/8.3.36/8.2.35, “who is at risk” SAPI list, mod_php highest risk, interim mitigations (memory_limit=-1, session.upload_progress.enabled=0, fatal_error_backtraces=0, post_max_size), source backports for 7.4/8.0/8.1, 8.2 EOL date, CVE-2026-115560 informational advisory
GitHub — GHSA-w8hw-w9fx-j79w (CVE-2026-109618) — CVSS vector, CWEs, longjmp() OOM root cause, multipart OOM triggers, per-SAPI analysis, soft/hard OOM fix, credits
GitHub — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — stale global state root cause, confirmed fatal_error_backtraces and session upload progress paths, mitigations
Datadog Security Labs — PHP2Shell: detection, analysis, and remediation — _zend_hash_str_add_or_update_i() root cause, exploitation stages, lab timing, request indicators, log signatures, process lineage
Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated RCE in PHP — CVSS vector, PoC reliability analysis, exploitation attempts, mitigation guidance
Tenable — php2shell FAQ — timeline incl. Amazon MadPot attempt, leak and early release, CISA alert, KEV status, malware-laced PoC warning, credits
watchTowr — PHP2Shell FAQ — in-the-wild attempts via Attacker Eye, affected legacy versions, leak timeline
Sansec — PHP2Shell: PHP RCE — disclosure timeline, PHP 5.4.0 origin, affected applications tested by Calif, multipart-blocking stopgaps, backport check commands, Cloudflare early-attack timing
Unit 42 — Threat Brief: CVE-2026-109618, CVE-2026-109619 — 22.6 million exposed instances, retraction of the intrusion attribution on 2026-10-25
Red Hat — CVE-2026-109618 — Important rating, CVSS 3.1 8.1, NVD 9.8, RHEL PHP-FPM default
Debian Security Tracker — CVE-2026-109618 and Ubuntu — CVE-2026-109618 — backported package versions
PPC Land — Cloudflare blocks php2shell exploits 9 hours before PHP flaws went public — WAF rule timing
Wiz — CVE-2026-109618 — reach of the affected runtime
CISA — Known Exploited Vulnerabilities Catalog — KEV status (catalog version 2026.10.23)
The Hacker News — CISA Flags Two Actively Exploited Critical Flaws in Collabora Online and Arista VeloCloud — other CW43 candidates considered for topic selection
EntryZero — Top 5 Hacker-relevant Vulnerabilities (weekly briefing) — weekly vulnerability briefing consulted for topic selection

InSEKurity of the Week (CW43/2026): PHP2Shell Unauthenticated RCE in PHP (CVE-2026-109618, CVE-2026-109619)