NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦 SwiftURL
Not in CISA KEV

jose-swift has JWT Signature Verification Bypass via None AlgorithmGHSA-88q6-jcjg-hvmw

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.

Published
Updated
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

    Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

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?

Find it across SwiftURL, including transitive dependencies.

jose-swift has JWT Signature Verification Bypass via None…