PHP critical release: defensive telemetry during reported active exploitation

Warning Update, 20 October 2026. I have received credible private indications of active exploitation. I am withholding affected locations, technical evidence, and exploit details while they are handled through incident-response and disclosure channels. PHP has announced a critical security release for 21 October at 14:00 UTC ^[1]. Patch immediately when fixed releases are published; until then, apply the interim risk reduction below.

What PHP has confirmed #

• A security release is scheduled for 21 October 2026 at 14:00 UTC.
• It addresses two critical vulnerabilities, each rated CVSS v4.0 9.2.
• PHP may release earlier if details become public or it observes active exploitation.

That is everything PHP has confirmed ^[1]. The notice does not name the vulnerabilities, describe the affected code, or list affected or fixed versions.

What third parties report #

BleepingComputer and Sansec report the identifiers as CVE-2026-109618 and CVE-2026-109619, describe both as remote code execution, and report that older PHP branches are affected ^{[2, 3]}. Huntress reports that watchTowr reproduced CVE-2026-109618, that Huntress had not seen in-the-wild exploitation in its partner environments as of 20 October, and that no indicators of compromise have been confirmed ^[8]. CERT-EU’s advisory repeats the CVE and affected-version claims on the strength of the same third-party reporting ^[7]. None of this is confirmed by PHP. Treat it as reporting until the advisory is published.

What the PoC group claims #

The group that published the php-up-2026 proof-of-concept page and bundle (J4ck3LSyN, with @acd421 and ArchKnight23 credited) is a separate source, and it is more specific than anything above. It names CVE-2026-109618 and CVE-2026-109619, and it identifies session upload-progress and multipart (rfc1867) request handling as the leading affected paths. @acd421 describes that conclusion as a moderate-confidence assessment from reading php-src, not a PHP-confirmed root cause, and says the group will check it against the advisory ^[10]. The group’s X post and its PoC page are one source, not two.

It is the most specific public hypothesis so far, and it is unverified. Nobody independent has confirmed the root cause or vetted the group’s bundle. Copies, mirrors and repacks circulating elsewhere are less trustworthy still. Do not download, execute, or trust any of it.

Interim risk reduction #

Patching is the remedy. PHP core developer Gina Peter Banyard wrote on 21 October that “the only mitigation is patching / upgrading PHP” ^[6]. Nothing in this section should be read as protection. It reduces exposure while fixed releases and distribution backports are pending.

For applications that do not use the feature, disable upload-progress tracking as a precaution:

session.upload_progress.enabled = Off

The feature is enabled by default, and PHP documents that it writes progress into the session before application scripts execute ^[4]. That does not make it the confirmed cause, and turning it off should not be assumed to close the vulnerability. It is low-cost and reversible. Assess application impact; the usual loss is server-side upload-progress reporting. In .htaccess under Apache, the equivalent is php_flag session.upload_progress.enabled off, where the host allows it.

Reload the PHP SAPI that serves the application, then verify the effective setting through that same SAPI, using an existing authenticated health or configuration endpoint or a controlled server-side check. The CLI often loads a different configuration, so checking only the CLI can mislead. Do not stand up a public phpinfo() page to check it.

Apply the official update as soon as fixed versions or distribution backports are available, starting with internet-facing hosts. Where that can’t happen promptly, consider isolating exposed PHP applications or restricting access to them, which is what CERT-EU recommends ^[7]. PHP currently supports 8.2 through 8.5 ^[5]; 8.1, 8.0 and older are end-of-life upstream. For those, do not assume an upstream fix, and get vendor, distribution or host guidance now.

Defender hunt #

You do not need exploit code to hunt. Look for these signals together, not in isolation:

• Multipart requests carrying the documented PHP_SESSION_UPLOAD_PROGRESS field, especially on routes that do not normally accept uploads, or repeated from the same source, session, or network range.
• PHP-FPM, Apache, LiteSpeed, or FastCGI worker crashes and restarts, including segfault, abort, or core-dump messages, close in time to that traffic.
• Clusters of 5xx responses, upstream timeouts, or reset connections on PHP-backed routes.
• Anomalies in session storage: a sharp rise in upload_progress_ records, or records on applications where the feature was believed unused.
• Shells, downloaders, interpreters, or other unexpected child processes under the PHP service account.
• New or modified files in the web root, or changed startup and scheduled-task files.
• Outbound connections from the PHP service account that should not exist.

