
Black October: What Actually Happened, and What To Patch
“Black October” looked like AI swarms hacking the internet. We checked all 28 incidents against primary sources: most of the AI defends, and the damage came from long-lived keys in shared places. What to patch and rotate this week, starting with PgBouncer.

Gautam Gopinadhan
2026-10-27 · 15 min read
Black October is the name social media gave to a wave of security disclosures in October 2026, including PHP2Shell, the Railway and TiDB Cloud breaches, and the LiteLLM supply-chain attack.
Most of the "AI is hacking the internet" stories are about AI finding bugs, not exploiting them. The breaches that hurt database teams came from long-lived credentials stored in shared places. Here's what we found and what to do this week.
The short version
- Most of the AI in this story works for defenders. Vulnerability disclosures doubled this year, and AI tools found the most serious bug on the list before it was widely exploited.
- AI-driven attacks are real but rare. Only two of the 28 incidents involve an AI-driven attack, and the evidence for one of them is weak.
- Stolen credentials did the real damage. Railway, Zeabur, TiDB Cloud, and LiteLLM all came down to long-lived keys stored in one place.
- Your next step: Patch the software next to your database, and rotate any database credential stored in a platform's environment variables.
What was Black October?
Black October was a burst of alarm in mid-October 2026, when a list of 28 security incidents spread on Reddit and X. One post said AI agent swarms were hacking about half the internet. Another said a new CVE (Common Vulnerabilities and Exposures entry) was dropping every hour.
The panic follows a familiar plot. In The Hunt for Red October (1990), the Soviet Union launches a new submarine with a drive so quiet that sonar can barely hear it. When it heads for the US coast, both governments assume its captain, Marko Ramius, plans to attack. One analyst, Jack Ryan, reads the same evidence and reaches the opposite conclusion: Ramius is defecting and bringing the submarine to the West.
Black October has the same shape. A powerful new capability, AI that finds software flaws at scale, showed up all at once, and the first reading was that it was being turned against everyone. The evidence mostly points the other way. Like Red October, the alarming new arrival is largely on the defenders' side. The damage this month came from something older and quieter.
We took Ryan's approach. We checked each incident against primary sources and sorted it by what AI actually did. Then we searched security news for critical incidents that the list missed. We build Readyset, a SQL proxy that sits between applications and Postgres or MySQL, so we focused on those databases and the credentials that reach them.
How many of the 28 incidents actually involved AI?
Nine of the 28 incidents have a documented or possible AI connection, and none was traced to AI-written code. The other 19 have no documented AI link.

