D-Link says it won't patch 60k older modems

Original Article ↗ Hacker News Discussion ↗

Vulnerability and Technical Details

  • Core issue: unauthenticated command injection in D‑Link firmware (notably NAS and some DSL routers) via a CGI endpoint that builds shell commands unsafely.
  • The CGI script calls a helper binary which uses sprintf + system() with user-controlled input, effectively allowing arbitrary shell execution.
  • Some debate over exact URL encoding in the proof-of-concept, but consensus that the implementation is egregiously insecure and yields instant root via a simple GET.

CVE Scores and Real-World Risk

  • Multiple CVEs (some at 9.8) across NAS and router product lines; some fixed via firmware, others explicitly “no fix, buy a new one.”
  • Discussion that CVSS scores are often misused or sensationalized, yet a 9.8 on an internet-exposed device is widely seen as genuinely serious.
  • Several note that exposing consumer NAS directly to the internet has long been risky regardless of vendor.

D-Link’s Response and EOL Debate

  • D-Link declines to patch older, EOL devices (around 60k modems/routers), telling users to replace them.
  • Some argue this is expected once EOL is clearly signposted; others say the devices shipped “defective” and should be fixed regardless of age.
  • Many doubt typical consumers understand or even know about EOL timelines, especially for ISP‑provided hardware.

User Impact, Botnets, and Threat Models

  • Concern that unpatched devices become easy botnet nodes and may be abused for traffic proxying, DDoS, or ransomware entry points.
  • Discussion of how powerful router SoCs are sufficient for traffic redirection, MITM (if you can get a cert installed), or bricking.

Alternatives and Workarounds

  • Strong recommendations for OpenWRT, MikroTik, Ubiquiti, OPNsense/pfSense, and OpenBSD-based setups for long-term support.
  • Caveats: many affected D-Link models lack resources or active OpenWRT support; consumer “flash your own firmware” is niche.

Regulation, Liability, and Firmware Openness

  • Proposals: mandatory minimum support periods, on-box EOL dates, auto‑update and explicit EOL warnings, or forced open-sourcing of firmware at EOL.
  • EU initiatives (Cyber Resilience Act, Product Liability Directive) are cited as moves toward requiring vulnerability handling for a defined support period.
  • Concerns that simply “dumping code on the community” doesn’t guarantee competent third‑party maintenance.

Broader IoT Software Quality Concerns

  • Many see this as symptomatic of cheap, outsourced IoT firmware with minimal security practices.
  • Repeated theme: consumers get low prices at the cost of security, longevity, and environmental waste from premature obsolescence.