Shaun Seidman
Engineering Manager · Denver, CO
GitHub ↗LinkedIn ↗

03 / note · October 24, 2026

Black Thursday and the vulnerability fatigue coming for all of us

Is this the new normal?

I had a flight out of DIA to DFW for a work event (probably best I have ever attended, need to write something on that) @ 7 in the morning on Wednesday. Tuesday evening, I sent a VERY strongly worded support ticket to WP Engine asking what their plan was when it came to the PHP2Shell as I wasn't taking my personal machine with me and I didn't know if I needed to take things down Tuesday before I left. Still waiting for that ticket to get answered!

PHP2Shell lives in the PHP runtime, so there was nothing for me to fix in WordPress or a plugin. WP Engine had to update PHP for me, and since the ticket went nowhere, I spent the trip checking their status page from my phone.

I got home Friday night. Saturday morning, I started on my personal projects. I went through each vulnerability (burning through my 5 hour usage), checked whether it touched anything I run, and fixed what did. I used AI to help with the audit and the fixes. I still had to verify every change as I went, because an agent telling me it fixed a CVE doesn't count as fixing it.

Past few days in summary if you live under a rock

  • PHP: Someone leaked two PHP core CVEs, CVE-2026-109618 and CVE-2026-109619, with a Thursday disclosure date. PHP pulled the fix forward to Wednesday for 8.2 through 8.5. Anything on 8.1 or older gets nothing. Exploit code was on GitHub before the patch was, and PHP blamed Chainguard for shipping patched images six hours early.
  • GitLab: CVE-2026-110264 is a CVSS 10.0 unauthenticated RCE in self-managed GitLab, and it goes all the way back to 7.0. Fixes only exist for 18.11 and newer, so if your instance is older than that, you get to walk through upgrade stops first. If you patched on October 12, that was a different CVE. Patch again.
  • Node.js, then everything else: CVE-2026-111497 is an out-of-bounds write in Google's Brotli decoder. OpenAI found it back in February, it got fixed in source, and nobody treated it as a security issue until now. It started as a Node bug and by Friday it was hitting Python too, because requests, httpx, and aiohttp decode Brotli for you if the package is installed. As of Friday, pip-audit and Dependabot weren't flagging it.
  • Python: Pillow disclosed three critical CVEs on the 19th, fixed in 13.0.0. Then on the 21st, someone used stolen GitHub tokens from three LiteLLM engineers to publish a backdoored 1.107.0 to PyPI and Docker. It dropped a .pth file, so the credential stealer ran on every Python startup whether you imported LiteLLM or not.
  • eMudhra: On October 17, Mozilla got a report that eight of eMudhra's intermediate certificate authority keys were compromised. Six were for TLS and two for code signing. The keys came out of an April 2025 key ceremony and were small enough to brute force. One of them was the number 4. Mozilla recovered the keys on its own to confirm, and one write-up says a Mozilla researcher's local AI agents got them on the first try. Chrome, Apple, Microsoft, and Mozilla all blocked the certificates, Mozilla pulled trust in the root, and by Thursday eMudhra announced it was leaving the TLS certificate business.
  • Java and Oracle: Oracle's October Critical Patch Update landed Tuesday with 1,295 patches. A day later Oracle pushed an out-of-band Java fix for CVE-2026-91403, a 9.1 in JSSE, so Java would stop trusting those eMudhra intermediates. If you run Java and haven't picked that up, your apps still trust certificates signed with keys anyone can recover.
  • Railway: Railway disclosed a breach where someone may have read customers' decrypted environment variables. They paused every deployment on the platform on Wednesday. If you deploy there, assume every API key and database password in your env vars is out there and rotate it.

Researchers at Wiz, OpenAI, and Calif used AI models to find the PHP bugs. OpenAI's Codex Security team reported the Node.js one. Wiz said frontier AI had "substantially reduced" the barrier to exploitation, which is a polite way of saying the attackers have the same tools.

Is this the new normal?

I think so. Frontier models are good at reading old C code and noticing the thing a human reviewer skipped twenty years ago. PHP, Node, GitLab, and whatever comes next are full of that code. Every lab and security vendor with a model and a press team now has a reason to point it at popular runtimes and see what falls out.

Microsoft shipped more than 1,400 fixes on Patch Tuesday earlier this month. Oracle added 1,295 more this week. That was all before PHP2Shell and the GitLab 10.0. If that's what a normal month looks like now, I don't know what a bad one looks like.

What the fatigue looks like

On my personal projects, the loop went like this: an advisory lands, X freaks out, I freak out, I check whether it applies, I have AI help me find the affected code or the version bump, and then I verify the fix myself. Doing that once is fine. I'm not sure I can do it every week without starting to cut corners.

Speeding up the audit with AI didn't make the verifying any faster. I wrote about this in The human in the loop owns the loop. When an agent makes the change, reviewing it is still my job, and that's the step that wears me down. Multiply that by every 9.x that lands in a week and the review starts to feel like paperwork. That's where I'd expect the mistakes to come from.

The other kind of fatigue is quieter. When every advisory is a 9 or a 10, they all start to look the same. I don't stop caring about them. I start sorting faster, and the one that matters gets skimmed along with the one that doesn't apply to me. Last month I built a CVE tracker with Jev to help decide whether a patch can wait for the normal cycle. If I'd run this week through it, I'm pretty sure everything would have come back "patch immediately," which doesn't help much with triage.

Then there's the hosting side. WP Engine took care of PHP for me. I also had no say in when it happened. That works when a bad week comes once a year. If it's every month, "my host will handle it" is a dependency I need to think about, because I'm trusting their timeline every time a runtime CVE drops.

Everyone is an 'expert'

X had a field day when some turd cyber correspondent Joe Tidy said he didn't know PHP existed until yesterday morning. He called it "one of these things we take for granted."

It's funny for about five seconds. Then it's sad. He has "cyber" in his title, and the BBC put him on air to explain the risk to millions of people.

I don't think that problem stops at the BBC. Plenty of companies have someone with security in their title who has never read a CVE advisory end to end, and plenty of engineers assume security belongs to that person. Will AI make this worse, IDK yet. An agent will tell you it patched the vulnerability with the same confidence whether it did or not, and it's easy to sound like an expert when a model wrote your summary or gives your the proverbial 'LGTM 👍'.

ICs need to know enough security best practices to ask whether this affects us and to check the answer themselves.

CVE and exploit volume is only going up, so we need to stay hyper vigilant without burning out on it or going 'not my monkey not my circus'.