GHSA-v83q-83hj-rw38
ntpd NTS client denial of service via wrongly sized cookies
Blast Radius
ntpdReal-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
Two denial of service vulnerabilities were found in ntpd-rs related to the handling of NTS cookies in our client functionality. Whenever an NTS source is configured and the server behind that source is sending zero-sized cookies or cookies larger than what would fit in our buffer size, ntpd-rs would crash. Only configured NTS sources can abuse these vulnerabilities. NTP sources or third parties that are not configured cannot make use of these vulnerabilities.
For zero-sized cookies: a division by zero would force an exit when the number of new cookies that would need to be requested is calculated. In ntpd-rs 1.5.0 a check was added to prevent the division by zero.
For large cookies: while trying to send a NTP request with the cookie included, the buffer is too small to handle the cookie and an exit of ntpd-rs is forced once a write to the buffer is attempted. The memory outside the buffer would not be written to in this case. In ntpd-rs 1.5.0 a check was added that prevents accepting cookies larger than 350 bytes.
Users of older versions of ntpd-rs are recommended to update to the latest version. If an update is impossible, it is recommended to only add NTS sources to ntpd-rs that are trusted to not abuse this bug.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | ntpd | all versions | 1.5.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ntpd. 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 ntpd to 1.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v83q-83hj-rw38 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-v83q-83hj-rw38 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-v83q-83hj-rw38. 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-v83q-83hj-rw38 in your dependencies?
O3 detects GHSA-v83q-83hj-rw38 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.