The Engineer

Risky.Biz places the compromised releases of Trivy, KICS, LiteLLM and Telnyx in a January-to-August 2026 exposure window. The Hacker News dates the Trivy and Checkmarx compromise to March 2026. That disagreement is the rotation window, and the two accounts do not overlap cleanly. Neither states the entry vector per project. Trivy ships as a Go binary and container image rather than a language-registry package, so compromised release automation is at least as plausible as a stolen registry account. Treat January 2026 as the start date until a per-project advisory narrows it.

The worm never touched the artifact layer. It waited for install on a developer machine, stole stored credentials, then republished itself into other libraries the same maintainer owned. The release is signed by the real publisher and the SBOM version checks out, so no scanner has a CVE to match. The attack traverses the human trust graph while almost every supply-chain control on the invoice watches artifacts.

The two exploited bugs sitting in the same blast radius

Gitea CVE-2026-60004 is the same mechanism from the other side. An attacker with repository write access, from a leaked PAT or an over-permissioned bot, posts a malicious patch to the diffpatch endpoint. Gitea writes an executable file into the repo's hooks directory, and the next matching Git operation runs it as the Gitea service account. That account holds every repo on disk plus webhook secrets, runner registration tokens and usually registry push credentials. Admin is never required. SANS is explicit that upgrading does not remove hooks already planted, so the order is patch, diff every hooks directory against defaults, rotate.

The MLflow SSRF is the ML-platform variant, and it sits next to an ISC diary on mass scanning for cloud metadata services. Read together, the chain closes: reach an unauthenticated tracking server inside the VPC, coerce it into fetching 169.254.169.254, collect the instance-profile credentials it carries for artifact-store access. IMDSv2 with hop limit 1 and default-deny egress break that chain on an unpatched tracking server. The work lands in the metadata service config and the subnet egress rules.

Two arrests closed the case in Western Australia, but the stolen credentials still authenticate and the planted hooks still execute, so rotation and hook diffing are still owed.

The move

Sources agree on the sequence and disagree only on scope. The Hacker News makes the sharpest structural point: OIDC-federated short-lived credentials need no rotation at all, which is the argument for the migration that keeps getting deferred. The rest is mechanical. Runners get destroyed per job, sub-hour OIDC tokens replace every static secret, and scanners run in a separate job with no deploy credentials and egress limited to the vulnerability-database endpoints. Pin scanner images by SHA256 digest while in there, because aquasec/trivy:latest inside a job holding a cloud role is the exact configuration this campaign was designed against.

The mechanism that makes prefix caching fragile decides where the prompt-assembly boundary goes. vLLM stores KV in fixed 16-token blocks, each identified by a hash over the parent block's hash plus its own token IDs. That chaining turns a block lookup into a prefix lookup: a block matches only if everything before it matched. The scheduler walks incoming blocks in order and stops at the first miss; the rest is fresh allocation and fresh prefill. Only complete blocks are indexed, so the block straddling stable prefix and variable content is recomputed every request and unshareable. Prefix cache and running batch draw from the same GPU memory pool, so a bigger cache buys fewer concurrent sequences.

The write premium is not the exposure

Do the arithmetic before arguing about the 1.25x write surcharge. For N requests over a shared prefix of T tokens, uncached costs N·T and cached costs T·(1.25 + 0.1·(N−1)). Crossover is N ≈ 1.28; one reuse inside the TTL pays for the write. The leak is writes that are never read: a flat 25% surcharge for nothing, from TTL expiry, misplaced breakpoints and invalidation. The invalidation list is longer than most prompt-review checklists.

