Description

The Omnivore API (packages/api) before the fix in commit abf53d6 contains an authentication bypass in Apple sign-in token verification. The decodeAppleToken function extracted the 'alg' field from the attacker-supplied JWT header and passed it as the sole allowed algorithm to jwt.verify(). Using jsonwebtoken v8 (which does not validate key/algorithm compatibility), an attacker can set alg=HS256 and sign a forged token using Apple's publicly available RSA public key as the HMAC secret, bypassing signature verification and impersonating any Apple-linked account.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-29T14:16:38.480Z",
  "pubdate": "2026-08-29T14:16:38.480Z",
  "executiveSummary": "The Omnivore API contains a critical authentication bypass vulnerability in the Apple sign-in token verification process. The flaw resides in the decodeAppleToken function, which improperly handles user-supplied JSON Web Token (JWT) headers.\nBy manipulating the 'alg' header parameter, an attacker can force the application to use the HS256 algorithm instead of the expected asymmetric RSA algorithm. Exploiting the behavior of jsonwebtoken v8, which fails to enforce key-type compatibility, allows an attacker to sign a forged JWT using a publicly available RSA public key as an HMAC secret.\nThis vulnerability allows an unauthenticated attacker to impersonate any user registered via Apple sign-in, leading to full account takeover. The impact is severe, resulting in unauthorized access to sensitive user data and complete identity spoofing within the Omnivore platform. The flaw affects the packages/api component before commit abf53d6.",
  "technicalDetails": "The root cause of this vulnerability is an improper implementation of JWT verification logic within the decodeAppleToken function. The application extracts the 'alg' field directly from the untrusted JWT header provided by the client and passes this value into the jwt.verify() function as the sole allowed algorithm.\nThis behavior exposes the system to an 'alg' algorithm switching attack. Specifically, the implementation relies on jsonwebtoken v8, which is susceptible to a key confusion attack. In an RSA-based JWT flow, the server expects an asymmetric signature verified with a public key. However, by changing the 'alg' header to 'HS256', the attacker forces the library to treat the token as a symmetric HMAC-signed token.\nThe exploitation flow is as follows: 1) The attacker obtains Apple's public key (e.g., from the public JWKS endpoint). 2) The attacker crafts a malicious JWT with the payload containing the targeted user's Apple ID or identifier. 3) The attacker sets the 'alg' header to 'HS256'. 4) The attacker signs the forged JWT using the base64-encoded bytes of the RSA public key as the HMAC shared secret. 5) When the server receives the malicious token, it reads the 'alg: HS256' header, retrieves the RSA public key, and attempts to verify the HMAC signature of the token against that public key acting as a secret.\nBecause the server uses a trusted public key as a secret for the HMAC algorithm, the cryptographic check succeeds. The application then trusts the forged payload and considers the user successfully authenticated. This bypasses the intended security controls that require Apple's private key to sign the token. Consequently, an attacker can effectively impersonate any user on the platform without requiring prior authentication or knowledge of valid secrets, provided they can identify the target's Apple-associated identifier. The vulnerability is network-exploitable and requires no specific privileges other than access to the public API endpoint."
}