How severe is GHSA-88q6-jcjg-hvmw?

No CVSS score has been assigned to GHSA-88q6-jcjg-hvmw yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-88q6-jcjg-hvmw?

GHSA-88q6-jcjg-hvmw affects the following packages: github.com/beatt83/jose-swift (SwiftURL). Ecosystems affected: SwiftURL.

How do I fix GHSA-88q6-jcjg-hvmw?

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.

How do I detect GHSA-88q6-jcjg-hvmw in my SwiftURL dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/beatt83/jose-swift. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-88q6-jcjg-hvmw if there is no patch (or I can't update yet)?

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.

How does O3 Security protect against GHSA-88q6-jcjg-hvmw?

O3 pinpoints whether GHSA-88q6-jcjg-hvmw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-88q6-jcjg-hvmw actively exploited in the wild?

No public exploit code has been indexed for GHSA-88q6-jcjg-hvmw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-88q6-jcjg-hvmw published, and has it been updated?

GHSA-88q6-jcjg-hvmw was published on January 9, 2026 and was last updated on March 25, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 SwiftURL

GHSA-88q6-jcjg-hvmw

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

Blast Radius

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:

Checking if the signature is empty or present
Validating the token against any key
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

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.

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

Ecosystem	Package	Vulnerable range	Fix
📦SwiftURL	`github.com/beatt83/jose-swift`	all versions	6.0.2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/beatt83/jose-swift. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
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.
How O3 protects you
O3 pinpoints whether GHSA-88q6-jcjg-hvmw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

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 detects GHSA-88q6-jcjg-hvmw across SwiftURL dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works