Cross-Service Token Attack
- Cross-service token attack is the exploitation of authentication tokens across different security contexts due to insufficient binding to the intended service, device, or presenter.
- It involves failure modes like provenance confusion, replay attacks, and inadequate non-transferability, affecting systems from WebAuthn to 5G networks.
- Defensive strategies emphasize stronger cryptographic binding, constant-time validation, and strict context isolation to prevent multi-stage exploitation.
Cross-service token attack denotes a family of failures in which an authentication artifact, session artifact, capability, or token-like control object established in one security context is accepted, replayed, reinterpreted, or exploited in another. Across the surveyed literature, the “cross” boundary varies: between relying parties in WebAuthn, between OpenID Connect endpoints, between 5G network functions, between an Android app and an embedded WebView, between local applications and mobile SDK services, between devices, between agent and tool servers, and between bridge components spanning multiple chains. This synthesis suggests that the unifying issue is not a single protocol bug, but insufficient binding of a token or token-like artifact to its intended service, presenter, device, or execution path (Kepkowski et al., 2022, Mladenov et al., 2015, Chen et al., 10 Sep 2025, Khinda, 3 Mar 2026, Feng et al., 27 Apr 2026).
1. Definition and terminological scope
The literature uses the topic unevenly. Some works are direct instances of cross-service token attack in a narrow sense. In FIDO2/WebAuthn, timing differences in key-handle processing allow an adversary to link a user’s accounts on multiple services even though the protocol is designed to use a different credential per service (Kepkowski et al., 2022). In OpenID Connect, “Malicious Endpoints” attacks cause a client to send authorization codes, access tokens, and client credentials to the wrong service after Discovery and Dynamic Registration metadata is maliciously supplied (Mladenov et al., 2015). In 5G SBA, the paper explicitly names a “Cross-Service Token Attack” in which a token legitimately issued for one SBI service is accepted by another because scope validation is broken in free5GC (Chen et al., 10 Sep 2025).
Other papers are adjacent but still informative. The Android WebView work is best understood as session/cookie reuse across the app–WebView boundary rather than a classic federated-token attack: the remote site “authenticates the WebView and not the application,” which allows the host app to drive authenticated requests or replay cookies (Bhavani, 2014). The Apple Intelligence work demonstrates a practical cross-device replay of TGTs and OTTs, not a direct proof that the same token is accepted across multiple distinct backend services; its relevance is that non-transferability fails when tokens are not bound to the rightful device (Zhou et al., 17 Apr 2026). TULIP, by contrast, is not a treatment of stolen SAML assertions, OIDC bearer tokens, or RP session cookies; it is a pre-authentication gate that requires an enrollment JWT cookie before the IdP login page is rendered (Hays et al., 2024).
A further complication is that “token” is overloaded. In identity, mobile, telecom, and bridge systems, it denotes cookies, JWTs, authorization codes, access tokens, proofs, key handles, or transferable IPC objects. In recent LLM-agent security work, it can instead denote model-generation tokens and token budgets. The agent-tool paper on “resource amplification via tool-calling chains” is therefore a cross-service token attack in an economic sense: one service causes another to spend excessive tokens across turns while preserving protocol compatibility and final-task correctness (Zhou et al., 16 Jan 2026).
2. Core failure modes
A recurring failure mode is broken audience, scope, or endpoint binding. In OpenID Connect, attacker-controlled Discovery metadata can split one logical OP across different services, so that registration and authorization occur at an honest OP while the token and userinfo endpoints point to malicious.com; the client then sends the code, client_id, and client_secret to the malicious token endpoint, or sends a fresh access_token to a malicious userInfoEndp (Mladenov et al., 2015). In free5GC, a token issued for nudr-dr can be reused against nnrf-disc because VerifyOAuth calls verifyScope(...) but returns errors.Wrapf(nil, ...) when the scope check fails, so unauthorized NF operations are accepted (Chen et al., 10 Sep 2025).
A second failure mode is provenance confusion: the system authenticates origin rather than current presenter. The Android SDK paper shows that PendingIntent.getCreatorPackage() identifies who created a PendingIntent but cannot attest who presents it. An attacker with NotificationListenerService access can steal a legitimate partner’s PendingIntent from a notification and replay it to the provider service, which then authenticates the attacker as the partner. The attack succeeds against both mutable and immutable PendingIntents because immutability protects contents, not provenance (Khinda, 3 Mar 2026).
A third failure mode is insufficient non-transferability. The Apple Intelligence study reconstructs a two-stage design with long-lived TGTs and shorter-lived OTTs, then shows that those tokens can be extracted from keychain storage and replayed on another Mac. The TGT remains useful for several days, OTTs for about 12 hours, and the attacker’s use is rate-limited against the victim. The paper’s main lesson is explicit: anonymizing identity does not by itself make the service secure; non-transferability requires cryptographic binding to the rightful user or device (Zhou et al., 17 Apr 2026).
A fourth failure mode is side-channel correlation rather than direct replay. FIDO2/WebAuthn uses unique key pairs per service, yet vulnerable authenticators process “wrong service but correct authenticator” handles measurably differently from “wrong authenticator” handles. Because browsers perform silent authentications over allowCredentials, an attacker can compare total execution times and link accounts across relying parties without stealing private keys or breaking signatures (Kepkowski et al., 2022).
A fifth failure mode is ambient delegated authority and confused-deputy behavior. In MCP ecosystems, a malicious weather server can induce an AI client to discover and invoke a legitimate banking tool authenticated through OAuth2, retrieve the user’s account balance, and then send it to an attacker-controlled endpoint. The proof of concept exfiltrates sensitive data rather than the token itself, but the authority of the already-authenticated tool is reused across services through a shared orchestrator (Croce et al., 26 Jul 2025).
3. Representative architectures and attack patterns
Representative cases span web identity, mobile platforms, telecom control planes, agentic systems, and bridge protocols (Kepkowski et al., 2022, Mladenov et al., 2015, Bhavani, 2014, Khinda, 3 Mar 2026, Chen et al., 10 Sep 2025, Zhou et al., 17 Apr 2026, Croce et al., 26 Jul 2025, Zhang et al., 2023).
| Domain | Artifact or control object | Representative mechanism |
|---|---|---|
| FIDO2/WebAuthn | key handle / credential ID | timing-based account linking across relying parties |
| OpenID Connect | authorization code, access_token, client_secret |
Discovery and Dynamic Registration redirect secrets to malicious endpoints |
| Android WebView | session cookie / session ID | app drives authenticated requests or replays cookies via HttpClient |
| Android cross-app SDKs | PendingIntent |
creator/presenter confusion enables partner impersonation |
| 5G SBA | OAuth access token | token for one SBI service accepted by another NF service |
| Apple Intelligence | TGT and OTT | stolen tokens replayed on another device |
| MCP tool ecosystems | delegated OAuth context / tool authority | malicious tool induces use of another tool’s authenticated capability |
| Cross-chain bridges | proofs, messages, events, signatures | forged, replayed, or misparsed cross-domain token transitions |
In the Android WebView setting, the paper presents both browser-mediated and app-mediated variants. The host app can use WebView.loadUrl, WebView.loadData, or WebView.postUrl to issue authenticated requests inside the WebView session, or it can call CookieManager.getCookie(url) and then replay the cookie via httpPost.setHeader("Cookie", cookie) in a raw HttpClient request (Bhavani, 2014). In Apple’s XARA work, related cross-app resource access can steal an iCloud token, the Evernote authentication token, the Pushbullet secret token, or browser-stored credentials by abusing keychain items, URL schemes, NSConnection, WebSocket endpoints, or Bundle ID confusion (Xing et al., 2015).
In bridge systems, the cross-service boundary is the chain boundary. The SoK on cross-chain bridges describes lock-and-mint and liquidity-pool-based communication models, then catalogs attack vectors such as problematic mint, fake burn, incorrect release, replayed withdraw, incorrect event emission, and fake event emission. These attacks violate the integrity of token movement between services or chains: unbacked wrapped assets can be minted, locked assets can be released without a valid burn, and proofs or events can be replayed or forged (Zhang et al., 2023).
This suggests a common abstraction: the artifact being misused need not be an OAuth bearer token. It may be a key handle, JWT, cookie, proof, validator signature set, one-time token, PendingIntent, or even a service-produced instruction channel whose outputs another service obeys.
4. Attack mechanics and validation blind spots
Many attacks follow a two-stage or multi-stage structure. The OpenID Connect paper explicitly frames its contribution as a class of second-order vulnerabilities: first, attacker-supplied endpoint metadata is stored by the client through Discovery; later, the stored values are reused in security-critical operations such as token redemption or userinfo retrieval (Mladenov et al., 2015). The WebView paper has the same temporal structure in simpler form: the user first authenticates to the trusted site inside WebView, then the host app reuses the resulting session cookie or session ID to send forged requests (Bhavani, 2014).
Extraction or observability is often local rather than cryptographic. On Android, NotificationListenerService exposes contentIntent, action intents, and delete intents from posted notifications, which is sufficient to steal a legitimate partner’s PendingIntent for later replay (Khinda, 3 Mar 2026). On Apple Intelligence, the reverse-engineered token path ultimately reaches SecItemCopyMatching, and the paper shows that token payloads can also be read with /usr/bin/security; the actual token bytes are recovered from the returned plist (Zhou et al., 17 Apr 2026). In WebAuthn, no token is extracted at all; instead, the browser’s silent processing of allowCredentials becomes a timing oracle (Kepkowski et al., 2022).
Acceptance typically hinges on a server-side blind spot. In the WebView case, the remote service authenticates based on session cookies and cannot distinguish the host app from the browser-like context that already holds the authenticated state (Bhavani, 2014). In free5GC, the producer NF performs JWT parsing but fails to reject mismatched scope, so “an access token with an arbitrary scope field value will be accepted by an arbitrary NF” (Chen et al., 10 Sep 2025). In the PendingIntent case, the provider service upgrades “creator package” into proof of present caller identity, even though the token is transferable (Khinda, 3 Mar 2026). In bridge exploits, the blind spots are proof uniqueness, validator trust, event origin, or missing accounting constraints; the SoK’s “replayed / unlimited withdraw” class is the most literal example of a reusable authorization artifact that was not consumed exactly once (Zhang et al., 2023).
Agentic systems add a distinct blind spot: validation is often attached to final answers or API compatibility rather than to the entire execution trajectory. The tool-layer economic DoS paper keeps the final payload correct and function signatures unchanged, yet expands a task into trajectories exceeding 60,000 tokens, inflates costs by up to 658x, raises energy by 100–560x, drives GPU KV cache occupancy from less than 1% to 35–74%, and cuts co-running throughput by approximately 50% (Zhou et al., 16 Jan 2026). The malicious MCP server paper makes the same architectural point for authority rather than cost: the dangerous step is not direct server-to-server compromise, but orchestrator-mediated data flow across tools (Croce et al., 26 Jul 2025).
5. Defensive principles and verification strategies
The dominant defensive principle is stronger binding between artifact and authorized context. In OpenID Connect, the proposed mitigations include OP whitelisting, endpoint restrictions, and binding Discovery to the later authentication response through issuer validation, so that a malicious Discovery service cannot mix authEndp from one service with tokenEndp from another (Mladenov et al., 2015). In Android SDK ecosystems, the paper’s defense replaces transferable PendingIntent-based authentication with Bound Service IPC authenticated by Binder.getCallingUid(), augmented by signer certificate verification and server-side certificate-hash validation (Khinda, 3 Mar 2026). In Apple Intelligence, the paper argues that non-transferability requires cryptographic binding to the rightful user or device, and discusses sender-constrained or hardware-bound designs as the natural direction (Zhou et al., 17 Apr 2026).
Timing, replay, and amplification channels require separate controls. For FIDO2, the strongest authenticator-side fix is constant-time key-handle processing so that “wrong token,” “wrong RP,” and “correct RP” paths do not diverge measurably. The paper also discusses a KDF-based non-resident-key design and notes browser-side mitigations such as deduplicating allowCredentials, adding random delays to silent failures, and limiting the list size; Chromium adopted deduplication plus a limit of 64 key handles under CVE-2021-38022 (Kepkowski et al., 2022). For bridges, the verification framework in GoAT-X elevates ValidProof(M,signature), NonceUnused(chain,nonce), LockedCorrect(sender,token,amount), and UnlockedCorrect(receiver,token,amount) into explicit predicates, then reports 92% recall on fine-grained audit points, 95% coverage of vulnerable projects, and 117 confirmed risks in the wild (Feng et al., 27 Apr 2026).
Composition-heavy systems need isolation and trajectory-aware controls. The MCP trojan paper recommends capability-based permissions, mandatory access boundaries, and the ability to designate servers as sensitive with restricted interoperability (Croce et al., 26 Jul 2025). The tool-layer resource-amplification paper argues for a shift “from validating final answers to monitoring the economic and computational cost of the entire agentic process,” and specifically implies per-session token budgets, chain-length controls, tool-response sanitization, and behavioral baselines for normal tool-calling patterns (Zhou et al., 16 Jan 2026). By contrast, the WebView paper is diagnostically strong but weak on concrete defenses; it states that the attacks are easy to execute, difficult to detect and prevent, and leaves solutions to future work (Bhavani, 2014).
Telecom systems require the same discipline at a different layer. The 5G SBA case makes clear that token integrity is not enough: the producer NF must actually enforce scope, audience, and service identity rather than merely parse the JWT. The paper also indicates that richer 3GPP authorization attributes, such as NF instance identity and slice constraints, need to be encoded and validated rather than ignored (Chen et al., 10 Sep 2025).
6. Misconceptions, limits, and research directions
A common misconception is that unique per-service credentials or anonymous tokens automatically prevent correlation or replay. The FIDO2 paper refutes the first point: per-service key pairs do not guarantee unlinkability if key-handle processing leaks timing structure across services (Kepkowski et al., 2022). The Apple Intelligence paper refutes the second: anonymized TGTs and OTTs do not guarantee security when tokens are locally retrievable and not sender-constrained (Zhou et al., 17 Apr 2026).
Another misconception is that every attack in this area is a strict service-to-service bearer-token replay. Several important works are only partially on target. The Android WebView attack targets the same remote site that authenticated the user; it is therefore more precisely “session/cookie reuse via embedded browser context across application boundaries” than a federated cross-service replay (Bhavani, 2014). TULIP is adjacent because it reduces the usefulness of stolen credentials and MFA bombing in SSO environments, but it does not analyze theft of access tokens, ID tokens, refresh tokens, SAML assertions, or RP session cookies, and its enrollment JWT is not RP-scoped (Hays et al., 2024). The MCP cross-tool exfiltration paper is closer to confused-deputy authority abuse than to direct token theft, though it makes plain how already-authenticated tools can be induced to act for unrelated workflows (Croce et al., 26 Jul 2025).
A further misconception is that protocol compliance or correct outputs imply safety. OIDC malicious endpoints preserve nominal protocol phases while redirecting sensitive artifacts (Mladenov et al., 2015). MCP-compatible tool servers can remain protocol-compatible and still drive economically catastrophic multi-turn trajectories while returning the correct final answer (Zhou et al., 16 Jan 2026). In cross-chain systems, the SoK and GoAT-X both show that the decisive failures are often semantic gaps—missing constraints, bypassable validations, replayable proofs, inconsistent event handling, or accounting mismatches—rather than cryptographic breaks (Zhang et al., 2023, Feng et al., 27 Apr 2026).
The literature therefore points toward a stable research agenda. Tokens and token-like artifacts need tighter audience and service binding, presenter authentication, and proof-of-possession properties. Failure handling must be constant-time where unlinkability is claimed. Cross-context composition needs explicit capability boundaries. Proofs, nonces, and messages must be uniquely consumed. Standards and implementations must be checked for semantic alignment rather than only for syntactic conformance. This suggests that cross-service token attack is best understood as a class of semantic trust-boundary failures: the system accepts the right artifact in the wrong place, from the wrong presenter, for the wrong service, or along the wrong execution path.