How severe is GHSA-hxhc-wmg8-xrqf?

No CVSS score has been assigned to GHSA-hxhc-wmg8-xrqf yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-hxhc-wmg8-xrqf?

GHSA-hxhc-wmg8-xrqf affects the following packages: namshi/jose (Packagist), namshi/jose (Packagist), namshi/jose (Packagist), namshi/jose (Packagist). Ecosystems affected: Packagist.

How do I fix GHSA-hxhc-wmg8-xrqf?

Update namshi/jose to 1.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hxhc-wmg8-xrqf is resolved across your whole dependency graph.

How do I detect GHSA-hxhc-wmg8-xrqf in my Packagist dependencies?

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

How do I mitigate GHSA-hxhc-wmg8-xrqf 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.

Is GHSA-hxhc-wmg8-xrqf actively exploited in the wild?

No public exploit code has been indexed for GHSA-hxhc-wmg8-xrqf 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-hxhc-wmg8-xrqf published, and has it been updated?

GHSA-hxhc-wmg8-xrqf was published on May 17, 2024 and was last updated on December 2, 2024. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

namshi/jose insecure JSON Web Signatures (JWS)

Real-World Exposure

4 pkgs affected

🐘namshi/jose🐘namshi/jose🐘namshi/jose🐘namshi/jose

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

Description

namshi/jose allows the acceptance of unsecure JSON Web Signatures (JWS) by default. The vulnerability arises from the $allowUnsecure flag, which, when set to true during the loading of JWSes, permits tokens signed with 'none' algorithms to be processed. This behavior poses a significant security risk as it could allow an attacker to impersonate users by crafting a valid jwt token.

Affected Packages

4 total 4 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`namshi/jose`	all versions	1.1.2`composer require namshi/jose:^1.1.2`
🐘Packagist	`namshi/jose`	≥ 1.2.0&&< 1.2.2	1.2.2`composer require namshi/jose:^1.2.2`
🐘Packagist	`namshi/jose`	≥ 2.0.0&&< 2.0.3	2.0.3`composer require namshi/jose:^2.0.3`
🐘Packagist	`namshi/jose`	≥ 2.1.0&&< 2.1.2	2.1.2`composer require namshi/jose:^2.1.2`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for namshi/jose, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update namshi/jose to 1.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hxhc-wmg8-xrqf 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.

Frequently Asked Questions

namshi/jose allows the acceptance of unsecure JSON Web Signatures (JWS) by default. The vulnerability arises from the $allowUnsecure flag, which, when set to true during the loading of JWSes, permits tokens signed with 'none' algorithms to be processed. This behavior poses a significant security risk as it could allow an attacker to impersonate users by crafting a valid jwt token.

O3 Security · Impact-Aware SCA

Is GHSA-hxhc-wmg8-xrqf in your dependencies?

Find it across Packagist, including transitive dependencies.

Scan my dependencies How O3 SCA works

namshi/jose insecure JSON Web Signatures (JWS)GHSA-hxhc-wmg8-xrqf