Forged Certificates, Faster Compilers, Fewer Stalls

On October 19, 2026, at about 17:00 UTC, Cloudflare learned that the private keys for eight intermediate certificates¹ issued by eMudhra, a certificate authority², had been compromised. Browsers, operating systems and Cloudflare's own systems all trusted these certificates. Cloudflare says "the keys themselves are weak," so an attacker could sign a forged certificate for any domain. With one, an attacker in the network path could pose as a real server and read or change its traffic. The article doesn't say how the keys became weak or who found the problem.

The WebPKI³ is the public system of certificate authorities (CAs) and trust lists that secures HTTPS. In it, any trusted CA can vouch for any domain. A certificate authority signs statements like "this public key belongs to bank.example." TLS⁴ (Transport Layer Security, the protocol behind HTTPS) clients check that signature against a trust store⁵, a list of root CAs they accept. Roots usually sign through intermediate certificates, so a chain like root → eMudhra intermediate → forged bank.example certificate passes every check. The verifier can't tell the signing key was stolen or guessable. The encryption still works. What fails is authentication, the step that confirms you reached the right party. Cloudflare stresses this point: TLS's encryption algorithms are not weakened.

1. Services that authenticate remote endpoints with public certificates. These were the most exposed. They include Cloudflare's proxies connecting to customers' origin servers⁶ (the customer's own backend behind Cloudflare) and internal applications calling external APIs. A forged certificate could impersonate the other end of either connection.
2. Shared foundations. In parallel, teams updated shared trust stores and base images, so every service that inherits trust from them got the fix. Reloads, restarts and redeployments followed to activate it.
3. Odd cases. Applications with bundled or custom trust stores were checked and updated one by one.

Cloudflare's closing point is that the incident hits some systems much harder than others. Browsers fixed it "with a flip of a switch." That is partly because each browser is one application rather than hundreds. It is also because they use quick-revocation channels like Chrome's CRLSets⁸, small revocation lists pushed to the browser outside the normal release cycle. Cloudflare uses a similar mechanism for some products. Most server software instead treats its trust store as a static file that only changes when a package update ships.

Cloudflare points to upki as a better model. Upki is a project built on the idea that a trust store should be a live feed, not a fixed list of root CAs. The feed would carry revocations and certificate transparency⁹ keys (certificate transparency is a system of public logs that record every certificate issued). The article doesn't describe how upki works or how widely it is used.

Cloudflare has published an experimental release of tsrs¹, a port of the TypeScript compiler to Rust. VoidZero², the company behind the Vite build tool and the Oxc³ toolchain, worked on it with Cloudflare, along with Max Schwenk of Owner.com. tsrs is being incubated inside Oxc, a set of Rust-based JavaScript tools. Cloudflare says it is working in close collaboration with Microsoft's TypeScript team. Anyone can try it with npm install tsrs and npx tsrs.

Microsoft has already attacked this once. It rewrote the compiler, originally written in TypeScript, in Go. That rewrite ships as TypeScript 7.0⁴, and the article credits it with about a 10x speedup and much lower memory use. Cloudflare says this was the only successful port among many attempts over the years, because the compiler is so complex.

The headline benchmark compares tsrs with TypeScript 7.0 using the same number of type-check workers⁵, the parallel threads that check files. On that basis tsrs is up to 8x faster and uses about 70% less memory. Cloudflare says it worked with the TypeScript team to make sure both sides ran the same configuration. It contrasts this with other published port benchmarks that, it says, inflated their results with larger machines or non-default options.

Cloudflare argues the point is not mainly speed. It is about WebAssembly (Wasm)⁶, a compact bytecode that runs in browsers and in sandboxed server runtimes. Go manages memory with a garbage collector⁷, a runtime component that periodically finds and frees unused memory. Compiling Go to Wasm means shipping that collector inside every module. Rust frees memory at points fixed when the program is compiled, so it needs no collector. Cloudflare says this also lets a Wasm module and the program hosting it exchange memory simply.

The target is Cloudflare Workers⁸, its serverless platform that runs code in sandboxes across its data centers. Workers has long supported Wasm, and Cloudflare recently added native Rust support through a new Emscripten target for wasm-bindgen, the tool that connects Rust code to JavaScript hosts. When build and deploy systems run in tight loops, a small memory footprint saves money quickly. Cloudflare's stated aim is to run a whole development toolchain, end to end, in a sandbox that AI agents can drive. The same Wasm build could also run client-side in a browser, or on embedded and IoT (internet-connected) devices.

Maintenance has two parts. First, Cloudflare is working with Theo Browne to merge tsrs with a similar project, tsc-rs, into one package covering all of TypeScript's features. That includes the Language Server Protocol (LSP)⁹, the standard way editors get errors, completions and go-to-definition from a language tool. The article also mentions "content mappers" but doesn't explain them.

Second, it will reuse the agent workflow it runs for Vinext¹⁰, its reimplementation of the Next.js web framework:

Meta's engineering blog has published a detailed look at Prometheus, its gigawatt-scale AI training supercluster in New Albany, Ohio. Two years ago the site ran ordinary web traffic. Now it holds hundreds of thousands of NVIDIA GPUs¹, the processors that do the matrix math of AI training, spread across several buildings and wired together to act as one machine. Phase one is finished. It trained Meta's Muse foundation models, including the frontier "Muse Wonder" models, and Meta plans to grow the cluster to about 1 million GPUs. The most useful part of the post is about reliability, not raw compute.

• Goodput²: the share of time spent on productive training.
• MTBI³ (mean time between interruptions): measured in GPU-hours. An MTBI of 50,000 GPU-hours on a 10,000-GPU job means a stall roughly every five hours (illustrative arithmetic).

In the H100 generation, NVLink joined only 8 GPUs. NVL72 joins 72, so one fault can now take out nine times as many GPUs. Training splits work most cleanly into groups sized as powers of two, so Meta runs 64 GPUs per rack and keeps 8 as in-rack spares. When a GPU fails, a spare takes its place. The job restarts from its last checkpoint⁹, and the rack stays in the job instead of waiting for a technician. For rarer whole-rack failures, Meta keeps about 2% extra racks in reserve.

• PAFT¹⁰ (Parallelism-Aware Fault Tolerance): training runs as several data-parallel replicas, meaning full copies of the model that each train on different data. If a fault stays inside one replica, only that replica goes offline. The others repeat the step and continue, and the damaged replica restarts on spare hosts and catches up. A full halt becomes a brief dip in throughput.
• Checkpointing: larger faults roll the whole job back. Checkpoints save model weights, gradients and optimizer state in the background to tiered storage. Meta uses delta checkpoints (saving only what changed) and stages them in memory first, so training barely slows.

Alongside the normal data-center network, Meta runs a dedicated Ethernet back-end network¹¹ used only for GPU-to-GPU traffic. Each building fabric connects up to 20,736 GPUs. It began as a "scheduled" fabric, where switches spread packets across paths and reorder them. That design avoids collisions between the few large, long-lived flows that training produces. Once network cards could reorder packets themselves, Meta moved to simpler 51.2 Tbps switches running its own FBOSS¹² switch software. The network links the buildings over 2 to 100+ km using deep-buffered Arista switches, with several petabits per second between region pairs. Meta places delay-tolerant traffic between replicas on these long links and keeps delay-sensitive traffic inside buildings. It also needed dedicated tuning to cope with speed-of-light delay. In total the cluster uses millions of miles of fiber and millions of optical transceivers.

When tens of thousands of GPUs switch between computing and communicating at the same moment, cluster power swings by 30–40%. Starting or stopping a job can move tens of megawatts in seconds. Software called Dynamo Dimmer¹⁴ gradually lowers GPU power caps as the cluster nears its electrical limit, instead of halting jobs. Rack batteries, capacitor trays and facility battery storage absorb the spikes. Cooling varies by building: air-assisted liquid cooling in older and rapid-deployment buildings, and facility liquid cooling in the new AI-specific building.

IBM Research reports that ALTK-Evolve, its system for giving AI agents learned memory, lifted a plain agent built on GPT-4.1 to the top of the retail leaderboard on τ²-bench¹, a customer-service benchmark. GPT-4.1 is an older OpenAI model with no extended reasoning mode. The agent reached 67.5% Pass^4², beating every retail entry in the October 12, 2026 snapshot. That includes RAFT-30B-A3B, a model fine-tuned on synthetic τ²-bench retail data, which scored 61.4%. The model's weights never changed. The only change was a list of behavioural rules appended to the system prompt³, and the agent wrote those rules itself from its earlier attempts.

τ²-bench, built by the company Sierra, pairs an agent with a customer played by another LLM⁴ (large language model). The simulated customer has a hidden goal. The agent gets domain tools, such as order lookup, refunds and flight rebooking, plus a written policy it must follow. Grading is strict. A task counts as solved only if the final database state matches the expected one, and many actions, like a refund, can't be undone. The agent has to draw out the right details from the customer, stay within policy and call the right tools in the right order. IBM uses the benchmark's two customer-service domains, retail and airline.

The setup is deliberately stock. It uses τ²-bench's own ReAct⁵ agent, a loop that alternates THINK and ACT steps, with GPT-4.1 as the agent and GPT-5.5 playing the customer. ALTK-Evolve runs the agent on the benchmark's training tasks. GPT-4.1 then reads the successful and failed transcripts and distills them into short rules. The same model plays both roles, and no human labels anything. The rules are appended after the policy as a markdown list, then applied unchanged to held-out test tasks. Examples include:

Each rule has a support count⁶: the number of distinct training tasks it was extracted from. A high count suggests the rule generalises; a count of 1 may be a one-off. IBM tested three settings:

• baseline: no rules.
• sup3: only rules with support of 3 or more. That left 31 rules for retail and 14 for airline.
• lossless⁷: every rule kept after merging duplicates. That left 292 for retail and 101 for airline.

Conversations did not get longer. IBM compared only runs that both the baseline and the guided agent solved, on the same scenario and random seed. On those, lossless trimmed the conversation from 10.59 to 10.16 agent turns in retail and from 9.15 to 8.82 in airline. No setting added turns. Each turn is a sequential model call, so fewer turns means lower latency. The rule block is identical on every call, so IBM argues prompt caching⁸ can recover much of the extra input cost. The article gives no numbers for the cached case.

τ²-bench requires leaderboard submissions to be scored on the full "base split⁹", meaning training and test tasks together. These figures therefore differ from the held-out ones above.

Interconnects publishes a regular roundup of open-weight¹ AI releases. Open-weight models are ones whose trained parameters anyone can download and run. In issue #25, Florian Brand argues that the biggest open-source artifact of recent months isn't a model at all. It is DeepInfer, the inference² software DeepSeek uses to serve its own models, which the company has now released publicly. The release lands in a week when governments in both Washington and Beijing moved toward controlling open models.

• China. MOFCOM³, China's Ministry of Commerce, published a policy proposal. It is not yet law. Under it, frontier AI models and some other technologies would need government pre-approval before being shared internationally. Brand calls the reaction "overblown", because the document says open-source technologies would get automatic approval. He notes that geopolitics watchers still see it as significant: it creates a framework that could be used to regulate China's AI industry later. Other sources he trusts think the real target may be deals like the sale of Chinese startup Manus to Western companies, not model releases.
• United States. The Department of Homeland Security (DHS) issued an order that bars DeepSeek, both the company and its models, from being a vendor in federal civilian procurement. Brand points out an open question the order doesn't settle. What happens to models fine-tuned from DeepSeek, or trained on its outputs? NVIDIA's Nemotron models, for example, have long leaned heavily on DeepSeek models in their training recipes.
• Existing controls. Zhipu AI, the maker of the GLM models, is already on the Entity List⁴. That list is run by the Commerce Department's Bureau of Industry and Security (BIS) and restricts access to American technology.

Training a model is only half the cost. Every response has to be generated on GPUs, a step called inference. How cheaply that runs depends on serving software that batches many users' requests together, manages GPU memory and uses fast low-level kernels. The standard open-source options are vLLM⁵ and SGLang⁶. They are general-purpose engines that support many model architectures.

DeepInfer is built for DeepSeek's own models, so Brand expects it to be "far more efficient" on them than vLLM or SGLang. The article cites outside estimates that DeepSeek makes up to 90% gross margin⁷ selling tokens on this stack. Gross margin is revenue minus the direct cost of serving. The article doesn't give benchmarks for DeepInfer, describe how it works internally, or say where the 90% figure comes from.

DeepSeek-V4.1-Flash-1017. DeepSeek shipped two iterations since the last roundup, at a new size: 552B-A16B. That means 552 billion total parameters, about 16 billion active per token, in a mixture-of-experts⁸ design. It also accepts image inputs and keeps the MIT license. Brand calls that notable at a time when licenses are becoming "more bespoke and exclusionary". On DeepSWE⁹, which the article calls a favorite agentic software-engineering benchmark, DeepSeek dominates the Pareto frontier of performance against price. The Pareto frontier is the set of models that no other model beats on both score and cost at once.

MiMo-V2.6-Pro-RL (Xiaomi). This model reuses the base models from MiMo V2.5 but puts far more compute into reinforcement learning¹⁰ (RL). RL is post-training in which the model attempts tasks and gets rewarded for good outcomes. Xiaomi released a detailed technical report and some of its RL environments, which Brand says is rare at this scale. It also ran a live training dashboard. The final V2.6-Pro is currently the top open model on Artificial Analysis, an independent benchmarking site.

NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4. This is the mid-sized Nemotron update, with vision support (VL means vision-language). NVFP4¹¹ is NVIDIA's 4-bit floating-point format, which shrinks the model enough to run on a high-end laptop or an RTX Spark. As usual, NVIDIA released most of the training data and a detailed report.

• Ternary-Bonsai-2-27B (prism-ml): a ternary version of Qwen3.8-27B, meaning each weight is restricted to roughly three values (−1, 0, +1). It ships in GGUF¹², a file format used by local runtimes such as llama.cpp, and targets on-device use.
• Ornith-1.5-397B (ornith-ai): fine-tunes of Qwen3.5 and Gemma 4 that local-AI users noticed for beating those already strong base models.
• Ling-3.0-flash-VL-fp4 (inclusionAI, part of Ant Group): a 124B-A5.5B model.
• Muse-Spark-Open-816B-A42B (Meta): an open version of Meta's Muse model.