GHSA-jp37-5qhw-mffw — sharks
GHSA-jp37-5qhw-mffw is a security vulnerability in sharks. No vendor fix is recorded yet; mitigation options are listed below.
Sharks has a Bias of Polynomial Coefficients in Secret Sharing
Real-World Exposure
sharksReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range [0, 255] they were instead in the range [1, 255]. A description from Cure53, who originally found the issue, is available:
The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing. Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same secret has been distributed 500-1500 times.
Secrets that have been shared a low amount of times (ideally, once) would not be impacted. However, secrets that are repeatedly shared may be vulnerable, especially if the shares are still available, and should be rotated.
The vulnerability does not impact reconstitution of secrets: secrets that have already been split can be recombined without issue.
The flaw can be corrected by changing the lower bound of the polynomial coefficient range in the sharks::math::random_polynomial function to 0. The blahaj crate has been made available with a fixed version of the code, after attempts to reach the maintainer of the sharks crate were unsuccessful.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | sharks | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sharks, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of sharks has shipped for GHSA-jp37-5qhw-mffw yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-jp37-5qhw-mffw can be triaged on real exposure rather than presence alone.
Tailored to GHSA-jp37-5qhw-mffw. 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-jp37-5qhw-mffw in your dependencies?
O3 Security finds GHSA-jp37-5qhw-mffw across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.