sudodrift

Breach Notes, Oct 24 to 30, 2026: Binance's record theft and a week of logins nobody was watching

Eight incidents from the past seven days, what is confirmed, what isn't, and the one or two things I would do about each before the weekend.

· By sudodrift · RSS feed

By sudodrift

This is the first weekly roundup. Every Friday I’ll take the incidents that were reported in the last seven days, strip them down to what the company or a solid source has actually said, and add the checks I would run. Where I already wrote a longer piece on one of them, I link it instead of repeating it.

Dates are Toronto time unless I say otherwise. If a number below comes from an attacker rather than the victim, I say so.

A week-at-a-glance chart, Saturday October 24 to Friday October 30, 2026, placing each incident on the day it was reported: PingCAP's extortion group posts a first batch of data by the 25th, Anthropic and Warp disclose on the 26th, Fore Coffee and the FileMaker attack brief land on the 27th, Japan Airlines and the Gitee scan on the 28th, the Binance theft on the 29th, and Cathay Pacific plus Binance's laptop update on the 30th.

Security breaches

1. Binance: about $6.3 billion moved out in an afternoon

On Thursday, October 29, roughly $6.3 billion in crypto left Binance wallets. Blockchain analytics firm TRM Labs puts the start at 20:05 UTC, which is 4:05 PM here, and says most of it moved within about 20 minutes across ten chains. On TRM’s numbers it is the biggest crypto theft ever recorded, roughly four times what Bybit lost in February 2025.

Confirmed by Binance, per BleepingComputer and the BBC: its first read is that a DevOps engineer’s laptop was compromised, that this led to a service container, and that withdrawals were submitted from there. Co-CEO Richard Teng says it was a multi-step attack, not one person’s permissions, and that there’s no sign so far of a wallet private key leak. Binance later said it had found more points of breach and is still collecting facts. It has paused deposits and withdrawals and says it will cover all losses from its SAFU fund and its own money. Binance.US says it is not affected.

Not confirmed by Binance: who did it. TRM and Chainalysis both attribute it to TraderTraitor, the North Korean unit also tracked as Lazarus. Stablecoin issuers and Arbitrum froze around $2.7 billion, per TRM, which leaves the attacker holding a lot that can’t be frozen. How the laptop was compromised, and what the other breach points are, is not public.

What I would do:

  • If you hold a Binance account, ignore every “claim your compensation” or “re-verify your wallet” message this week. Binance itself warned about scams around the incident. Open the app or type the address yourself.
  • If you run anything that moves money or signs transactions, write down which workstations can reach the systems that submit withdrawals. If an engineer’s laptop is one hop from that path, that is the finding, whatever else you have in place.

2. Amadeus: an airline booking system with outside access going back to 2023

Amadeus runs the passenger service system that a lot of airlines use for reservations, ticketing and check-in. This week the airlines started telling their customers that someone had been inside it.

Japan Airlines says Amadeus told it on October 23 that it had found traces of outside access running from August 10, 2023 to September 23, 2026. About 92,000 JAL and Japan Transocean Air customers are involved. For about 90,000 that means booking code, name, flight date, route and class. For about 2,000 it also includes email, phone, passport number, nationality and frequent flyer number. JAL says no card numbers or passwords were exposed.

Cathay Pacific followed on October 30 with about 53,000 bookings. Its notice adds a detail I care about: the unauthorised party used login credentials assigned to a system account. Amadeus has reset the password and added monitoring, according to Cathay. The Business Times lists Korean Air, Asiana, ANA (around 37,800 passengers, as reported) and Jin Air as affected too, with Bloomberg reporting Condor.

Not known: I couldn’t find a public statement from Amadeus itself, so the total number of airlines and passengers is unknown. Nobody has said how those credentials were obtained, or why access traces spanning three years weren’t caught sooner.