Existing EDR rules for a web server spawning a shell already cover the post-exploitation step, whatever the entry point. Elastic’s rule, for example, includes php-fpm*, php-cgi and lsphp* parents ^[9]. Match php-fpm as a prefix: Debian-family workers run as php-fpm8.2 and similar. PHP isn’t Linux-only: on Windows, Elastic’s web-shell rule covers php.exe and php-cgi.exe spawning script interpreters ^[11].

None of these proves exploitation on its own. The value is in correlation. Upload-progress traffic followed by a worker restart, a 5xx cluster, an unexpected child process, a web-root change, or new outbound traffic warrants opening an incident immediately, before the vendor publishes details. Preserve proxy, WAF, web-server, PHP-FPM, and host telemetry now, before normal rotation removes it; after the advisory, those records are how you answer whether this touched you.

YARA #

These rules cover four jobs: finding one exact reported archive if it landed on a host, hunting related unpacked tooling or documentation artifacts, baselining upload-progress use, and triaging suspicious session residue after an alert. They are not an exploit detector. They will not reliably identify modified, repacked, memory-only, or standalone proof-of-concept code, and they are not a substitute for disabling the feature and applying the vendor patch.

The ruleset is also available as a download: php-upload-progress-prepatch-defense.yar.

YARA inspects retained artifacts. It cannot see connection timing, worker crashes, PHP memory state, or requests that were never logged. Do not use the informational or low-confidence rules as blocking conditions. For accurate results, scan retained, decrypted request bodies and copied session data or backups rather than live session files, unpack archives first, exclude rule, documentation, threat-intelligence, and fixture directories to avoid self-matches, and record the YARA version, command line, corpus, and results with each scan. The small-file rule’s filesize < 4096 condition applies to the retained artifact passed to YARA, not necessarily the original wire-level request. Log wrappers, metadata, encoding, or truncation can change the scanned size and affect matching.

/*
 * Pre-patch telemetry for the 2026 PHP upload-progress emergency release.
 *
 * Scope:
 * - Scan UNPACKED files and retained, decrypted HTTP request bodies.
 * - These rules are alerts/hunts, not a compensating control for a PHP-core flaw.
 * - Do not scan live session files in place if the scanner can lock or alter them.
 */

import "hash"

rule PHPUP_Staged_Bundle_Exact_Hash
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "high"
        purpose = "Detect the exact staged archive identified in public reporting"
        limitation = "Hash only; renamed or modified variants will not match"
    condition:
        filesize > 30MB and filesize < 50MB and
        hash.sha256(0, filesize) == "0c254d547cac650bfbcb2275e30c2083737520a51a0511646f1fbb7ed60a0d63"
}

rule PHPUP_Staged_Tooling_Unpacked
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "medium"
        purpose = "Hunt unpacked staged-tooling files or documentation"
        limitation = "Compressed tarballs must be unpacked before string scanning"
    strings:
        $file1 = "php_up_framework.py" ascii wide
        $file2 = "poc0_109618.py" ascii wide
        $file3 = "poc1_109619.py" ascii wide
        $file4 = "poc_trigger.py" ascii wide
        $mark1 = "DELTAS_LSphp" ascii wide nocase
        $mark2 = "PHPUP_FILES" ascii wide
        $mark3 = "php_session_rfc1867_callback" ascii wide
    condition:
        filesize < 10MB and (2 of ($file*) or (1 of ($file*) and 1 of ($mark*)))
}

rule PHPUP_Session_Progress_Record
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "informational"
        purpose = "Locate persisted upload-progress records for incident scoping"
        limitation = "Matches normal use of the feature; supports common PHP serializers only"
    strings:
        $php_session = /upload_progress_[^|]{0,256}\|a:[0-9]{1,10}:\{/ ascii
        $php_serialize = /s:[0-9]{1,10}:"upload_progress_[^"]{0,256}";a:[0-9]{1,10}:\{/ ascii
        $field1 = "bytes_processed" ascii
        $field2 = "content_length" ascii
        $field3 = "start_time" ascii
        $field4 = "files" ascii
    condition:
        filesize < 4MB and (any of ($php_*) and 2 of ($field*))
}

