What Black October means for every engineering team

The last few days have been rough for anyone who runs software on the internet. On October 21, PHP shipped emergency patches for two critical remote code execution flaws now called PHP2Shell, found with help from AI. On the same day, Node.js and GitLab patched their own critical remote code execution bugs, and LiteLLM, a popular LLM proxy, published a malicious release that stole credentials.

Around the same time, developer platforms such as Railway and PingCAP disclosed breaches that touched customer secrets and source code. Microsoft described a group that used an agentic AI framework to reach more than 2,250 Microsoft 365 tenants through a single compromised third-party app.

The press started calling it AI's Black October. I want to share what I think it means for engineering teams. For me, the lesson is about speed more than any single CVE.

The clock is the real story

To be fair, a lot of this is a wave of disclosures, not a wave of new attacks. Many of these bugs sat in the code for years, and some of the breaches started weeks earlier.

What changed is the time between "this is public" and "someone is using it". PHP released its patches at 14:00 UTC on October 21, and exploitation attempts were seen 19 minutes later. This is not new, but it keeps getting worse. Google measured the average time to exploit at 63 days in 2018 and 2019, then 32 days in 2021 and 2022, then 5 days in 2023. Mandiant estimates it at minus 7 days for 2025, which means exploitation routinely starts before a patch is out.

AI pushes this further. The group Microsoft tracked made about 2,900 sign-in attempts per minute and, in some cases, reached privileged access in under three hours. CISA now expects US federal agencies to fix actively exploited, internet-facing bugs within 3 days, and it names AI as the reason.

I think of it like a burglar who used to walk the street checking windows one by one. Now they have a drone that checks every window on the street in minutes. The windows have not changed. Only how fast someone checks them has.

Old mistakes, machine speed

The entry points are ordinary. Mandiant makes the same point: most intrusions still come from basic failures, and AI mostly makes attackers faster.

Look at how this month's breaches started. Railway lost CI credentials. PingCAP had a stolen service account inside its systems for about four weeks. The Microsoft case turned on an app identity that already had access across thousands of customer tenants. These are credentials for machines, pipelines, and apps rather than people, the keys we create once and forget. AI API keys have also become loot, because attackers can resell the compute.

None of this needs new technology to fix. It needs the boring foundations to be in place before someone tests them.

Why we should treat this as the top priority right now

Security incidents hit the business directly. IBM puts the average cost of a breach at a record $4.99 million, and for AI-enabled breaches it is about $6 million.

When the market looks like this, security risk and awareness should get the highest priority and urgency, even when there is no evidence you are affected. Waiting for proof is the reactive option, and by the time proof arrives the attacker has had days.

The best outcome is no breach at all. The next best outcome is a breach you detect within minutes and contain decisively. Both require acting before you know you need to.

I also think this push should be time-boxed. A team in permanent war mode gets tired, and tired people make riskier security choices. Run an intense push with clear owners, then keep the priority high through normal engineering work.

What to do this week

Assume any single control will fail, and add layers so one failure does not become a breach. A VPN is one layer, not the answer. VPN appliances and other edge devices are among the most exploited targets.

Here is where I would start:

• Make everyone sign in again, and put every login behind SSO with strong MFA.
• Rotate secrets, including personal tokens, machine credentials, and AI provider keys, and watch for unusual usage.
• Reduce access to what people need today, especially for code and sensitive data. Restore the rest with expiry dates.
• Find everything that is exposed to the internet and patch it first. Include the small apps and tools people built quickly.
• Keep AI tools updated, and limit what AI agents can reach. An agent with access to everything a person can see is a large blast radius, which I touched on in MCP vs Skills.
• Invest in security monitoring and anomaly detection. You need to see unusual logins, access patterns, and traffic as they happen. If you have no visibility into your systems today, fix that first, because you cannot contain a breach you cannot see.
• Run it as one checklist, with one owner per item and a daily status.

After the push

The sprint should leave habits behind. Prefer short-lived credentials over static secrets. Set a deadline for patching actively exploited bugs on internet-facing systems. Keep SSO everywhere, scan for secrets in code and logs, and test that you can actually recover, the same way I argued for resilience after the AWS outage last year.

Black October will fade from the news. The speed will not.

If this perspective resonates with you, subscribe to my blog. You can also follow me on X or Threads for more thoughts on engineering and AI.