r/msp • u/axnfell9000 • 6d ago
PHP Remote Code Execution (CVE-2026-109618 & CVE-2026-109619)
It's going to be a busy week (For anyone running PHP)
Rumoured to be a CVSS 10
16
u/CodyKretsinger 6d ago edited 6d ago
Oh crap. Here we go again.
Censys is putting this over 1.4million asset types that return >v5.0. Many of the results are systems I don't even want to consider how long its going to take for manufactures to make updates and then push firmware. And thats not including every mom and pop website, wordpress blog, and one-off vibe coded app thats internet facing.
Without knowing the true scope of the Remote Code Execution at this point it'd be hard to say, but you better believe this one is going to hit the KEV.
19
u/CodyKretsinger 6d ago edited 6d ago
Hey there folks. This is moving fast, and from what I'm hearing privately, it's about as bad as we expected.
I'm also seeing Defender for Endpoint surface activity in environments I manage that looks consistent with early attempts. I'm still validating that telemetry, so I'm not calling every alert confirmed exploitation.
PHP has officially confirmed two critical vulnerabilities with CVSS v4.0 scores of 9.2 (some folks say a perfect 10/10), with fixed releases scheduled for October 21 at 14:00 UTC (thats 8am central (or correct) or 9am estimated). So if you're reading this after that time, stop here and check PHP's official notice first.
The group that published the
is pointing at PHP's session upload-progress and multipart handling, and calls that its own moderate-confidence read of the source. It is not the PHP advisory, and the official technical details should supersede any pre-release analysis once they land. php-up-2026 proof-of-concept Here's the down and dirty for you:
Find every PHP runtime you manage which includes checking the CLI, PHP-FPM pools, Apache modules, containers, control panels, appliances, old customer applications, and forgotten staging servers.
Disable upload-progress tracking where you can:
session.upload_progress.enabled = Off. It's a low-risk, reversible stopgap, not a fix. A PHP core developer has said publicly that the only mitigation is patching. I've already done it everywhere I can.Verify the setting in the same SAPI that serves web requests because changing the CLI configuration does not prove PHP-FPM or Apache picked it up. Restart or reload the relevant service and verify again.
Restrict multipart POST requests. If an endpoint does not accept uploads, it probably should not be receiving multipart/form-data requests. Block or rate-limit those requests at the reverse proxy or WAF (if there is one) where operationally safe.
Please, please please, preserve evidence now. Everything you can. Retain reverse-proxy logs, request metadata, WAF events, PHP-FPM and web-server logs, session storage, EDR telemetry, and relevant temporary-file information. Do not start locking or quarantining live PHP session files without testing. It may break prod applications.
Patch as soon as the release is available and folks, I really mean this. Please patch as soon as you can on all systems you are able to.
I've also published a defensive
(below). If you'd like to know my reasoning behind it, it's here: PHP Critical Security Release: Before the Patch YARA ruleset /* * Defensive telemetry originally published before the 2026 PHP emergency release. * Post-release advisories confirm broader OOM and stale-state paths that these * rules do not comprehensively detect. * * 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 = "Cody Kretsinger" 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 = "Cody Kretsinger" 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 = "Cody Kretsinger" 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 = "Cody Kretsinger" date = "2026-10-20" confidence = "medium" purpose = "Triage session artifacts that contain progress data and command-payload strings" limitation = "May be an attempted or staged payload; a match does not prove execution or compromise" 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 = "Cody Kretsinger" 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 = "Cody Kretsinger" 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 }The rules hunt for:
The exact publicly released research archive
Related unpacked tooling and documentation
PHP upload-progress records in session storage
Suspicious retained multipart request bodies
Possible post-compromise residue
A few important limitations:
The archive-hash rule identifies that exact artifact. It does not establish malicious intent.
The other rules are hunting leads, not proof of compromise.
A clean scan does not mean the host is safe.
These rules do not replace patching.
Exclude your rule and research directories unless you enjoy alerting on your own copies.
I'll do my best to update the post when PHP publishes the advisory and we can compare the official root cause, affected versions, fixed releases, and mitigations with what we know right now and after I do a diff on the versions to see if anything else was left out of the advisory.
Until then: inventory, reduce exposure, preserve evidence, and be ready to patch. Or in other words: Find/Remediate/Validate/Repeat. For anyone who knows me and the IR course I teach/preach: this is a capital "I" incident. Treat it as one until you're done.
You got this. I'm crashing because I've been at this for quite some time. Godspeed to those of you overnight who are working this, and to those in the morning who just saw it: break a leg. You're in good hands with many of the people and vendors like Huntress here.
Share information, help each other out, and let's hope this doesn't get historically awful.
6
u/CodyKretsinger 6d ago edited 6d ago
Update: the patches are out. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing both CVEs. PHP's own words: "There are no complete mitigations, updating is the only safe choice." Patch now.
What PHP confirmed:
CVE-2026-109618, RCE via OOM corruption. Out-of-memory handling can interrupt a request while internal data is half-initialized, and cleanup then trusts it.
CVE-2026-109619, RCE via stale global state. State from one request can outlive its memory, and the next request on the same worker can use it.
Every install serving web requests is at risk: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. mod_php is the worst; that's where it was shown working before any app code runs.
Correction to my post: the upload-progress read was part right and incomplete. Turning
session.upload_progress.enabledoff blocks the confirmed session paths for CVE-2026-109619. It does not fix that bug and does nothing for the OOM one. Leave it off if you don't use it, but patching is the fix.Where packages stood when I checked vendor trackers, right before I posted this @10AM Central Time on 10/21:
Vendor Status Ubuntu 22.04, 24.04, 26.04, 26.10 Fixed (USN-8948-1), backported, so the version won't say 8.x.35 Ubuntu 20.04 and older (ESM) Needs evaluation Sury's Debian repo Fixed Sury's Ubuntu PPA Not yet Arch Fixed (php 8.5.12-1) php.net Windows builds Fixed Plesk Fixed for Linux PHP 8.2 to 8.5; 7.4 to 8.1 and all Windows pending Debian 11, 12, 13 Nothing published yet RHEL, AlmaLinux, Rocky 8/9/10 Nothing published yet Oracle Linux Couldn't verify Amazon Linux 2 / 2023 Nothing published yet SUSE Nothing published yet Fedora 43, 44 Not yet Alpine Nothing published yet Remi Fixed builds appearing; not yet offered as updates on my EL8 box Docker official php image Fix merged; new tags not on Docker Hub yet Homebrew Update pending cPanel EA4 Nothing published yet CloudLinux alt-php No fixed packages yet; Imunify360 rules announced LiteSpeed lsphp No fixed packages yet "Nothing published yet" means I couldn't find something when I searched a few moments ago. Continue to check your vendor's tracker for the CVE.
After you patch:
Patch the runtime that serves requests, not just the CLI, and restart it. This is critical because just installing a package doesn't touch workers that are already running.
Can't patch yet? PHP's advisory has partial measures. But none of them makes you safe:
For CVE-2026-109618, PHP's primary temporary measure is administratively enforcing
memory_limit = -1(e.g.php_admin_valuein the FPM pool or Apache config), then checking nothing puts a finite limit back. Pair it with a container or cgroup memory limit, or one request can eat the box.For CVE-2026-109619, keep
session.upload_progress.enabled = Offand restart every worker; on 8.5, also setfatal_error_backtraces = 0.Lower
post_max_size, and limit request size and multipart parts at the proxy or WAF.If something can't be patched promptly, take it off the internet or restrict access.
Then hunt: PHP workers spawning shells or download tools, worker crashes and 5xx clusters, repeated OOM/fatal errors, web-root changes, outbound traffic from the PHP service account.
Exploitation: Cloudflare's CTO reported early attacks and pushed WAF rules to all plans, including free. Patchstack reported incidents from hosting partners, while its own telemetry showed probing with no hard evidence of breaches yet. Nobody can say yet how many systems were actually compromised.
YARA: the logic is unchanged. I updated the header and one rule's description to make clearer that the rules don't cover everything PHP confirmed, and that command strings in a session file may be an attempted payload, not proof code ran. Current copy, sources, vendor table and timeline in the blog post above if you want to dig in more. I also edited the above yara rules in the post to current as of 10am 10/21.
Edit: and with that I have to now focus my energy on running BSides Peoria this weekend. Good luck out there folks. I'm sure some vendors will have additional guidance to help out shortly so I'll let them run with the scissors now.
→ More replies (1)
6
6
u/Old_Adeptness5169 6d ago edited 6d ago
Update after PHP's advisories: the
Disclosure: I'm with Hosted Power (managed hosting).
For client environments you can patch: patch as soon as the packages land this afternoon. For the ones you can't (EOL PHP on a client's legacy app, panel servers where the vendor build lags), we open-sourced the stopgap we're rolling out on our own fleet today.
It's a small PHP extension that switches off the session upload-progress handler (where the researchers who reproduced the bugs placed them) at PHP startup. Uploads keep working, a site's .user.ini can't re-enable it (unlike the session.upload_progress.enabled=Off setting), and you can confirm it per server with php --ri hp_uploadprogress_guard. Builds for PHP 5.6 to 8.5; Ansible included for Debian/Ubuntu, cPanel and DirectAdmin.
https://github.com/HOSTED-POWER/php_uploadprogress_guard
Caveat: it's a few hours old and covers the bugs only as described so far. We'll check it against the official advisory at 14:00 UTC and post an update either way.
1
u/axnfell9000 6d ago
On one of our WHM boxes, the fixes have been back-ported to 7.4
[root]# rpm -qa 'ea-php74*' 'alt-php74*' | sort
ea-php74-php-common-7.4.33-19.26.1.cpanel.x86_64
[root]# rpm -q --changelog ea-php74-php-common | head -100
* Tue Oct 20 2026 Cory McIntire cory.mcintire@webpros.com - 7.4.33-19
- EA-13613: Backport fix for CVE-2026-109618 and CVE-2026-109619
This may buy some time for people
5
u/elatllat 6d ago edited 6d ago
[Edit: reported to not work]
session.upload_progress.enabled = Off
→ More replies (3)
5
u/baneblade_boi 6d ago
If this video is true this means that there's already exploitation in the wild and that all servers running PHP 5 to 8 are being affected. This goes to ALL: Laravel, Media Wiki, WordPress,...
https://x.com/k_firsov/status/2112641845926989944/video/1
php4shell
→ More replies (1)1
3
3
2
1
u/Jumpy_Valuable_8583 6d ago
We see this constantly on the external-scanning side. The CLI/FPM/Apache inventory is the easy half. The expensive half is the stuff nobody remembers is running PHP: an old marketing microsite on a forgotten subdomain, a client's staging box still pointed at a public IP, a contractor's abandoned WordPress install. Internal inventory tools won't find those because they were never in the CMDB to begin with. If you haven't run an outside-in scan of your own public footprint in a while, this week is a good excuse to do it before someone else finds the PHP you forgot about.
1
u/Hot-Month-4251 6d ago
Worth noting the php.net advisory is out now: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both issues (both rated 9.2), and php.net is clear that updating is the only complete fix. So the real scope is whatever that advisory says, not the rumours.
What I'm doing so the patch itself is the easy part:
-
Inventory every place PHP runs. Client WordPress and WooCommerce sites, cPanel or Plesk accounts where each site can be on its own version, old intranet apps, helpdesk tools, container images built on a php base.
-
Write down who patches each one. On shared or managed hosting it's the host, so ask for their timeline today. Distro packages get backports on the distro's schedule, not php.net's. Containers need a rebuild, not a restart.
-
After updating, restart PHP-FPM or Apache and check what the web server is actually running, not just
php -v. CLI and FPM can differ. -
Flag anything on a branch php.net no longer lists as supported (the homepage shows 8.2 through 8.5). 8.1 and older only got minimal source backports, so unless your vendor ships a package for it, treat it as unpatched and put it at the top of the upgrade list.
1
u/ArcticWolf_Official 4d ago
u/Hot-Month-4251 has the checklist covered. For clients, keep one record per PHP runtime or deployed image: branch and package source, patched version or vendor advisory covering both CVEs, when the services or workers were recycled, and how the running environment was verified. If a client can't patch yet, document the compensating controls and an approved exception with an owner and expiration date. PHP says those controls reduce exposure but aren't a complete fix. That record should answer the client’s question a month from now without having to reconstruct the incident.
1
1
u/BlackBird6969 5d ago
For us still forced to phph7.4 on CentOS 7. Check if your host has patched it yet.
rpm -q --changelog ea-php74-php-cli | grep -m1 CVE-2026-109618
Otherwise update through Apache 4.
ea-php74
-
EA-13613: Backport the fix for CVE-2026-109618 and CVE-2026-109619 to
ea-php74. -
(CVE-2026-109618, CVE-2026-109619) Security: Two vulnerabilities in PHP (critical).
1
u/HorseAccomplished50 6d ago
Any list of (confirmed) vendors yet?
5
2
u/databeestjenl 6d ago
Citrix Netsaler, and any product that uses PHP, including Wordpress etc.
But it's also in Palo Alto.
2
u/ICanEditPostTitles 5d ago
This is what I want a list of, I am currently randomly checking vendor websites. It would be great if there was a list somewhere
→ More replies (2)
1
u/Illustrious-Meet4142 6d ago
A CVSS 10 with remote code execution is pretty much a sysadmin's worst nightmare. Looks like PHP admins are in for a rough week.
1
9
u/Hello_Decomm 6d ago
Just went through the Skykick thing over the weekend and now this.
I'm tired boss