1. Any variable ahead of stable content, such as a timestamp, request ID or username in the system prompt, invalidates every block after it.
2. Tool schemas usually render ahead of the system prompt, so nondeterministic serialization order nukes the whole cache.
3. Web search, citations, thinking config and tool_choice toggles rewrite the rendered prompt. Feature flags carry an inference bill.
4. A/B testing two reasoning efforts splits the cache in two, and nobody bills that to the experiment.
5. Summarizing history rewrites the prefix and pays cold price; truncating tool outputs in place keeps it byte-identical.
6. Entries are model-scoped, so routing a long conversation to a cheaper model re-prefills the full history cold.

Where the two sources converge

The independent PagedAttention reporting lands in the same place from the serving side: ~96% cache utilization, copy-on-write sharing of identical prefixes, 2–4x more users per GPU with byte-identical attention outputs, and it fires only on exact prefix matches. That kernel already ships in vLLM and SGLang, so the remaining lever is what you feed it. For RAG, sort retrieved chunks by a stable content hash or doc ID instead of relevance score, and pad the stable region to a block boundary. That trades positional quality for cache determinism, so A/B it on answer quality and TTFT.

Capacity planning changes too. Decode is memory-bandwidth-bound: the whole KV cache streams from HBM every step, and roughly 40 GB of KV covers one 128K context on a 70B BF16 model. On 640 GB of HBM with ~140 GB of resident weights, that is about a dozen concurrent max-context requests. Model concurrency-at-context, not FLOPs.

Hit rate is not one metric. Split it into prefill saved and wrong answers served, because only one of those has a severity.

That second half is the semantic cache. Its failure modes are geometric rather than threshold-tunable: negated sentences sit close together in embedding space, and two prompts sharing a sentence frame but differing in one operational value score as near-identical because the frame dominates the vector. Published thresholds span 0.75 to 0.97. The number is a property of your traffic.

The architecture is the part of LinkedIn's decision worth copying. Its hiring assistant runs four memory types: conversational, episodic, semantic, procedural. Behind them sit three dedicated services: ingestion, consolidation and retrieval, each with access control, traceability and a hard latency budget. Most teams shipping agent memory build ingestion and retrieval and skip consolidation. Consolidation is the service that keeps memory from degrading into an append-only landfill of stale preferences.

The trade should be priced before it is copied. A tree gives up the arbitrary multi-hop relational queries a graph hands you for free. Picking it is a bet that personalization needs freshness more than relational reach. Where the differentiating queries run three hops deep, the same cost analysis lands somewhere else.

The same finding, one layer down

An independent line of analysis reaches the write path from the multi-tenant side. Agent memory as knowledge graphs produces one graph per user, per team, per project. That is millions per enterprise customer, most cold at any instant, with each query reading exactly one. General-purpose graph engines assume the opposite: one large resident graph, with a parse and optimizer pass ahead of every request. On sparse workloads cost then tracks provisioned memory rather than reads served, and tenant isolation collapses into a filter over one shared graph. That is a unit-economics problem sitting one bad predicate away from cross-tenant exposure. Vendor latency claims in that space arrive without disclosed graph sizes, query shapes or hardware. Take the architecture; make them reproduce the benchmark.

Then check the state backend

Flink and Kafka Streams both use RocksDB as the state backend, so anyone running either already owns this problem. Benchmarked across workload shapes:

A 4.5x I/O and SSD-wear lever living in the key schema is the cheapest performance work available to a streaming team. The space-amplification number also says the usual disk-headroom alarm threshold is miscalibrated. TTL-heavy stores want at least 40% free.

What not to act on yet

Two adjacent items are evaluation criteria, not mandates. LogDrive decomposes the shared log into an AtomicLog sequencing layer plus a durability layer of flat single-value registers with weakTail, which makes striping and quorum replication reusable over S3, S3 Express or DynamoDB. It is the clean formal skeleton under the diskless-Kafka wave, and it is good work. weakTail is the word to circle: approximate tail visibility is a real semantic change for any consumer that assumes strictly monotonic tail reads. Read it as a vendor questionnaire, not a migration plan.

Production bills for incremental update cost. Benchmark cost-per-update before you benchmark recall.