You do not need to be breached to learn from breaches. Every month, defenders publish detailed accounts of what attackers did, and reading them well is one of the fastest ways to build judgement. This lesson gives you a method, then you apply it to a real case file: Beam's tracker of October 2026, Black October: every incident, what was taken, and what to do. All facts below come from that tracker and the posts it links.
The five questions
Ask the same five things of every incident. The point is that identical questions make different incidents comparable.
- Vector. How did the bad thing arrive? A package, a release, an update channel, a stolen login, a certificate?
- Credential. What access made it possible? A token, an account, a leaked admin key? (Often the real answer to "how", and the part defenders miss.)
- Exposure. What was taken or reachable? Secrets, customer data, the ability to run code?
- Status. For each fact: confirmed, reported, or only claimed? By whom?
- Action. What do you check, rotate, pin or update? Which single control would have mattered most?
Worked example: OVHcloud CLI
Entry from the tracker: Oct 19, OVHcloud CLI v0.11.0 to v0.15.0, contributor account hijack; release assets and checksums replaced; secrets on disk; confirmed by OVHcloud; action: v0.16.0 and rotate disk secrets.
- Vector: official release assets on the project's release page.
- Credential: a hijacked contributor GitHub account.
- Exposure: secrets on the disk of anyone who installed during the roughly 94-minute window.
- Status: confirmed by OVHcloud. Its founder said GitHub release immutability was disabled.
- Action: upgrade to v0.16.0, which is immutable; rotate everything on the disk, including OVHcloud API credentials. Most valuable control: release immutability, and for users, hashes recorded from an earlier trusted download.
That took one minute and told you which lesson to reach for: this was a build-and-release problem (Lesson 3), delivered as a trusted download.
Mapping incidents to the four routes
Do the same for more entries and a pattern emerges. Here are several from the tracker, placed against this level:
| Incident | Vector | Credential | Which lesson |
|---|---|---|---|
| Tensorlake npm 0.5.144 (Oct 8) | Rogue commit, then the release workflow published; preinstall payload | Repository write access | Malicious packages, build and CI |
| LiteLLM 1.107.0 (Oct 21) | PyPI wheels and Docker images built from an attacker-controlled repository | Stolen GitHub CLI OAuth tokens | Malicious packages, build and CI |
| Rank Math PRO 3.0.123 (Oct 15 to 16) | The vendor's own update channel for about 11 hours | Not stated in the tracker | Build and CI |
| TeamUpdraft (Oct 17 to 18) | Signed remote commands that installed backdoor plugins | Stolen UpdraftCentral connection keys | Build and CI |
| eMudhra (Oct 17) | Eight intermediate CA keys that could be computed | None needed; weak key generation | Trust stores |
| Zeabur second breach (Oct 14 to 15) | Platform database reached with admin credentials | Plaintext admin credentials left out of an August rotation | Credentials, not packages |
| Apex Accelerator (reported Oct 12 to 19) | Fake AI copilot and MCP packages on npm | None; the user ran it | Malicious packages |
Look at the credential column. Almost nothing needed a clever exploit. The tracker states the first pattern in plain words: "Stolen tokens, not zero-days. The exploit was usually a login."
Claimed versus verified
The same tracker keeps two entries separate from the rest because they are unconfirmed: OpenRouter (listed on dark-web trackers on October 20) and TiDB Cloud (claimed on social media), neither confirmed by the company at the time of writing. A careful reader treats them differently from Railway or LiteLLM, where the vendor itself published details. This habit has a name: keep apart.
Why not ignore claims entirely? Because the cost of acting differs. Rotating an API key is cheap, so the tracker's advice for OpenRouter is "rotate and cap keys anyway". Rebuilding your whole stack because of a rumour is not cheap. Matching the response to the evidence is the skill.
The State Bank of India entry shows another honest pattern: SBI confirmed 3,897 customer records in a dark-web set of about 375,000, but, per the tracker, the source is unknown. A good report says "not established" where it is not established. Be wary of any report that never does.
What the whole month says
The tracker's own pattern list is a good summary. In your words, after this level:
- Stolen credentials beat vulnerabilities. GitHub tokens, a contributor account, an application credential, connection keys, unrotated admin keys.
- Trusted channels carried the malware. Trusted publishing, release workflows, update servers, signed remote commands. Checks that ask only "did this come from the right place?" passed.
- Checksums and tags are not enough. OVHcloud's attacker replaced
checksums.txt; LiteLLM's attacker movedlatest. Immutable releases, digest pins and provenance checks are what hold. - Rotation that misses one credential is not rotation. Zeabur's second breach came from admin tokens left out after the first.
- Clean up before rotating when malware is active. Tensorlake's wipe switch is the example.
- Cheap prevention beats fast detection. Installs of the bad LiteLLM version were possible for about 100 minutes.
How AI changes this
AI keys are now the target. The tracker's fifth pattern: Railway's attacker aimed at AI inference providers, OpenCode described its incident as a large-scale distillation attack, and LiteLLM, Tensorlake and GhostAction all harvest AI tool credentials. A key to a model API is spendable and resellable.
AI-found flaws move faster. The tracker lists PHP2Shell, two PHP interpreter RCEs that were found with AI, leaked a day early and attacked before the fix. That is a genuinely new tempo: less time between discovery and exploitation.
Agents on your machine read the same files as stealers. The tracker notes that many of these stealers read the same files agents read: .env, .npmrc, SSH keys and AI tool configs. Knowing where secret copies live is the same exercise for both threats.
Using AI to read reports. An assistant can summarise a long incident post quickly, and it is useful for that. It can also blur the line between claimed and verified, or drop version numbers, so keep the five questions as your checklist and verify the specifics (versions, dates, indicators) against the primary source.
Same old problem: the tracker's own closing line, "the biggest security risk might not be the code we write, but the code we trust."
Try it
Build one case file. Choose one tracker entry that is not OVHcloud, and write a short note answering the five questions in your own words, with one sentence on what is confirmed and what is not.
Then apply it to a machine you own. Everything below is read-only:
# Are any of the affected packages in your projects?
grep -rIl "litellm" --include="requirements*.txt" --include="*.lock" ~/code 2>/dev/null | head
# Which Python startup hooks (.pth files) exist in your default Python?
ls "$(python3 -c 'import site; print(site.getsitepackages()[0])')"/*.pth
The second command lists startup hooks. Some are normal tooling files. The skill is learning what is normal on your machine so that an unfamiliar one stands out. If one surprises you, look up the package that owns it before deleting anything.
Check yourself
Name the five questions and say which one most often reveals the real cause.
Vector, credential, exposure, status and action. The credential question usually does: most October incidents began with a stolen or unrotated credential, not a new exploit.
A dark-web listing names a company as breached but the company has said nothing. What do you do?
Treat it as claimed, not verified. Do the cheap precautions (rotate and cap keys, watch for a statement) without assuming the breach is real or panicking, and look for the company's own confirmation before escalating.
Which control would have mattered most for OVHcloud CLI, and for Zeabur's second breach?
For OVHcloud, release immutability (and recorded hashes for users), because the attacker replaced release files and checksums. For Zeabur, a complete rotation after the first incident, because plaintext admin credentials were left out of it.
Why is a clean-looking scan result not the end of a supply chain investigation?
Scanners are heuristic and can miss payloads built at runtime, as the Beam package scanning documentation says. Treat a clean result as evidence for your review, and combine it with pinning, provenance and monitoring of what actually runs.
Next
That completes the supply chain level. Next, the course turns to AI agents directly: what changes when the software that installs packages and runs commands is itself an assistant working for you.