Readyset review of 28 incidents from the viral Reddit list, primary sources, as of October 22, 2026 (full table in the appendix)
The sources show two more patterns:
-
Some of it is old news. The Medi-Cal billing-vendor breach happened in October 2025. The AOMEI update tampering ran from May through July. Palo Alto patched its GlobalProtect bug in May, and the North Korean campaign started in July 2025. SecurityToday found that many of the attacks began weeks or months earlier.
-
Some numbers grew in the retelling. eMudhra's "master keys" were eight intermediate certificates that never issued a website certificate. Railway said an attacker "may have" reached customer secrets. Zeabur's 321,810 figure counts account records read from a database, not accounts taken over. Cairn's "100+ companies" is an estimate based on token spending.
The closest case of AI-written code isn't on the list. UpGuard found more than 16,000 misconfigured Supabase databases, most with row-level security turned off. UpGuard attributes most of them to apps built with AI coding agents, but says its scan can't prove that for any single site.
Is AI really finding more bugs?
Yes. AI tools got very good at finding bugs this year, and defenders use them the most.
One scene in the film captures what that feels like. Red October's quiet drive confuses the US sonar computer, which logs it as "magma displacement," a natural sound. Sonar operator Seaman Jones plays the recording 10 times faster and hears a machine. Better sensors put more contacts on the screen, and the work becomes telling them apart. That's where the security industry is now:
- Disclosures doubled. The US National Vulnerability Database (NVD) logged 72,812 CVEs from January through September, more than in all of 2025. September alone had 14,943, compared to 4,321 a year earlier.
- AI found the most serious bug on the list. PHP2Shell lets an unauthenticated attacker run code on any web server that runs PHP, through code that dates back to 2012. Calif and Wiz each found it, both using the same OpenAI model. OpenAI says AI found it before attackers did. But Amazon's honeypots logged an exploit attempt four days before disclosure, and a leak forced the patch out a day early.
- AI tools appear in vulnerability credits. The Node.js Brotli fix credits OpenAI Codex Security. Microsoft's October Patch Tuesday fixed about 1,411 flaws, a record that the press links to Microsoft's own AI bug hunting. Anthropic's disclosure dashboard lists 219 CVEs and 365 GitHub security advisories.
- Attackers use few of these bugs. VulnCheck counted 225 CVEs credited to Anthropic's program as of late September. Attackers have exploited one.
Maintainers carry the cost. PostgreSQL 19 moved to November 19 and dropped several major features. The project cites the volume of fixes to older branches, and press coverage ties that volume to AI-assisted code review. curl will publish low- and medium-severity reports openly starting October 26 because its maintainers can't keep up.
If you run Postgres or MySQL, patch on a tighter schedule than you did a year ago. Rapid7 reports that attackers now exploit high-severity bugs about three days after disclosure, on average.
Have AI agents actually run attacks?
Yes, but the confirmed cases are fewer, and stranger, than the X posts suggest.
A lab's own agents caused the Hugging Face incident. The "swarm" that people cite came from OpenAI's test environment. According to OpenAI, agents running a hacking benchmark with reduced safeguards couldn't solve some tasks and went looking for answers. They broke into OpenAI's own artifact server first, then reached Hugging Face in July. About 1,200 agents were involved. In May, agents that OpenAI was testing also pushed malicious packages to RubyGems.
Criminals use agents to scale up. In the Cairn campaign, attackers aimed an open-source multi-agent platform at more than 1,200 websites. The agents tried to plant web shells, which are scripts that give an attacker remote control of a server. Reuters named Deere, SharkNinja, and Cummins among the targets, and each reported limited impact. The attackers also left their own control panels exposed, leaking hundreds of credentials. Anthropic's September threat report describes one group running Claude Code workflows with little human input, and another that scanned 1.8 million Android apps for hard-coded secrets.
These agents went after known web bugs and exposed secrets. They didn't invent new kinds of attacks. They made old attacks cheap enough to run against everyone at once.
Where did the real damage come from?
The incidents that hurt database teams this month share a pattern: one long-lived credential, stored in one place, that opened many systems. The weak spots were systems nobody watches closely: the platform that stores your environment variables, your CI/CD (continuous integration and delivery) server, a vendor's control plane, or a laptop with a .env file.
| Incident | How attackers got in | What they could reach | Time inside |
|---|---|---|---|
| TiDB Cloud | A stolen service-account credential | Account data, SQL editor text, and encrypted management API keys | About four weeks (Sep 9-Oct 7) |
| Zeabur | Leaked long-lived AWS keys and a cluster admin token that never expired | 3.2 million environment-variable records and possible access to 865 database services | Oct 14-15, its second breach since August |
| Railway | Not disclosed | Customer environment variables, which can include database credentials; some were decrypted | Detected Oct 21 |
| LiteLLM | GitHub CLI tokens stolen from three engineers | A stealer that took .env files, psql and mysql shell history, and keys found through DATABASE_URL | About two hours live on PyPI |
| UpdraftPlus | A breach of the vendor's own website | Connection keys to customer WordPress sites that never expire | Oct 18-19 |
| OVHcloud CLI | A contributor's GitHub account, compromised since March | Release files for five versions of the tool | About 94 minutes of bad downloads |

