Confession: when the PHP advisory landed last Wednesday, my first instinct was to schedule the update for the weekend. Critical bug, sure, but I'd read "high attack complexity" in the score and told myself I had time. Then I lined up the dates for the six days that followed, and the weekend plan looked a lot worse.
Short version for the impatient: waiting on CVE-2026-109618 and CVE-2026-109619 costs you more each day than the score suggests, because the attack side moved faster than the advisory implied. Below is the timeline as I can source it, what a late patch actually risks, and what I'd check if you already waited.
I'm a developer who runs PHP for clients, not an incident responder. Where I'm guessing, I'll say so.
The timeline, with sources
Here's what I can pin to a source, in order.
On October 20, a post about two critical PHP bugs appeared on Hacker News and was removed, but screenshots spread. According to Huntress, watchTowr confirmed the leak, and the planned Thursday release was pulled forward to Wednesday, October 21.
On the 21st, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The same day, watchTowr says its honeypot network observed exploitation. Huntress, checking its own partner systems that afternoon, saw none. Both statements can be true. A honeypot sees the whole internet; a partner base sees a slice.
Datadog Security Labs notes that working public proofs of concept were circulating by October 23. Rapid7 tested them and found each one works only for a specific mix of OS, PHP version and web server. They had not seen confirmed exploitation themselves but did report multiple attempts.
On October 26, watchTowr updated its FAQ to say CISA added CVE-2026-109618 to the Known Exploited Vulnerabilities catalog. The page lists KEV status only for that CVE, not for 109619.
That's five days from fix to the government's "this is being used" list. I'd have bet on longer.
One claim I'd throw out
Palo Alto's Unit 42 published a brief on the 23rd linking some post-compromise activity to PHP2Shell, then retracted that link on October 25. Per their updated page, they had seen an attack on a European government agency running a vulnerable PHP application but could not confirm the initial access involved these CVEs.
I mention this because a lot of people screenshotted the first version. If someone tells you "attackers are dropping X after PHP2Shell", ask which source, and check whether it's the retracted one. The honest state of the evidence is: exploitation attempts, some observed exploitation per watchTowr, a KEV listing for one CVE, and no clean public case study of a full compromise tied to these bugs.
That's not comfort. It means we're early.
What a late patch actually risks
Let me be concrete about the downside, because "critical RCE" is abstract enough that it stops registering.
These are unauthenticated bugs. PHP's own description, passed along by Huntress, is that an exploit exists for mod_php where an unauthenticated request triggers the attack before any application code runs. There's no login to brute-force, no form to find, and your WAF rules written against your own routes sit in the wrong place.
Once someone has code execution inside a PHP worker, they have whatever that worker has. Database credentials from your .env. API keys. Write access to the web root. Wiz showed, again via Huntress's summary, that the memory disclosure side can expose passwords, tokens, API keys and certificates. So the cost of waiting is not only "they take the server". It's "they take everything the server can reach".
For a freelancer, that last part is the one that wakes me up. One compromised client box can hold the Stripe key, the mail credentials and the database for a business that never heard of CVSS. I keep thinking about how I'd write that email.
Also remember the shared-hosting case. If you run client sites on one box, one vulnerable pool puts them all in range together.
If you already waited, check this
Patching does not undo anything that happened before the patch. If your server was reachable on the 21st and ran an old build for days, spend twenty minutes on these.
Look for PHP workers spawning things they shouldn't. Florian Roth, quoted by Huntress, expects exploitation to show up as child processes of PHP such as sh, bash, python, curl, wget or nc. Huntress also flags reverse-shell strings like /dev/tcp/ and fsockopen, and quick recon commands such as whoami and id.
# PHP workers with suspicious children (rough check, run as root)
ps -eo pid,ppid,user,lstart,cmd --forest | grep -B1 -E 'sh -c|bash|curl|wget|nc ' | grep -A1 -E 'php-fpm|php-cgi|apache2|httpd'
# files changed in the web root since the fix shipped
find /var/www -type f -newermt '2026-10-20' -not -path '*/cache/*' -not -path '*/node_modules/*' | head -50
# cron entries and recently modified system accounts
ls -la /etc/cron.d /var/spool/cron* 2>/dev/null
lastlog | head
These are my rough versions of the checks Huntress describes: webshells, new files in the web root, new cron jobs, new accounts. A hit isn't proof and a clean result isn't proof. The Rapid7 advisory itself says the absence of relevant log entries does not prove an installation is safe, and there are no published indicators to match against.
If something does look off, Huntress's advice is to isolate the server and preserve the web server and PHP logs before touching anything. Then rotate every secret that box could read, not just the obvious ones.
Which servers I'd patch first when I can't do all of them
If you have ten servers and one evening, the order matters more than the speed. This is the order I'd use, and it's my own judgment, not vendor guidance.
First, anything running Apache with mod_php. The PHP team rates it highest risk because the demonstrated attack lands before application code runs. Second, anything public that accepts file uploads or large multipart posts, since the memory exhaustion path in the first bug starts with a crafted multipart request. Third, anything holding secrets for other systems: a box with payment keys, mail credentials or database admin passwords is worth more to an attacker than a brochure site.
Last, the internal tools and staging boxes. They matter, but nobody is spraying the internet for your staging server.
This is also where the weekend plan falls apart. A Saturday window sounds fine until you add up what the timeline above shows: fix released Wednesday, exploitation reported the same day by one source, public exploits by Friday. By Saturday you would have spent a day and a half on a bug with working public exploits and no log evidence either way, and the KEV listing was only two days further on.
What I'd do about the delay itself
Delays happen for boring reasons. A client is mid-launch. A deployment pipeline is flaky. The distro repo hasn't got the package yet; Huntress notes the Remi repository had no updated packages on release day.
When I can't patch, I narrow the exposure rather than shrug. Disable session upload progress in the main config, cut the upload size, and put a stricter limit on request bodies at the proxy. That's a partial step for one attack path, and per watchTowr's reading of the PHP statement, no configuration change fully mitigates these bugs. If the app is public and the stakes are real, a maintenance window tonight beats a perfect one on Saturday. My VPS hardening baseline has the proxy and firewall pieces I use to narrow things down.
If you want to see how I handle this kind of work for clients, my portfolio has the details.
Tonight, pick your most exposed server, run the first command above, and if anything unexpected shows up, isolate the box before you do anything else.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
Top comments (0)