rule PHPUP_Session_Progress_Potential_PostCompromise
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "medium"
        purpose = "Triage session artifacts that contain progress data and likely command-execution residue"
        limitation = "Post-compromise signal only; it does not detect the exploit attempt"
    strings:
        $progress = "upload_progress_" ascii
        $cmd1 = "system(" ascii nocase
        $cmd2 = "shell_exec" ascii nocase
        $cmd3 = "proc_open" ascii nocase
        $cmd4 = "passthru" ascii nocase
        $cmd5 = "/bin/sh" ascii
        $cmd6 = "/dev/tcp/" ascii
        $cmd7 = /(curl|wget)\s+-?[a-zA-Z]*\s*https?:\/\// ascii
    condition:
        filesize < 4MB and $progress and 1 of ($cmd*)
}

rule PHPUP_Multipart_Progress_Small_File_Hunt
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "low"
        purpose = "Prioritize retained multipart requests that exercised upload progress with a very small file part"
        limitation = "Use for hunt/correlation only; legitimate upload-progress forms can match"
    strings:
        $disposition = "Content-Disposition: form-data" ascii nocase
        $progress = "name=\"PHP_SESSION_UPLOAD_PROGRESS\"" ascii nocase
        $file_part = "filename=" ascii nocase
    condition:
        filesize < 4096 and all of them
}

rule PHPUP_Multipart_Progress_Any
{
    meta:
        author = "gib.bz"
        date = "2026-10-20"
        confidence = "informational"
        purpose = "Baseline all retained use of PHP upload progress"
        limitation = "Never use alone as a block or high-severity alert"
    strings:
        $progress = "PHP_SESSION_UPLOAD_PROGRESS" ascii nocase
    condition:
        $progress
}

Indicators published by the PoC group, not independently verified #

The group that published the php-up-2026 PoC page published an archive hash and file names for its bundle. They describe that published material only. They are not PHP-vendor IOCs and have not been independently validated against observed attacks. A match is a reason to investigate, not proof that a host was compromised. Preserve matching files for incident-response review.

After the PHP release #

1. Read PHP’s advisory and identify the fixed releases and affected branches.
2. Upgrade the serving PHP SAPI, not only the CLI binary, and restart it.
3. Re-enable upload progress only after evaluating the advisory and validating the patched deployment.
4. Retire or tighten these rules based on the vendor’s technical details.
5. Review retained request logs and session backups for the period before the patch was deployed.

References #

1. PHP, “Upcoming Critical PHP Security Release”, 20 October 2026. php.net (opens in a new tab) (accessed 20 October 2026)
2. BleepingComputer, “PHP warns admins of two critical flaws, emergency patches coming tomorrow”, 20 October 2026. bleepingcomputer.com (opens in a new tab) (accessed 20 October 2026)
3. Sansec, “Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619”. sansec.io (opens in a new tab) (accessed 20 October 2026; page is being updated)
4. PHP Manual, “Session Upload Progress”. php.net (opens in a new tab)
5. PHP, “Supported Versions”. php.net (opens in a new tab) (accessed 20 October 2026)
6. Gina Peter Banyard (@Girgias), Mastodon post, 21 October 2026. phpc.social (opens in a new tab) (accessed 21 October 2026)
7. CERT-EU, “Critical Vulnerabilities in PHP”, Security Advisory 2026-018. cert.europa.eu (opens in a new tab) (accessed 21 October 2026)
8. Huntress, “Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)”, 21 October 2026. huntress.com (opens in a new tab) (accessed 21 October 2026)
9. Elastic, “Unusual Command Execution via Web Server” detection rule. github.com (opens in a new tab)
10. @acd421, post on X, 21 October 2026. x.com (opens in a new tab) (accessed 21 October 2026)
11. Elastic, “Web Shell Detection: Script Process Child of Common Web Processes” detection rule. github.com (opens in a new tab)

Corrections #

1. 2026-10-20 The unpacked-tooling YARA rule was published as high confidence. It is medium confidence: documentation and copied snippets can match its strings.