They collapse trust between authentication and execution. If the same key signs multiple features, or if a signed claim is later fed into a template or evaluator, a forged but valid token can carry attacker-controlled input straight into code execution. The signature proves integrity, not safe downstream use.
Why shared signing keys turn authentication into an execution path
Shared signing keys create a single trust boundary for multiple features, so compromise in one place often becomes compromise everywhere that key is trusted. That is dangerous before authentication, because the system is still deciding whether to trust the token or claim at all. If the same signer is reused across features, a forged token can look legitimate long enough to reach code paths that should never consume it as executable input.
Shared keys also make blast radius larger than the application team often assumes. When the same signing material is accepted by multiple services, the attacker does not need to break each service individually. They only need one signing trust anchor, then any downstream component that treats the claim as authoritative inherits that compromise.
Trust gets especially brittle when the signed field is later used as more than an access decision, for example when a claim is inserted into a template, command, query, or expression evaluator. The signature may prove the token was issued by a trusted signer, but it does not prove the downstream use is safe. That distinction is the core reason pre-auth remote code execution can emerge from something that initially looks like “just token validation.”
How a valid signature can still lead to pre-auth RCE
The exploit path usually depends on a dangerous chain: attacker controls some token content, the token is accepted because it validates, and an application later reuses that value in a context with execution semantics. At that point, the bug is not in cryptography alone, it is in assuming signed means safe. A valid token can still carry attacker-controlled payloads if the application treats claims as trusted data for rendering or evaluation.
This is why the exact boundary matters. If one component verifies a signature and another component later interprets the claim as code, policy, or a template fragment, authentication and execution become coupled. The verifier may be correct, but the consumer is over-trusting the assertion. In practice, that often appears in SSO, federation, or feature-flag flows where a signed assertion is reused beyond its original security purpose.
For readers who want the trust mechanics behind signed assertions and sender-constrained tokens, the standards around RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants and RFC 9700: Best Current Practice for OAuth 2.0 Security are useful reference points for why token handling and audience discipline matter.
What makes the risk worse in real systems
The risk rises when signing keys are long-lived, reused across environments, or shared by many products, because compromise becomes both easier to exploit and harder to contain. If one key signs multiple claims, tokens, or platforms, an attacker may be able to pivot from one weak entry point into other services that implicitly trust the same signer. That is why key rotation, key separation, and strict audience scoping are not optional hardening steps but core containment controls.
Pre-auth RCE also becomes more plausible when developers trust signed claims to carry application logic. A signed string that reaches a template engine, expression language, shell wrapper, or deserializer is a classic trust boundary failure. The more generic the signed content is, the more tempting it becomes to reuse it across layers, and the more likely one layer will interpret it in a dangerous way.
Concrete examples of this failure mode include signing-key abuse in Microsoft Storm-0558 key breach 2023, where a stolen signing key enabled token forgery, and ASP.NET machine key attacks 2025, where exposed machine keys were used to turn trusted server-side data into remote code execution. Both show how trust in a signer can be converted into trust in attacker-controlled behavior.
Risk and Threat Considerations
Shared signing keys are a pre-authentication hazard because they widen the number of places an attacker can impersonate trust, while trusted claims can become code execution primitives when downstream components interpret them too broadly. The key danger is not merely token forgery, but forged legitimacy flowing into a higher-privilege or executable context.
Failure mechanism: A token validates against a shared key, then the application reuses a claim in a template, evaluator, or other execution-aware sink without rechecking whether that value is safe for that context.
Impact: An attacker can move from unauthenticated token injection to code execution, often before any normal user session exists, which makes detection harder and containment more urgent.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shared signing keys and leaked claims secrets directly create forged-token and RCE exposure. |
| NHI-05 — Overprivileged NHI | Reused signing keys grant one compromise excessive trust across features and services. | |
| NHI-07 — Long-Lived Secrets | Long-lived signing keys increase the window for token forgery and downstream abuse. | |
| Recommendation — Rotate exposed signing keys and remove any secret that can mint trusted claims. Separate signing trust so one key cannot authorize multiple unrelated systems. Shorten cryptoperiods and rotate signing material aggressively. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Machine and service assertions must be verified without over-trusting them as executable input. |
| AC-6 — Least Privilege | Limiting what a trusted claim can reach reduces blast radius after token validation. | |
| Recommendation — Bind service authentication to scoped trust and reject unsafe downstream claim use. Restrict claim-driven code paths to the minimum authority needed. | ||
| OWASP ASVS | V8 — Authorization | Claims used for access or policy decisions must not be repurposed as executable data. |
| Recommendation — Separate authorization decisions from any claim processing that can trigger execution. | ||
Practitioner Guidance
What to verify: Check whether any signed field is ever consumed by rendering, rule evaluation, deserialization, shelling out, or dynamic policy logic. If yes, treat that field as untrusted input for the downstream sink even if the signature is valid.
Decision rule: If a signing key is accepted by more than one service or environment, assume compromise has cross-system blast radius and prioritise key separation, audience restriction, and rotation before deeper application tuning.
Common mistake: Teams often stop at “the token verifies,” but verification only answers who signed it, not whether the value is safe to execute or interpolate.
Practitioner takeaway: The safest pattern is to keep authentication evidence and executable input separate, because once a signed claim can influence code paths, the signature no longer functions as a safety boundary.