If your scripts, CI runners, or embedded devices use default TLS settings, eight eMudhra CA keys that were literally the numbers 4, 56, and 115 let anyone on the network path forge a valid cert for any hostname, and revocation does not reach you.
Eight eMudhra intermediate CA private keys on the P-384 curve were single-byte integers; the author recovered all eight on a laptop in under a second: EM OV TLS CA-G3C was d=4, EM EV TLS CA-G3C was 56, EM EV TLS CA-G3B was 115, plus 155, 156, 230, and two code-signing keys 66 and 237. A correct P-384 key is a random 384-bit number (~2^384), so brute force needs at most 255 steps.
Six TLS issuing CAs (DV/OV/EV, two generations each) and two code-signing CAs, all created April 2025 and cross-signed by Sectigo's AAA Certificate Services root in May 2025, giving a 17-month exposure window where the keys were effectively public and no theft was needed.
Timeline: reported Saturday Oct 17 2026 to Apple, Google, Microsoft, Mozilla and eMudhra; Chrome shipped a CRLSet block that evening and Mozilla used OneCRL hours later; Mozilla announced publicly Tuesday Oct 20 with an NSS update removing the root, and the root goes in Chrome Root Store v43.
Full summary
A security researcher reported on Oct 17 2026 that eight eMudhra intermediate CA private keys were compromised; the keys turned out to be single-byte integers (such as 4, 56, 115) on the P-384 curve, recoverable by brute force in under a second since a correct key would be a random 384-bit number. The six TLS issuing CAs and two code-signing CAs were created in April 2025 and cross-signed by Sectigo's AAA root in May 2025, so the keys were effectively public for 17 months with no way to know if anyone exploited them. Chrome blocked the intermediates via CRLSet and Mozilla via OneCRL within hours, followed by an NSS update removing the root and planned removal in Chrome Root Store v43. Browsers requiring Certificate Transparency (Chrome, Firefox, Safari) are largely safe, but CT detects rather than prevents mis-issuance. Non-browser TLS clients (curl, Python, Node, Go, CI/CD pipelines, package managers, IoT/OT devices) check neither revocation nor CT by default, so revocation does not protect them; the author demonstrated a forged api.stripe.com cert accepted by curl, Python and Node on Linux and macOS. Frozen-firmware devices will trust these certs until expiry in July 2039; eMudhra attributed the root cause to a ceremony script bug plus human error selecting the wrong keypair.
If the benchmarks hold, type-checking a large TypeScript codebase gets up to 8x faster at ~70% less memory, and the no-GC Rust build makes running a full TypeScript toolchain in WebAssembly (browser, Workers, embedded) practical.
Details
tsrs is a Rust port of the TypeScript compiler, built by Cloudflare and VoidZero with Max Schwenk of Owner.com, incubated inside the Oxc toolchain. Cloudflare says it is explicitly not a fork and that the TypeScript team keeps full control of language design.
Self-reported benchmark: tsrs is up to 8x faster and uses ~70% less memory than TypeScript 7.0 at equal type-check worker counts; Cloudflare says it worked with the TS team to match configurations. By default tsrs ships an adaptive config that trades more memory for even higher speed.
TypeScript 7.1 beta is already up to 2.5x faster than 7.0, with some optimizations upstreamed from tsrs. No methodology, machine specs, or codebase details are given for any of these numbers.
Cloudflare and VoidZero, working with Max Schwenk of Owner.com and in collaboration with the TypeScript team, announced tsrs, a Rust port of the TypeScript compiler incubated inside the Oxc JavaScript toolchain. Cloudflare states this is not a fork: the TypeScript team retains sole control over language design, and tsrs is meant to track upstream strictly. Early self-reported benchmarks claim tsrs is up to 8x faster and uses about 70% less memory than TypeScript 7.0 at equal worker counts, while the TypeScript 7.1 beta is already up to 2.5x faster than 7.0, partly from optimizations upstreamed from tsrs. Rust was chosen over Go (used by TypeScript's own native port) primarily for WebAssembly: Rust's no-GC memory model enables efficient guest/host memory sharing, enabling full dev toolchains to run in browsers, Cloudflare Workers, or embedded devices. Maintenance will mirror Cloudflare's Vinext/Next.js approach, using agents for daily diff review and nightly compatibility testing against TypeScript's suite, with performance fixes contributed back to the Go codebase. Current differences from upstream, such as diagnostic print order, are acknowledged and slated for reduction before a stable release; no benchmark methodology is disclosed.
Two small changes to a consistent-hashing library — a 6-byte packed struct and a 90% cut in hashes-per-server — freed 100TB of RAM across Cloudflare's fleet without new hardware, and the code ships now in the pingora-ketama v2 ring.
Details
The target was Pingora Backend Router (PBR), Cloudflare's internal load balancer, which uses pingora-ketama consistent hashing to route cacheable requests by URL so each data center keeps one copy of a file.
Storage win: the hash-point struct held a u32 hash plus index; shrinking the index to u16 did nothing because Rust aligns the struct to its largest field (4 bytes, min size 8). Storing both as a raw [u8; 6] byte array with getters dropped memory 25%. #[repr(packed)] was rejected as controversial.
Hashes per server trade memory for balance: NGINX hardcodes 160 and Pingora inherits it. For 100 servers, going from 1 to 160 points drops the coefficient of variation (error margin) from ~99% to ~8%.
Cloudflare reports reclaiming over 100TB of RAM globally by optimizing the pingora-ketama consistent-hashing used in its Pingora Backend Router, following a separate 100TB reduction by its DNS team the prior month. Two changes drove it: packing the hash-point struct from 8 bytes to 6 by storing hash and index as a raw byte array (circumventing Rust alignment rules) for a 25% cut, and reducing the number of hashes generated per server by 90%. The hash-count reduction was justified by deriving the coefficient of variation of per-server load and observing that 32-bit hash collisions (per the birthday paradox) make additional hashes counterproductive past a point — error rises between 10,000 and 100,000 hashes/server for 2,048-server data centers, so most of the default 160-per-server points were unnecessary. To avoid invalidating cached content, PBR held both the old and new rings in memory and chose per request-hash which ring routed the backend, rolling out by data center rather than a flat global percentage, with a redeploy-free rollback. The optimized v2 ring (compacted storage, faster sorting, tunable base hash count) is available as an unadvertised cargo feature in the open-source pingora-ketama crate. The 100TB figure is Cloudflare's self-reported result shown as a before/after memory chart.
If you parse untrusted JSON at scale in Rust, Deser offers a drop-in-ish alternative that eliminates per-nesting stack growth and keeps datetimes, arbitrary-precision numbers, and XML namespaces intact instead of corrupting them through Serde's buffering.
Details
Architecture inversion: in Serde the type drives and the format calls back into visitors via recursion (stack grows per nesting level); in Deser the format pushes events into a sink and a driver keeps nested sinks/emitters on the heap in an arena, so no call-stack recursion and no stack-overflow risk on deep input. The driver is Send, enabling streaming parses (JSON, CBOR, MessagePack) that can pause for IO under tokio.
Named root causes of Serde's limits: one trait set for all formats (features fail at runtime, derived structs can silently accept a JSON array for an object); a fixed data model that loses information when buffering internally/untagged enums and flatten (lost error locations, in-band magic-key signalling); and call-stack recursion.
Cited Serde corner cases: serde_json's arbitrary_precision feature (globally enabled by any crate via Cargo feature unification) breaks internally tagged enums with 'invalid type: map, expected f64'; serde(flatten) turns integer map keys into strings and misreports error location; deserialize_with functions cannot be composed into Option/Vec/map wrappers because a function is not a type parameter.
Deser is a Rust serialization library Armin Ronacher started in 2022, modeled on dtolnay's miniserde and recently revived. It inverts Serde's design: rather than a type driving deserialization and the format recursing through visitors, the format pushes events into a sink and a heap/arena-based driver manages nested sinks and emitters, removing per-level stack growth and enabling streaming, pausable parses that are Send-friendly under tokio. Ronacher attributes Serde's recurring problems, drawn from processing untrusted JSON in Sentry Relay, to three design decisions: one trait set for all formats, a fixed data model that loses information when buffering (breaking internally tagged enums, untagged enums, and flatten), and call-stack recursion that risks stack overflow. Deser aims for completeness, supporting JSON variants, CBOR, MessagePack, YAML, TOML, XML with namespaces, plist, CSV, urlencoded, and env vars, with type-based adapters and validators that nest inside Option/Vec and extension values (datetimes, UUIDs) that round-trip without magic keys. The tradeoffs are real: protobuf/bincode/postcard are excluded by design, it relies on dynamic dispatch and some internal unsafe, and the author's own benchmarks put JSON reads at roughly 10% slower on average and writes about even, with worse binary bloat but ~2.3x faster compilation of derived code. Ronacher concludes it is a possible drop-in replacement for users whose tradeoffs fit, but does not expect it to displace Serde given the orphan rule's entrenchment.
If you are building language tooling, the argument here is concrete: ship a queryable program database and runtime observability for agents instead of syntax tweaks or LSP endpoints, because agents track symbols and traces, not file/line/column positions.
Details
Written by Jose Valim (creator of Elixir) on the Dashbit blog; split into speculative 'Reflections' and opinionated 'Agentic tooling' sections. Discloses AI was used for style and grammar editing.
Rejects 'languages for coding agents' that optimize syntax or token efficiency, calling it building around current model limits; says agents experience HTML/CSS/JS/Elixir/Rust/Lean as tokens-in, tokens-out and are unbothered by boilerplate like explicit null checks vs optional chaining.
Argues agents writing raw assembly instead of using compilers is implausible: you still need an architecture-independent representation plus lowering (i.e., a compiler), and no single language unifies systems, theorem provers, query, concurrency (Erlang/Elixir), and hardware-description domains.
Jose Valim, creator of Elixir, argues that if coding agents write most code, language design should stop optimizing for human ergonomics and token efficiency and instead optimize for guarantees and agent-friendly tooling. He dismisses syntax-focused 'languages for coding agents' as building around current model limits, and rejects the idea of agents replacing compilers by writing assembly, since you still need an architecture-independent representation and no single language spans all domains. On tooling, he proposes exposing language-server information (symbols, references, call graphs, types, data flow) as a queryable program database rather than position-based LSP endpoints, which agents can compose into queries impractical as IDE features. He also favors stronger static guarantees over convenient type inference, combining correct-by-construction, static, runtime, and empirical (test/fuzz) techniques, and runtime observability over step-debuggers so agents can instrument and diagnose live systems, citing the Erlang VM's built-in introspection. The piece is framed as speculative 'ramblings,' informed by building Tidewave, and notes AI was used only for style and grammar.