GHSA-8q6v-474h-whgg
GHSA-8q6v-474h-whgg is a CWE-331 vulnerability in thinbus-srp. O3 Security confirms whether GHSA-8q6v-474h-whgg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
The Thinbus Javascript Secure Remote Password (SRP) Client Generates Fewer Bits of Entropy Than Intended
Blast Radius
thinbus-srpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
A protocol compliance bug in thinbus-srp-npm versions prior to 2.0.1 causes the client to generate a fixed 252 bits of entropy instead of the intended bit length of the safe prime (defaulted to 2048 bits). RFC 5054 states in section 2.5.4 Client Key Exchange
The client key exchange message carries the client's public value (A). The client calculates this value as A = g^a % N, where a is a random number that SHOULD be at least 256 bits in length.
The client public value is being generated from a private value that is 4 bits below the specification. This reduces the protocol's designed security margin it is now practically exploitable. The servers full sized 2048 bit random number is used to create the shared session key and password proof.
Patches
The issue is fixed in versions >= 2.0.1
Workarounds
It is possible to patch a legacy version:
// WRONG
var hexLength = this.toHex(N).length;
// CORRECT
var hexLength = this.toHex(this.N()).length;
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | thinbus-srp | all versions | 2.0.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thinbus-srp. 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 thinbus-srp to 2.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8q6v-474h-whgg 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-8q6v-474h-whgg 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-8q6v-474h-whgg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8q6v-474h-whgg in your dependencies?
O3 detects GHSA-8q6v-474h-whgg across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.