Notifications
Clear all
Topic starter
09/07/2026 3:30 pm
TL;DR: Anthropic’s new .dxt secret handling encrypts stored values with Keychain or DPAPI, but Cyata shows any extension can copy another extension’s encrypted blobs, decrypt them, and exfiltrate API keys across both macOS and Windows. Encryption at rest reduces exposure on disk, but it does not create trust isolation between plugins.
NHIMG editorial — based on content published by CYATA: LLMjacking sequel on encrypted Claude extension secrets and cross-plugin theft
Questions worth separating out
Q: What breaks when extension secrets can be copied between plugins?
A: The boundary between trusted and untrusted plugins breaks first, then the secret model itself.
Q: Why do encrypted secrets still create risk in plugin ecosystems?
A: Encrypted secrets still create risk because the application, not the extension, may control decryption.
Q: How do security teams know whether extension secret handling is actually isolated?
A: Test the replay path. A platform is not isolated if a secret created by one extension can be copied into another extension’s settings and still decrypt correctly. Also check whether decrypted values are exposed as environment variables or shared memory, because that reveals whether the runtime is enforcing actor boundaries or only encrypting files.
Practitioner guidance
- Inventory every extension with secret access Map which Claude extensions can read, copy, or request decryption of sensitive blobs.
- Separate credential-bearing workflows from general-purpose plugins Do not allow the same extension runtime to host both trusted automation and unrelated add-ons when secrets are in scope.
- Verify whether decrypted secrets are actor-bound Test whether a secret encrypted by one extension can be copied into another extension’s settings and still be decrypted.
What's in the full article
CYATA's full blog post covers the operational detail this post intentionally leaves for the source:
- A step-by-step walkthrough of how encrypted blobs are copied from one extension config into another.
- The exact macOS and Windows decryption behaviour that lets the host application unwrap sensitive values.
- Concrete examples of how stolen API keys can be read from environment variables after restart.
- A practical comparison of what encryption at rest does and does not protect in extension ecosystems.
👉 Read CYATA's analysis of encrypted Claude extension secrets and cross-plugin theft →
Claude extensions and encrypted secrets: is isolation still missing?
Explore further
09/07/2026 3:51 pm
Encrypted-at-rest secrets do not equal governed non-human identities: The article shows that the secret is protected from disk inspection but not from cross-actor reuse. That is the difference between storage hardening and identity control, and it matters because NHI governance is about who can use a credential, not only how it is stored. Practitioners should read this as a trust-boundary failure, not a cryptography failure.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- Around 100,000 valid secrets were found in public Docker images, with ENV instructions alone accounting for 65% of all secret leaks in containers.
A question worth separating out:
Q: Who is accountable when one plugin steals another plugin’s API keys?
A: Accountability sits with the platform owner and the extension governance process, not just the attacker. The control failure is allowing shared decryption rights across extensions, so the organisation must treat extension approval, secret scoping, and runtime containment as part of the same identity governance decision. OWASP Non-Human Identity Top 10 is a useful reference point for that review.
👉 Read our full editorial: Claude extension secret encryption still leaves cross-plugin theft
