Belkin F9K1015 CVE-2025-11300

Exploitation requires network reachability to the router's HTTP management interface and the ability to invoke /goform/formWlanMP with a manipulated ateFunc parameter. The CVSS vector specifies PR:L, so some level of authentication or privilege is required rather than fully anonymous access, which limits mass exploitation; no user interaction is needed (UI:N). Realistic exposure is constrained to environments still operating the specific end-of-life Belkin F9K1015 running firmware 1.00.10, and because the management interface is typically LAN-facing, internet-wide exploitation depends on remote-administration being enabled or the attacker already being on the local network. No patch exists (vendor unresponsive), so affected devices remain permanently vulnerable.

Signals are mixed and point to a low-to-moderate real-world priority despite the HIGH-ish 7.4 CVSS 4.0 score. The vendor's CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VC:H/VI:H/VA:H) claims remote, low-complexity, low-privilege exploitation with full confidentiality/integrity/availability impact, and a public exploit exists (E:P) - these are the strongest risk drivers. EPSS of 0.84% (56th percentile) is middling: elevated above the long tail of unexploited CVEs (consistent with a released PoC) but far from values typical of mass-exploited flaws, suggesting no observed widespread scanning. There is NO CISA KEV listing, so there is no evidence of active exploitation. Two important caveats: (1) VulDB-sourced buffer-overflow entries frequently describe conditions that in practice yield only a crash/DoS rather than confirmed arbitrary code execution, so the full VI:H/VC:H code-execution impact is optimistic and unverified; (2) the vector asserts PR:L (some authentication needed), which tempers unauthenticated-mass-exploitation risk. Net: a genuine but niche issue - public PoC against an end-of-life consumer router with an unresponsive vendor (no patch), relevant mainly to anyone still running this specific hardware.

An attacker with network access to the router's web interface sends a crafted request to /goform/formWlanMP manipulating the ateFunc argument to overflow a fixed-size buffer in the WLAN manufacturing-test handler. A public proof-of-concept is already published on GitHub, so the barrier to reproduction is low; a successful overflow at minimum crashes the HTTP service (DoS) and may, per the vendor's claim, allow code execution on the device.