Key Takeaways
October 2026 brought breaches across cloud, finance, and developer infrastructure.
Stolen credentials and unpatched vulnerabilities enabled several high-impact attacks.
Incidents exposed risks across platforms, software supply chains, and services.
Rotate secrets, secure devices, restrict access, enable MFA, and patch promptly.
The month the keys walked out
On October 29, about $6.3 billion left Binance's wallets, most of it in roughly 20 minutes. Binance traced it to one engineer's compromised laptop. Two weeks earlier, a cloud host called Zeabur was breached with admin tokens nobody had changed since January 2024. It later chose to shut down, partly because of the breaches.
Most of October's incidents weren't clever new attacks. Someone got hold of a key, or found a door that should have been locked. Below are eleven, in date order.
Each one is checked against the company's statement, a vendor advisory or a government notice.
Does this affect you?
Run your own GitLab server, PHP website or Palo Alto firewall? Patch now (Figure 4).
Kept keys on Zeabur, Railway or OpenCode Console? Rotate them.
Installed LiteLLM 1.107.0? Treat that machine as compromised.
The eleven incidents in date order.
Words you'll see in this article
Term | What it means |
|---|---|
API key or token | A long secret string that works like a password for software. |
Environment variable | A setting stored next to an app. Developers often keep keys here. |
CVE and CVSS | A CVE is a bug's ID number. CVSS scores its severity from 0 to 10. |
Zero-day | A flaw attackers use before a fix exists. |
Rotate a key | Cancel the old key and issue a new one. |
Root | Full control of a computer. |
Private key | The secret that proves who owns a crypto wallet or a certificate. |
Container | A packaged app running on a server. |
Stablecoin | A crypto token pegged to a currency like the US dollar. |
GitLab: two perfect-10 bugs in nine days (Oct 12 and 21)
What happened:
GitLab is where many companies keep their code. On October 12 it fixed CVE-2026-97229, scored 10.0. On October 29, CISA added it to its list of bugs used in real attacks. On October 21 came a second 10.0, CVE-2026-110264, reaching back to version 7.0.
How they got in:
With the first bug, a specially crafted pattern in a CI/CD configuration, the file that tells GitLab how to build code, lets someone with no login run code on the server. GitLab says the second "could have allowed an unauthenticated user to execute arbitrary code." Both are integer overflows: a number grows past its limit and wraps around, like an old car odometer rolling back to zero. No attacks on the second bug have been reported.
What to do:
GitLab.com is already patched. Self-managed servers need 19.5.1, 19.4.3, 19.3.6 or an older branch's backport. A server patched on October 12 is still exposed to the second bug. Running GitLab on your own Ruby? Upgrade Ruby to 3.3.13, 3.4.12 or 4.0.9+ too.
Palo Alto PAN-OS: a firewall zero-day (Oct 14)
CVE-2026-0322 lets an attacker who already has credentials and network access to the firewall's management page run code as root. Palo Alto said "very limited exploitation" had been observed, and CISA gave federal agencies three days to fix it. There is no workaround: upgrade, and allow the management page only from trusted internal addresses.
Zeabur: keys nobody changed (Oct 14 to 15)
What happened:
Zeabur hosted apps for developers. An attacker reached its shared cluster in nine regions, signed in as root on 101 dedicated servers and read the platform database: data for 321,810 accounts and 3,218,965 environment-variable records.
How they got in:
Zeabur says the attacker used "leaked Zeabur internal credentials": AWS keys and cluster admin tokens. The admin tokens "had no expiry, had not been rotated since they were created in January 2024." They sat in plain text in a private repository, and the admin interface was open to the internet. Picture a master key nobody changed for 1,008 days. Zeabur's reset after an August breach "did not cover the cluster admin tokens and AWS keys."
What to do:
Zeabur will stop all services by December 31. Customers should rotate every secret stored there and move their apps.
How far Zeabur's old admin tokens and cloud keys reached, using counts from Zeabur's report.
OpenCode Console: AI keys in someone else's hands (Oct 16 to 17)
What happened:
OpenCode is an open-source AI coding agent. Its optional hosted Console stores teams' AI provider keys so members can use models without seeing them. On October 16, an intruder reached a legacy Console system. OpenCode said the keys of 1.4% of Console users "may have been exposed," covering OpenAI, Anthropic and Google.
How they got in:
OpenCode hasn't explained the entry point. It linked the breach to "a large-scale distillation attack," where someone floods a big model with questions to train a copycat. Keys saved in the OpenCode command-line and desktop apps stay on your computer and weren't affected.
What to do:
Deleting a key from Console doesn't cancel it. Revoke it in each provider's dashboard, check billing from October 16 and set spending limits.
eMudhra: certificate keys anyone could guess (Oct 17)
eMudhra is an Indian certificate authority, one of the companies that vouch for the padlock in your browser. A researcher found that eight of its intermediate certificates had private keys with "values smaller than 256," so anyone could guess them in 256 tries and forge trusted certificates. Mozilla blocked them on October 17, and Chrome blocked the six that could issue website certificates. eMudhra said it found no evidence they were misused, and it is winding down its global TLS certificate business. India's Digital Signature Certificates and eSign are unaffected, according to India's IT ministry.
GMO Onamae.com Desktop Cloud: a hidden program (Oct 20)
What happened:
GMO Internet rents out cloud desktops, and many customers ran trading tools on them. On October 20 it found an unauthorized program on some customer servers. It shut down every plan the next morning and counts 26,739 servers as potentially affected.
By October 24, GMO confirmed customer information was taken. It warned that saved trading-account logins may have been misused. It received a ransom demand and refused to pay. TechCrunch reports a demand of about 8 billion yen (about $50 million); GMO's notices give no amount. Each customer gets ¥5,000, plus compensation for confirmed unauthorized trades.
How they got in:
GMO hasn't disclosed the entry point.
What to do:
GMO asks customers to use a clean device to log out of all trading sessions, change FX, securities and email passwords, and turn on multi-factor authentication.
Railway: secrets decrypted (Oct 20 to 22)
What happened:
Railway, another hosting platform, says attackers decrypted some customers' stored environment variables. At most 1.85% of workspaces, "about 100,000," may be affected.
How they got in:
The first entry point isn't public yet. Inside, attackers may have gained higher privileges in Railway's build systems and took credentials for its CI pipeline, the system that builds and tests code.
What to do:
Rotate every sensitive key stored on Railway before October 21.
LiteLLM 1.107.0: poisoned at the source (Oct 21)
What happened:
LiteLLM is a Python library that lets apps talk to many AI models through one interface. Attackers published a fake version 1.107.0 to PyPI, Python's main package store, and to Docker. It carried malware that steals credentials.
How they got in:
They held three developers' GitHub login tokens. One overrode the release safeguards, a second approved the release and a third deleted the records afterward.
What to do:
Don't start with pip: any Python run, pip included, restarts the malware. From the shell, delete cook.pth, cook.py, sitecustomize.py and their cached copies, then kill the hidden Python process. Rebuild from scratch on 1.106.2 and rotate every secret that machine could reach.
How long the poisoned release stayed downloadable, from LiteLLM's incident timeline.
PHP2Shell: a bug in the web's plumbing (Oct 21)
What happened:
PHP runs a huge share of websites, including WordPress. On October 21 the PHP team fixed CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. CISA confirmed attacks on October 26.
How they got in:
PHP says the risk is highest with Apache's mod_php, where a demonstrated attack works "before any application code runs." No login and no buggy plugin are needed.
What to do:
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.1 and older get no official release, though the team posted minimal source fixes for 7.4, 8.0 and 8.1. Anything older gets no fix from the PHP project, though some Linux distributions and paid support vendors backport one.
The versions that fix October's three big software bugs.
Node.js "Node2Shell": poisoned compressed data (Oct 21)
On October 21, Node.js, which runs the server side of many apps, fixed CVE-2026-111497, nicknamed Node2Shell, a bug in its built-in Brotli decompression code. Malformed compressed data can corrupt memory and let an attacker run code. Apps are exposed when they unpack compressed data from outsiders, for example through fetch() or Express 5's request parsers. Google, which maintains Brotli, scored it 9.2, and CISA listed it as exploited on October 27. Upgrade to Node.js 22.23.4, 24.22.1 or 26.12.1. Bun, Python's Brotli packages and Microsoft's .NET also needed fixes.
State Bank of India: customer data on the dark web (Oct 21)
What happened:
SBI said that of about 375,000 records (3.75 lakh) found on the dark web, 3,897 held customers' personal details. Those include names, mobile numbers, dates of birth, gender, email and home addresses, plus loan-related details. SBI says funds are safe, and the fields it listed don't include passwords, PINs or OTPs.
How they got in:
The source is still under investigation. SBI was alerted by its threat-intelligence provider, India's Defence Cyber Agency and CERT-In.
What to do:
Expect scam calls and texts that know your name and loan details. Never share an OTP, PIN or card number. Report fraud at 1930 or cybercrime.gov.in.
Binance: $6.3 billion through one laptop (Oct 29 to 30)
What happened:
Blockchain analysts TRM Labs say about $6.36 billion moved out of Binance wallets on ten blockchains from about 20:05 UTC on October 29. Stablecoin issuers and others froze about $2.7 billion, by TRM's count. TRM and Chainalysis attribute the theft to TraderTraitor, a North Korean state-backed group, and the FBI agreed on October 31. Binance hasn't named anyone.
How they got in:
Binance traced it to a DevOps engineer's compromised laptop. From there the attacker reached a service container and sent unauthorized withdrawals. Binance stresses it "was not a single 'one-click' action" and has found "additional points of breach." It sees no sign that wallet private keys leaked.
Binance's account of the path so far, with TRM Labs' figures.
What to do:
Binance says "User funds are safe" and will cover losses from its SAFU emergency fund and company money. By November 2 it said about 95% was covered.
Impact at a glance:
Incident | Impact |
|---|---|
PHP2Shell | 22.6M sites potentially exposed · exploited |
Binance | ~$6.3B stolen |
LiteLLM 1.107.0 | ~49,000 malicious downloads |
GMO Onamae Desktop Cloud | Up to 26,739 servers affected |
Zeabur | 321,810 accounts · 3.2M secrets read |
eMudhra | 8 certificates compromised |
GitLab | 11,300+ servers still exposed |
Railway | Up to ~100,000 workspaces' secrets exposed |
Palo Alto PAN-OS | Exploited · victims not disclosed |
OpenCode | 1.4% of users' API keys exposed |
SBI | 3,897 customers' data leaked |
Node.js (Node2Shell) | Exploited · Node.js 22, 24 and 26 affected |
Conclusion
Old admin tokens, three developers' logins, a laptop, a saved AI key: each carried far more power than anyone was watching. The bugs mattered, but the costliest losses came from access that was already sitting there. So give every key an expiry date, guard engineers' laptops, keep admin pages off the open internet and patch internet-facing software first.
Q1. What were the biggest infrastructure hacks in October 2026?
Major incidents included the Binance security breach, Zeabur credential exposure, GitLab vulnerabilities, the LiteLLM supply-chain attack, and PHP2Shell.
Q2. How did attackers compromise cloud infrastructure?
Attackers exploited leaked credentials, unrotated admin tokens, exposed management interfaces, compromised developer devices, and software vulnerabilities.
Q3. What is a zero-day vulnerability?
A zero-day is a software security flaw that attackers exploit before a fix is available. Such vulnerabilities can allow unauthorized access or remote code execution.
Q4. What is credential rotation, and why is it important?
Credential rotation means revoking old passwords, API keys, or tokens and replacing them with new ones. It limits the damage caused by exposed credentials.
Q5. How can businesses prevent infrastructure security breaches?
Businesses should rotate credentials regularly, protect developer devices, restrict admin access, enable multi-factor authentication, and patch internet-facing software promptly.
