CVE-2026-82454: Omnivore API Auth Bypass Vulnerability

CVE-2026-82454 Overview

The Omnivore API (packages/api) contains an authentication bypass in its Apple sign-in token verification logic. The decodeAppleToken function extracts the alg field from an attacker-controlled JWT header and passes it as the sole allowed algorithm to jwt.verify(). Because jsonwebtoken v8 does not validate key and 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. This bypasses signature verification and allows impersonation of any Apple-linked account. The issue is tracked as [CWE-347: Improper Verification of Cryptographic Signature].

Critical Impact

Unauthenticated remote attackers can forge Apple sign-in tokens to impersonate any Apple-linked Omnivore account, leading to full account takeover.

Affected Products

• Omnivore API (packages/api) before commit abf53d6
• Omnivore Android application before version 0.227.0
• Omnivore deployments relying on Apple sign-in authentication

Discovery Timeline

• 2026-08-29 - CVE-2026-82454 published to NVD
• 2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82454

Vulnerability Analysis

The vulnerability is a classic JWT algorithm confusion attack. Apple sign-in issues identity tokens signed with RS256, an asymmetric algorithm where Apple's private key signs the token and the public key verifies it. The Omnivore API fetches Apple's public key using the kid claim, then trusts the alg header from the token itself when calling jwt.verify().

An attacker crafts a token with alg set to HS256, a symmetric HMAC algorithm. Because jsonwebtoken v8 does not enforce that the key type matches the declared algorithm, it treats Apple's public RSA key as the HMAC shared secret. The attacker, who also possesses that public key (it is published by Apple), can compute a valid HMAC signature over any payload. The forged token then passes verification, and the API accepts arbitrary sub, email, and aud claims.

Root Cause

The root cause is trusting attacker-controlled JWT header fields during signature verification. The algorithms parameter to jwt.verify() must be a hardcoded allowlist. Sourcing it from the token itself defeats the purpose of the parameter and enables algorithm confusion.

Attack Vector

Exploitation requires only network access to the Omnivore API's Apple sign-in endpoint. No prior authentication, user interaction, or privileged position is required. The attacker constructs a JWT with alg=HS256, a valid kid referencing an Apple JWKS entry, and claims matching the target account. They sign the token using Apple's public key bytes as the HMAC secret and submit it to the login endpoint.

// Security patch in packages/api/src/routers/auth/apple_auth.ts
// Fix: hardcode RS256 in Apple JWT verification to prevent algorithm confusion (#4652)
   token: string
 ): Promise<DecodeTokenResult> {
   const decodedToken = jwt.decode(token, { complete: true })
-  const { kid, alg } = (decodedToken as any).header
+  const { kid } = (decodedToken as any).header
 
   try {
     const publicKey = await fetchApplePublicKey(kid)
     if (!publicKey) {
       return { errorCode: 500 }
     }
-    const jwtClaims: any = jwt.verify(token, publicKey, { algorithms: [alg] })
+    const jwtClaims: any = jwt.verify(token, publicKey, {
+      algorithms: ['RS256'],
+    })
     const issVerified = (jwtClaims.iss ?? '') === appleBaseURL
     const audience = jwtClaims.aud ?? ''
     const audVerified = audience == webAudienceName || audience === audienceName
// Source: https://github.com/omnivore-app/omnivore/commit/abf53d6508755d3d22a994e28e370a9193ea977a

The patch removes alg from the destructured header and hardcodes algorithms: ['RS256'], forcing verification to reject any token that does not use Apple's expected asymmetric algorithm.

Detection Methods for CVE-2026-82454

Indicators of Compromise

• Apple sign-in JWTs presented to the Omnivore API with an alg header value other than RS256 (particularly HS256, HS384, or HS512).
• Successful authentication events for Apple-linked accounts that lack a corresponding legitimate Apple authorization redirect.
• New session creation for existing Apple-linked users from unfamiliar IP addresses or user agents shortly after public disclosure.

Detection Strategies

• Log the JWT header (alg, kid) for every token processed by decodeAppleToken and alert on any non-RS256 value.
• Correlate Apple sign-in success events with Apple's OAuth authorization callback traffic; standalone successes with no upstream authorization are suspicious.
• Review application logs for repeated jwt.verify() failures followed by a success from the same client, which can indicate algorithm probing.

Monitoring Recommendations

• Instrument the authentication router to emit structured logs including alg, kid, iss, aud, and remote IP.
• Forward authentication telemetry to a centralized data lake for retroactive hunting across the disclosure window.
• Track anomalous rates of account access, mail address changes, or export operations on Apple-linked accounts.

How to Mitigate CVE-2026-82454

Immediate Actions Required

• Deploy the Omnivore API build that includes commit abf53d6 or later, and update Android clients to version 0.227.0 or later.
• Invalidate all active sessions and refresh tokens tied to Apple sign-in accounts to evict any attacker-established sessions.
• Audit accounts for unauthorized changes to email, linked identities, and API keys since the vulnerability window began.

Patch Information

The fix is applied in Omnivore commit abf53d6, delivered via Pull Request #4652. The patch hardcodes algorithms: ['RS256'] in the jwt.verify() call within packages/api/src/routers/auth/apple_auth.ts, eliminating attacker control over the accepted algorithm. Additional context is available in the VulnCheck Advisory for Omnivore.

Workarounds

• If patching is delayed, temporarily disable the Apple sign-in provider and require users to authenticate via email or another identity provider.
• Place a reverse proxy or WAF rule in front of the Apple sign-in endpoint that rejects any JWT whose header alg is not exactly RS256.
• Upgrade the jsonwebtoken dependency to a version that enforces key and algorithm compatibility as a defense-in-depth control.

# Reject non-RS256 Apple tokens at the edge (example nginx/openresty snippet)
access_by_lua_block {
  local jwt_header = ngx.req.get_headers()["Authorization"]
  if jwt_header then
    local token = jwt_header:gsub("Bearer ", "")
    local header_b64 = token:match("([^.]+)")
    local header_json = ngx.decode_base64(header_b64)
    if header_json and not header_json:find('"alg":"RS256"') then
      ngx.exit(401)
    end
  end
}