What I would do:

  • If you flew with any of these airlines since mid 2023, expect phishing that quotes a real booking code and a real flight. That detail is not proof. Change or check bookings only by typing the airline’s address yourself, and set a PIN or extra login step on your frequent flyer account if the airline offers one.
  • If you run a system that partners log into with shared service accounts, check when each one last had its password changed and whether you would even notice a login from a new place. Three years is a long time for a login to work unseen.

3. PingCAP: the extortion group started posting data

PingCAP, the company behind TiDB, had already confirmed that an intruder was in its internal network from September 9 to October 7, and that support tickets holding customer credentials were taken. The news this week was the other side. As InfoQ reported on October 25, the group FulcrumSec released a first batch of five archives, about 128 GB compressed, out of a claimed 10.6 TB.

The group’s claims are unverified. It says it holds more than 115,000 console API keypairs in plaintext, which PingCAP’s own statements contradict, plus around 1,800 database endpoints from customer migration jobs, some with root or admin logins. PingCAP still says it has found no evidence that data inside customer TiDB databases was touched.

What I would do: replace your TiDB Cloud management API keys, then rotate anything you ever pasted into a PingCAP support ticket and every migration job’s source login. I wrote the full steps, including a small ticket scan script, in the PingCAP post on sudodrift.github.io.

4. Fore Coffee: up to 5.7 million accounts through Metabase

Indonesian coffee chain Fore told the stock exchange on October 27, and said in a public statement on October 28, that customer data was accessed through its Metabase platform. Its own estimate is up to about 5.7 million accounts. Depending on the customer, that covers name, email, phone, birth date, gender, saved address, purchase history and a hashed PIN. Fore says the access came through accounts that should not have been there, that it revoked them, and that card data sits on a separate platform that wasn’t touched.

Not confirmed: how those accounts got in, when it started and which Metabase build was running. Fore has not linked this to CVE-2026-72898, the Metabase password reset SQL injection that CISA added to its exploited list in August. I suspect an old build, but that is my guess.

What I would do: Fore customers should change the app PIN and any other PIN that uses the same digits. If your team runs Metabase anywhere, read its version from /api/session/properties today and compare it against the fixed builds. My Metabase check post has the version table, a log check and the audit queries.

5. FileMaker Server: password spraying, and a host pulled every server

On October 27, Proof, which runs the Ottomatic FileMaker hosting service, published a brief on a coordinated attack. It says the attack reached Ottomatic’s managed servers on October 22, and that it shut down all of them on October 25. It is treating every FileMaker Server Admin API key on those servers as compromised. The New Zealand school software vendor KAMAR told its schools on October 28 that Claris had warned of password spraying against FileMaker Servers worldwide.

Not known: who is behind it, how many servers were actually broken into rather than tried, and how the Ottomatic Admin API keys were exposed. I still can’t find a public copy of the Claris advisory that KAMAR mentions.

What I would do: if you run FileMaker Server, kill or rename any account called admin, turn off Guest access, keep the Admin Console reachable only from known addresses, and rotate your Admin API keys. Then update to 26.0.3 if you haven’t. Log checks and the full list are in the FileMaker post.

AI breaches

6. Anthropic: AI agents got in through third-party business software

The Washington Post reported on October 26 that Cathedral, a young security startup founded by former DOGE staff, used AI agents to get into Anthropic’s internal systems. It did this through a bug bounty style program. The way in was not Claude. It was outside admin and sales software that Anthropic uses, and that plenty of other companies use too. Cathedral’s draft report says its agents reached meeting transcripts, pay and job offer details, and Slack messages within 12 hours.

What Anthropic confirms, per Decrypt and The Decoder: the researchers reached some of its sales, HR and IT systems, which held business contacts and basic account data. It says Claude conversations, source code and model weights were not. It cut the access the same day, switched off the affected third-party tools until their vendors fixed them, and told federal authorities.

Disputed: Anthropic says the probing went on for several days, not 12 hours, and that Cathedral didn’t disclose everything and went beyond the program’s safe harbor. Cathedral’s position is that it touched as little data as it could. A former OpenAI employee claims the Slack access went much further, and Anthropic says his sources are wrong. The vendors have not been named.

