Dev rejects CVE severity, makes his GitHub repo read-only

Original Article ↗ Hacker News Discussion ↗

Context: node-ip CVE and maintainer reaction

  • A widely-used npm package (ip / node-ip) received a high‑severity CVE for misclassifying certain nonstandard IP representations (e.g., hex) as public, enabling potential SSRF scenarios.
  • The maintainer patched the issue earlier but was later inundated with demands and tooling noise about old vulnerable versions, then made the repo read‑only and pushed back against the process.

Burden on Open Source Maintainers

  • Many argue unpaid maintainers shouldn’t be treated as on‑call security staff for companies building products on their work.
  • Some suggest using copyleft licenses (GPL/AGPL) partly to deter freeloading commercial users.
  • Others emphasize the “no warranty” clauses in common OSS licenses and say users must take responsibility for dependencies or pay for support.

CVE System and Severity Scoring

  • Strong criticism of the CVE “industrial complex”: incentives to collect CVEs for resumes or bounties lead to noisy, marginal, or mischaracterized reports.
  • The specific CVE’s 9.8 score is widely viewed as absurd relative to much more serious issues (e.g., RCE in OS components).
  • Several comments explain CVSS is mechanically computed from abstract vectors, not real‑world prevalence or exploitability, making scores misleading for triage.
  • Concern that bogus or inflated CVEs cause alert fatigue, break builds, and erode trust in genuine advisories.

Is the node-ip issue “real”?

  • Some view it as a legitimate but low‑impact bug: a parsing/validation library used in trust boundaries misclassifies certain addresses.
  • Others argue the exploit chain requires rare conditions (hex IPs, specific isPublic usage, SSRF) and should not be labeled critical.

Security Process, Tools, and CISOs

  • Multiple stories of automated scanners and security offices opening mass tickets for low‑impact issues without contextual analysis.
  • Some security professionals in the thread push back, saying good practice is to patch locally, contribute PRs upstream, and avoid offloading work onto maintainers.

Responsibility: Library vs Application

  • Debate over whether vulnerabilities belong to libraries or only to consuming applications.
  • One side: if a library claims to validate untrusted input, security bugs in it merit CVEs.
  • Other side: many CVEs are really normal bugs, and apps must assess whether they are truly exposed.

Proposed Improvements

  • Ideas include:
    • Maintainers registering as CNAs to dispute frivolous CVEs.
    • Requiring proof‑of‑concept or minimal exploitable examples.
    • “Proof of work” via suggested patches with reports.
    • Risk metrics for packages (e.g., maintainer count, bus factor).
    • Authority weighting or reputation for advisories.