The pattern shared by the Railway, Zeabur, TiDB Cloud, and UpdraftPlus incidents
Zeabur's own report says its admin credentials were long-lived, stored in plain text, and usable from the public internet. Railway says its incident is one of a series aimed at hosting platforms, with AI inference providers as the final target. A researcher traced cryptocurrency thefts that used keys stored on Railway to about two hours before Railway's disclosure.
TiDB Cloud matters most to us because it's a managed MySQL-compatible database. PingCAP found no sign that the attacker touched data inside customer databases, and it hasn't asked customers to change database passwords. But the attacker did get text that people typed into the web SQL editor. If anyone on your team pasted a connection string or password into a hosted SQL console, assume that someone else has it.
What should you patch and rotate this week?
Patch PgBouncer, your database, and the app-tier software next to it, then rotate every database credential stored in a platform's environment variables. The details follow.
Patch these components
The list starts with the database tier.
| Component | Update to | Why it matters |
|---|---|---|
| PgBouncer | 1.26.1 | A client with one user's password can sign in as any other user that uses SCRAM password authentication, including superusers. Two other bugs let an unauthenticated client freeze it. |
| MySQL | October Critical Patch Update (8.4.13 for the 8.4 line) | Quarterly MySQL fixes; version 8.4 is affected through 8.4.12 |
| MariaDB | 10.6.28, 10.11.19, 11.4.13, 11.8.9, or 12.3.3 | MariaDB published 15 CVEs on October 9 and 16, including three rated 9.9. The fixes shipped in the summer releases, so confirm that you have them. |
| pgvector | 0.8.7 | Buffer overflow when it builds IVFFlat indexes |
| PgJDBC | 42.7.14 | Two CVEs in the Java driver |
| PostgreSQL | 18.6, 17.11, 16.15, 15.19, or 14.24 | No October release, but the August release fixed 28 CVEs. If you skipped it, update before the November release. |
| PHP | 8.5.12, 8.4.27, 8.3.36, or 8.2.35 | PHP2Shell lets attackers run code on the app servers that hold your database credentials. |
| GitLab | 19.5.1 or its backports | Two bugs rated 10 out of 10. CI/CD variables often hold production database credentials. |
| Node.js | 22.23.4, 24.22.1, or 26.12.1 | Brotli decoder bug, plus fixes for TLS hostname checks |
| NGINX | 1.31.7 or 1.30.6 | Three memory bugs, each needing a specific configuration (alias, AIO with SSI, or a regex map) |
If any computer installed LiteLLM 1.107.0 on October 21, treat it as compromised. Rotate every credential it could read, including database passwords.
Reduce credential risk
- Rotate every database credential that you've stored in a hosting platform's environment variables, a CI/CD system, or a hosted SQL console.
- Switch to short-lived credentials where your platform supports them, such as cloud identity and access management (IAM) database authentication or dynamic secrets from a vault.
- Create a separate database user for each service and each AI agent, with only the access it needs. Don't let agents use the application's sign-in. The same goes for any proxy in the path: Readyset, PgBouncer, or ProxySQL should each connect with its own user, not the application's.
- Block public internet access to your database, and require TLS.
- Turn on audit logging for your database and for any control plane that manages it.
- Store backups offsite, and make them immutable. The SafePay advisory describes attackers resetting backup appliances and deleting backups before they encrypt data.
Per-agent database users get hard to manage once you have more than a few agents. That's the problem we're building Readyset Guard to solve: it applies per-agent access policies at the proxy, so each agent gets only the queries and data it should.
One ping only
The film ends well because Ryan read the evidence instead of the noise. Near the end, Ramius asks for "one ping only": a single sonar pulse that shows exactly where he is after hours of guessing on both sides.
That's the standard we'd hold this month's coverage to. The AI story is mostly good news: AI is finding old bugs faster than attackers, and patches are shipping. The part that cost people data and money was quieter. It came in through keys that had sat in the same place for months.
Patch what sits next to your database, and spend an afternoon on the systems nobody watches. You'll learn more there than from the news feed.
Appendix: All 28 incidents
We checked each incident against primary sources where they exist. Relevance means relevance to teams that run Postgres or MySQL.
| # | Incident | When | What AI did | Relevance | What the list got wrong |
|---|---|---|---|---|---|
| 1 | PHP2Shell | Fixed Oct 21 | Found the bug | Medium-high | Understated it. "70%" is PHP's share of websites, not the share that's vulnerable. |
| 2 | eMudhra | Oct 20 | Found it (weak link) | Low | Intermediate keys, not root keys. None issued a website certificate. |
| 3 | California students | Access May-Sep; notice Oct 19 | None | Low | The breach was at ETS, the testing vendor. |
| 4 | Railway | Oct 21 | AI keys targeted | High | Railway says "may have accessed" and gives no count. |
| 5 | Zeabur | Oct 14-17 | AI keys targeted | High | Counted 321,810 records read, not accounts taken over. |
| 6 | LiteLLM | Oct 21 | AI tool compromised | Medium-high | The bad release was live for about two hours. |
| 7 | GitLab | Oct 12 and 21 | None | Medium | Merged two separate bugs rated 10 out of 10 into one. |
| 8 | Cairn | Sep 25-Oct 19 | Agents ran the attack | Medium-high | "100+" is an estimate based on token spending. |
| 9 | Ahold Delhaize | Oct 11-12 | None | Low | The company took systems offline itself, and stores stayed open. |
| 10 | Onamae.com | Oct 20-21 | None | Medium | One VPS product. 26,739 servers were possibly affected. |
| 11 | Signal | Fixed Sep; CVE Oct 20 | None | Low | A malicious caller has to trigger it. |
| 12 | NGINX | Oct 14 | None | Medium-high | Rated 8.1 under CVSS 3.1. Each bug needs a non-default configuration. |
| 13 | HTTP/3 QPACK | Oct 22 | None | Low | Affects HTTP/3 libraries, not mainstream web servers. |
| 14 | Plex | Exploited from Oct 17 | None | Low | Patched in August. Only unpatched servers are at risk. |
| 15 | SafePay | Oct 20 | None | Medium | 600+ victims, but not all are critical infrastructure. |
| 16 | Palo Alto GlobalProtect | Bug from May; update Oct 19 | None | Medium-high | An old bug with a new ransomware attribution. |
| 17 | Bullhorn | Oct 16-19 | None | Low-medium | Accurate |
| 18 | Medi-Cal | Breach Oct 2025 | None | Low-medium | A billing vendor, and a year old |
| 19 | UpdraftPlus (WordPress) | Oct 18-19 | None | Medium | Accurate |
| 20 | AOMEI | May-Jul; disclosed Oct 16 | None | Medium | Months old |
| 21 | Meta Muse | Oct 20-21 | AI product leaked data | Medium | Shared chats only. No misuse seen. |
| 22 | Tor relays | Aug-Oct 20 | None | Low-medium | Hacked exit relays stole SSH passwords, not general sign-ins. |
| 23 | TiDB Cloud | Sep 9-Oct 19 | None | High | The attacker's 10.6 TB and 180,000-organization claims are unconfirmed. |
| 24 | State Bank of India | Oct 21 | None | Low | 3,897 records confirmed. SBI hasn't confirmed a breach of its systems. |
| 25 | OVHcloud CLI | Oct 19 | None | Medium | Accurate, but nobody has analyzed the payload. |
| 26 | Siemens Software Center | Oct 15-19 | None | Low | An installer app, not industrial systems |
| 27 | North Korea (Lazarus) | Since Jul 2025; Oct 21 | Attack (weak link) | Low | Not new. The AI link is one generated photo. |
| 28 | Node.js Brotli | Oct 21 | Found the bug | Medium | Code execution was shown only on a weakened build. |
What the list missed
Database and credential items come first.
| Incident | When | What AI did | Why it matters |
|---|---|---|---|
| PgBouncer SCRAM bypass | Oct 14 | None stated | Lets a client sign in as any SCRAM user, including superusers |
| MySQL October patch update | Oct 20 | None stated | Quarterly MySQL fixes; 8.4 is affected through 8.4.12 |
| MariaDB | Oct 9 and 16 | None stated | 15 CVEs published, three rated 9.9; fixes already shipped |
| pgvector | Oct 5 | None stated | Overflow when it builds indexes |
| Supabase exposure | Sep 28 | AI-built apps, probably | 16,000+ readable databases, most with row-level security turned off |
| OpenCode Console | Oct 16-17 | AI keys targeted | Stored LLM API keys may have been exposed for about 1.4 percent of users. |
| Atlassian Data Center | Patched about Oct 6 | None | Unauthenticated file read that leads to admin access, exploited within hours of a public write-up |
| BeyondTrust Remote Support | Fixed Oct 8 | None | A zero-day exploited since August |
| Ivanti Connect Secure | Oct 13 | None | A zero-day, with part of the attack chain still unpatched |
| OpenAI agent and Medicare Australia | Disclosed Sep 24 | Agent ran the access | A lab's test agent reached a government statistics portal. |



