Summary
Sharks has a Bias of Polynomial Coefficients in Secret Sharing
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.
Impact
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-JP37-5QHW-MFFW? GHSA-JP37-5QHW-MFFW is a medium-severity security vulnerability in sharks (rust), affecting versions <= 0.5.0. No fixed version is listed yet.
- Which versions of sharks are affected by GHSA-JP37-5QHW-MFFW? sharks (rust) versions <= 0.5.0 is affected.
- Is there a fix for GHSA-JP37-5QHW-MFFW? No fixed version is listed for GHSA-JP37-5QHW-MFFW yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-JP37-5QHW-MFFW exploitable, and should I be worried? Whether GHSA-JP37-5QHW-MFFW is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-JP37-5QHW-MFFW is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.