CVE-2026-67199

This vulnerability isn't about a missing iteration cap — it's about a component that crossed a trust boundary it was never designed to survive. The expression engine in Perspective was originally a client-side library where evaluating arbitrary expressions on trusted data was a feature, not a hazard. When Perspective migrated to server-side deployment, the expression engine came with it, unmodified, because it worked and removing it would break downstream consumers. No one audited whether it was safe in a context where untrusted callers could invoke it over the network. That migration inflection point is where the vulnerability was born. The technical mechanism matters: the attacker embeds a heavy iteration construct into an expression column, which gets evaluated once per table row. The blast radius scales in two dimensions — the malicious iteration count AND the victim's dataset size. Large dataset? You're blocked longer, and you don't know why. That response-time asymmetry creates a side-channel probe vector: attackers can infer dataset characteristics by measuring how long the blocked request takes to fail. Here's the systemic risk that CVSS 6.5 doesn't capture: a single malicious client submits one payload, the Tornado IOLoop blocks, and every connected client — potentially hundreds on a shared visualization server — experiences denial of service simultaneously. The attacker pays one request cost and collapses the entire tenant population. That's per-deployment systemic collapse, not per-request impact. The patch will add a loop limit. That's the right immediate response. But the underlying architectural gap is that the expression engine is in the request path at all — it's an unbounded computational context receiving untrusted input with no sandboxing, no worker delegation, no memory ceiling, no cancellation semantics. The expression API treats evaluation as a first-class feature while treating resource governance as optional. A loop limit treats the symptom; the disease is that the API boundary doesn't enforce computational contracts. If you're defending a Perspective deployment: prioritize the iteration cap patch immediately, but treat it as a bridge to the real fix. The expression engine should be moved to a worker process with hard resource limits, or the API should be refactored to accept only pre-validated expression patterns. The disclosed CVE now functions as a map — any expression construct that bypasses the new cap inherits the same execution context. Assume future payloads will probe the boundary differently. Plan your architectural remediation with that assumption baked in.

Reviewed through automated stages and approved by a human before publication.