When Signed and Encrypted Do Not Mean Safe

In both reported failures, the security mechanism worked as designed. Trusted publishing signed malicious source, and encrypted reasoning remained encrypted. The failure was treating those properties as guarantees that the content itself was safe.

Treat every security property as a narrow guarantee. Verify the content and its execution boundary separately.

A Valid Signature Can Authenticate Malicious Source

An attacker pushed malicious source to Kiev’s main branch. Trusted publishing built, signed, and released it.

The result was 2,234 poisoned versions across 444 package names, published using credentials from 12 organizations. Those packages had roughly 2 billion combined monthly downloads, although that measured ecosystem reach rather than compromised hosts, and overlapping dependencies inflated the aggregate.

The valid signature established provenance within the publishing process. It proved that the process signed the source it received, not that the source was benign.

The executable surface also extended beyond npm install. Visual Studio Code tasks could run when someone opened a repository, while Claude Code hooks could run when someone started an agent session. Deleting node_modules was insufficient because editor and agent configuration remained part of the execution boundary.

A 24-hour installation delay could have blocked this wave because its initial release remained live for one hour and 43 minutes. The trade-off is that the same delay would slow legitimate patches, and it would not protect users from a compromised maintainer.

Encrypted State Can Still Cross the Boundary

Researchers found the same boundary mistake in encrypted reasoning returned by Anthropic, OpenAI, and Google.

They replayed reasoning blocks across accounts, conversations, and some compatible models. They decoded 315,320 blocks from 6,78 public agent sessions and reported that 328 sessions exposed real information, including 182 credentials, 62 API keys, and 33 passwords.

Sixty-four recovered artifacts were absent from the visible transcript, so sanitizing readable messages was not enough. The researchers also used reasoning blocks to inject instructions, including code that uploaded PowerPoint files.

They did not break the cipher. The reasoning stayed encrypted, but authorized models accepted the authenticated state and could be prompted to reveal or follow it. Encryption prevented direct reading. It did not make the block safe to publish or replay.

Providers mitigated the reported attacks, which reportedly no longer worked as of August 2026. That stopped the demonstrated techniques, but it did not make client-held reasoning harmless.

Treat editor and agent configuration as executable code. Remove reasoning blocks before publishing traces. Where possible, keep state server-side and give the client only an opaque handle.

Configuration is executable code, and client-held reasoning should be handled like temporarily unreadable plaintext.