TL;DR: Truffle Security reports that a RubyGems caching flaw let unauthenticated users receive cached API token responses when requests were compressed, turning a private auth flow into a shared edge-cache leak. The issue shows how SaaS trust boundaries break when cache keys ignore identity and token-bearing responses are treated as reusable content.
At a glance
What this is: RubyGems had a cache handling flaw that could expose valid API tokens from authenticated requests to other users.
Why it matters: It matters because SaaS platforms often rely on tokens for privileged actions, so a shared-response bug can become supply-chain compromise rather than a simple data leak.
👉 Read Truffle Security's analysis of the RubyGems API token cache vulnerability
Context
The core problem is not just token exposure, but a failure to preserve identity boundaries in shared delivery infrastructure. When an authenticated response can be cached and replayed to another user, the platform is no longer treating per-user secrets as per-user secrets.
In this case, the vulnerable path sat inside a normal SaaS interaction: a login flow that fetched API credentials and stored them locally. That makes the issue especially relevant to secret sprawl because the credential was not only created and stored, but also exposed through a transport layer assumption that should have kept it private.
Key questions
Q: What breaks when authenticated responses are cached as shared content?
A: Identity-bound responses stop being private, so one user’s token or account data can be replayed to another requester. In practice, that means the cache becomes part of the privilege delivery path. Any system that caches credential-bearing responses without including identity in the cache key can turn a single login into multi-user exposure.
Q: Why do token leaks from SaaS platforms create supply-chain risk?
A: Because many SaaS API tokens do more than read data. They can publish software, change package metadata, manage integrations, or alter release state. When those credentials leak, the problem is not only account compromise. It is also loss of integrity across the downstream systems that trust the token.
Q: What signs indicate that a cached secret exposure path exists?
A: Look for authenticated GET endpoints, compressed responses, edge caching in front of identity-sensitive paths, and token return values that are stored or replayed outside the origin. If a private endpoint can be requested anonymously and still produce a previously authenticated response, the cache path is unsafe.
Q: How should teams respond when a token may have been replayed by an intermediary?
A: Assume the token is exposed, revoke it, and review every system action that credential could authorise. Then verify whether the response path can be cached, whether the cache key includes identity, and whether similar endpoints return secrets that were never meant to leave the origin.
Technical breakdown
Why cache keys must include identity context
A cache is safe only when the response is truly reusable across users. Here, the edge cache keyed on the URL but not on the Authorization header, so a private response became indistinguishable from a public one. That is a fundamental boundary failure: the system preserved content-addressable reuse while ignoring who the response belonged to. If the cached object contains an API token, the cache is not merely accelerating delivery, it is redistributing privilege. See the NHI Authentication Guide. See the NHI Authentication Guide.
Practical implication: treat any cacheable response that can contain credentials as an identity-sensitive object, not as generic web content.
How compressed authenticated responses can leak secrets
The attack depended on a common HTTP behaviour: clients frequently send Accept-Encoding: gzip by default, which triggered the buggy caching path. That mattered because the application allowed authenticated GET responses to be compressed and cached, then later served the cached object without rechecking identity. The mechanism is subtle because the origin may still behave correctly, while the intermediary layer overrides the security decision. This is why authenticated responses carrying secrets should be handled as non-shareable even when the backend enforces access checks. See the API Key Management Guide. See the API Key Management Guide.
Practical implication: classify compression-plus-cache paths as secret-exposure risk until you can prove they cannot replay credential-bearing responses.
Why token-bearing GET endpoints are high-risk in SaaS
The vulnerable endpoints were ordinary-looking account and credential retrieval paths, but they returned API keys that could manage packages and user-owned resources. That combination turns a convenience endpoint into a supply-chain control point. In SaaS environments, GET endpoints are often assumed to be low-risk because they are read-oriented, yet if they return secrets or privilege-bearing material, they become equivalent to an authenticator distribution service. The architectural lesson is that HTTP method semantics do not determine sensitivity. See the Top 10 API Security Risks. Read Top 10 API Security Risks.
Practical implication: inventory every GET endpoint that can return credentials, tokens, or privilege-bearing data and subject it to the same controls as write APIs.
Threat narrative
Attacker objective: The attacker’s objective was to obtain a valid RubyGems API token that could be used to manage packages and take over supply-chain activity.
- Entry occurred when an unauthenticated requester or adjacent user asked the same compressed API endpoint that a logged-in user had already filled into cache.
- Credential access followed when the shared cache replayed another user's valid API token instead of forcing a fresh authenticated origin lookup.
- Impact was the exposure of a supply-chain credential that could push or yank gems and, for some accounts, compromise package integrity and account control.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity-blind caching is a privilege boundary failure, not just a web bug. The cache served a per-user credential response to another requester because it keyed on the URL instead of the authenticated subject. That turns delivery infrastructure into an identity broker without any governance over who receives which secret. The practitioner takeaway is that shared caches must be treated as part of the identity control plane whenever they can carry tokens.
Supply-chain credentials create a wider blast radius than ordinary session secrets. A RubyGems API token can publish, withdraw, or modify packages, so exposure converts a single HTTP flaw into an ecosystem risk. That is why package registries need stronger treatment than standard profile endpoints: the credential itself is an operational control surface. The governance question is not whether the token was valid, but whether its delivery path was ever safe to cache.
Secret distribution over normal web flows is a form of credential reuse debt. The system created a reusable token through a sign-in workflow, stored it locally, and allowed an intermediary to replay it across users. That is the kind of hidden coupling that makes SaaS identity reviews miss the real exposure path. Organisations should assume that any authenticated response carrying a secret can become a shared secret unless explicitly prevented.
Leaked credential response playbook fits this failure mode because the right response starts with revocation, not diagnosis. The article shows an exposure pattern where one request can leak a credential into a cache that then serves multiple users. That is not a theoretical configuration issue once the token is live. Practitioners should interpret this as a secret propagation event with a wide downstream attack surface, especially in package and automation ecosystems.
Read next: Leaked Credential and Secret Incident Response Playbook
What this signals
The pattern here is broader than RubyGems: any SaaS platform that returns secrets through authenticated web flows can convert infrastructure convenience into privilege reuse. Identity-aware caching has to become part of the design review, not a post-incident afterthought.
Credential replay debt: when delivery layers can replay a secret across users, the organisation is carrying hidden privilege exposure even if the origin application enforces authentication correctly. That shifts governance from application checks alone to the full path from login to edge cache to token storage.
Programmes that still treat read-only endpoints as low risk should reassess whether those endpoints can return tokens, certificates, or other secrets. If they can, the control objective is not simply access restriction, but making sure the response can never be shared outside the intended identity context.
For practitioners
- Audit cacheable credential endpoints Identify every authenticated GET path that can return API tokens, OAuth grants, or other secrets, and mark them non-shareable at the edge and intermediary layers.
- Separate identity from cacheability Require a design review for any response that depends on the requester’s identity, even when the endpoint looks read-only, and block caching unless identity is part of the cache key.
- Revoke exposed tokens immediately Treat any cache replay of a secret as a credential exposure event, rotate the token, and verify whether it can publish packages or access other privileged functions.
- Review package registry trust paths Map which API tokens can publish, yank, or alter packages so that a leak is assessed as supply-chain compromise rather than ordinary account exposure.
Key takeaways
- A shared cache can turn a valid login response into a cross-user credential leak if the cache key ignores identity.
- In this case, a RubyGems API token could control package publication and other supply-chain actions, which widens the impact of exposure.
- The limiting control is not just rotation after discovery, but preventing credential-bearing responses from ever becoming reusable content.
Related NHI Mgmt Group resources: NHI Authentication Guide · Leaked Credential and Secret Incident Response Playbook · API Key Management Guide · Internet Archive breach 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on API tokens exposed through a shared cache. |
| NHI-04 — Insecure Authentication | The cache replay path bypassed the intended authenticated response boundary. | |
| NHI-07 — Long-Lived Secrets | The leaked API tokens remained valid long enough to be reused by another requester. | |
| Recommendation — Classify cached token replay as NHI-02 exposure and revoke any affected credentials immediately. Review authentication-dependent endpoints for replay paths that weaken NHI-04 protections. Reduce token lifetime and rotate secrets that can survive beyond their intended session. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The attack path resulted in unauthorized retrieval of valid credentials. |
| Recommendation — Map credential replay exposures to TA0006 and prioritise detection on token-returning endpoints. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity-sensitive responses must preserve authorization boundaries across delivery layers. |
| Recommendation — Enforce PR.AA-05 so cached responses cannot bypass user-specific authorization. | ||
Key terms
- Cache Key Poisoning: A cache key poisoning issue occurs when shared infrastructure stores or serves a response using incomplete request identity, so different users can receive the same cached object. In identity security, this becomes dangerous when the object contains tokens, credentials, or other privilege-bearing data.
- Credential replay: Credential replay is the reuse of stolen authentication material to impersonate a legitimate user or system. In human identity programmes, replay risk grows when passwords, OTPs, or weak recovery flows can be captured and used from a separate device or session.
- Supply Chain Credential Abuse: Supply chain credential abuse occurs when attackers compromise trusted software, dependency, or tooling paths to steal or reuse credentials. The attacker is not only targeting the software artifact but the identity material that the software can reach during normal execution.
- Identity-Aware Caching: Identity-aware caching means the system only reuses a response when the user, token state, and authorization context are part of the cache decision. Without that boundary, a cache can leak per-user secrets or authorization data across requests that should never be interchangeable.
What's in the full article
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step reproduction of the cache replay path using the gem CLI and curl
- Varnish configuration details showing how the cache key ignored authentication context
- Local lab setup and proof requests that demonstrate when the response becomes a cache hit
- Impact discussion on how a leaked RubyGems token can affect package publication and ownership
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org