What I would do: pull the list of third-party apps connected to your Slack, CRM and HR system, sort by scope, and remove the admin-level ones nobody can justify. My honest take is that the AI part of this story matters less than the third-party part. Agents just make it cheap to keep knocking on every side door you forgot about.

7. Warp: agent traces and telemetry reached through a vendor

Warp’s CEO said on October 26 that someone exploited a vendor in Warp’s infrastructure on October 23, and that the attacker got to “a limited amount of agent trace and telemetry data.” Warp’s current ceiling is about 1% of its users, and it notified the people it could identify. CrowdStrike is helping. BleepingComputer notes Warp has not said whether prompts, code or credentials were in that data.

Not known: the vendor, the flaw, the exact fields, and when access started.

What I would do: if you ran Warp’s agent with real keys in the session, rotate those keys now instead of holding out for Warp’s final report, and turn on Secret Redaction, which is off by default. The Warp post shows how to scan your local Warp database for keys.

8. Gitee: 26,400 live keys, many of them for AI services

A researcher scanned 7.25 million public Gitee repos and found 26,400 credentials that still worked. It was published on October 28 as a guest post on MongoDB’s blog, and MongoDB makes one of the two scanners used. Alibaba Cloud keys were the biggest group at about 9,400. DeepSeek, Zhipu and OpenAI keys were near the top, and one was an org admin credential for an unnamed enterprise AI platform. Nearly half were committed in 2025. The two scanners overlapped on only 1,001 keys.

Not known: whether the vendors have revoked them yet, and whether anyone else used them first.

What I would do: scan the full git history of your own repos with two different scanners, then revoke at the issuer anything that shows up. Deleting the commit doesn’t help a key that is already cloned. The Gitee post has the two-scanner commands.

The pattern this week

Almost every item comes down to a login or a key that kept working. An engineer’s laptop led to a container that could submit withdrawals. Someone used a system account’s login on an airline booking platform, with traces of access going back three years. Support tickets held customer passwords. Keys sat in old commits, and possibly in agent traces.

Two caveats so I don’t oversell it. Fore and Anthropic haven’t said exactly how the first foothold happened, and Binance’s investigation is days old. But the boring advice keeps being the right advice. Know which credentials can reach your important systems, notice when one is used from somewhere new, and rotate the ones that have lived in tickets, chats and repos.

A checklist titled What to do this week, with six cards: check third-party app access in Slack, CRM and HR; rotate keys that ever sat in support tickets, agent sessions or repos; review service account logins and their last password change; treat booking-aware airline messages and crypto compensation offers as suspect; patch and lock down Metabase and FileMaker Server; scan your git history with two scanners.

Tool of the week: keydrift

Half of this week’s items end with “rotate the keys”. The hard part is knowing which keys you even have on your machine. keydrift is the small tool I wrote for that. It runs on Linux and macOS and reads the places keys tend to end up: AI agent logs and history (Claude Code, Codex, Gemini CLI, Cursor and others), shell histories, .env files and tool configs like ~/.aws/credentials and .npmrc. It lists what it finds without printing the values, then gives you a rotation order with links to each provider’s revoke page.

It only reads files, runs nothing it finds and makes no network calls. It is free and MIT licensed. It also has checks for a few recent incidents (LiteLLM, the OVHcloud CLI swap, Railway, Zeabur and OpenCode).

What it doesn’t do, plainly: it can’t see keys that only live on a vendor’s side, and it doesn’t read Warp’s local database yet, so for Warp use the script in the Warp post. A clean scan means it didn’t find anything in the places it knows, not that you are clean. And one naming note: the KeyDrift malware that Cisco Talos wrote up this week for Cisco SD-WAN is unrelated. Same name, nothing to do with this tool.

If you also run sudodrift, my access drift tool, on real servers, there’s a paid Pro Pack for $24 with hardening configs and an access review kit. The tools themselves stay free.

Sources

Weekly Breach Notes sends this roundup every Friday, free: subscribe here.