Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 SwiftURL
Not in CISA KEV

GHSA-88q6-jcjg-hvmw jose-swift

Fix: beatt83/jose-swift#62

GHSA-88q6-jcjg-hvmw is a security vulnerability in github.com/beatt83/jose-swift. A fix is available for github.com/beatt83/jose-swift — see the affected versions and patch details below.

jose-swift has JWT Signature Verification Bypass via None Algorithm

Published
Jan 9, 2026
Updated
Mar 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Mar 25, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
📦github.com/beatt83/jose-swift

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects SwiftURL packages — download data is not available via public APIs for these ecosystems.

Description

Summary

An authentication bypass vulnerability allows any unauthenticated attacker to forge arbitrary JWT tokens by setting "alg": "none" in the token header. The library's verification functions immediately return true for such tokens without performing any cryptographic verification, enabling complete impersonation of any user and privilege escalation.

Details

The vulnerability exists in Sources/JSONWebSignature/JWS+Verify.swift at lines 34-37:

  public func verify<Key>(key: Key?) throws -> Bool {
      guard SigningAlgorithm.none != protectedHeader.algorithm else {
          return true  // <-- Vulnerability: returns true without verification
      }

When the JWT header contains "alg": "none", the verify() method returns true immediately without:

  1. Checking if the signature is empty or present
  2. Validating the token against any key
  3. Requiring explicit opt-in from the caller

The SigningAlgorithm enum in Sources/JSONWebAlgorithms/Signatures/SigningAlgorithm.swift:72 explicitly includes case none = "none" as a valid algorithm.

All verification methods are affected:

  • JWS.verify(key:) - Instance method
  • JWS.verify(jwsString:payload:key:) - Static method
  • JWT.verify(jwtString:senderKey:) - High-level API

PoC

  1. Create a forged JWT with modified claims: // Forged header with alg:none let header = #"{"alg":"none","typ":"JWT"}"#

// Attacker's payload with escalated privileges let payload = #"{"sub":"user123","admin":true}"#

// Base64URL encode and concatenate with empty signature let forgedToken = base64url(header) + "." + base64url(payload) + "." // Result: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJ1c2VyMTIzIiwiYWRtaW4iOnRydWV9.

  1. Verify the forged token passes verification: let jws = try JWS(jwsString: forgedToken) let isValid = try jws.verify(key: legitimateSecretKey) // Returns TRUE

Impact

This is an authentication bypass vulnerability. Who is impacted: Any application using jose-swift for JWT verification is vulnerable. An attacker can:

  • Forge identity: Create tokens claiming to be any user
  • Escalate privileges: Add admin/superuser claims to gain unauthorized access
  • Bypass authentication entirely: Access protected resources without valid credentials
  • Modify any claim: Change expiration, audience, issuer, or any custom claims

The attack requires no knowledge of the signing key and works against all signature algorithms (HS256, RS256, ES256, etc.) since the attacker simply bypasses signature verification entirely.

Credits

Reported by Louis Nyffenegger - https://pentesterlab.com/

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦SwiftURLgithub.com/beatt83/jose-swiftall versions6.0.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/beatt83/jose-swift, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/beatt83/jose-swift to 6.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-88q6-jcjg-hvmw is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-88q6-jcjg-hvmw can be triaged on real exposure rather than presence alone.

Tailored to GHSA-88q6-jcjg-hvmw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary An authentication bypass vulnerability allows any unauthenticated attacker to forge arbitrary JWT tokens by setting "alg": "none" in the token header. The library's verification functions immediately return `true` for such tokens without performing any cryptographic verification, enabling complete impersonation of any user and privilege escalation. ### Details The vulnerability exists in Sources/JSONWebSignature/JWS+Verify.swift at lines 34-37: ``` public func verify<Key>(key: Key?) throws -> Bool { guard SigningAlgorithm.none != protectedHeader.algorithm else {
O3 Security · Impact-Aware SCA

Is GHSA-88q6-jcjg-hvmw in your dependencies?

O3 Security finds GHSA-88q6-jcjg-hvmw across SwiftURL dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-88q6-jcjg-hvmw: jose-swift Auth Bypass | O3 Security