Is CVE-2021-35395 (Realtek AP-Router SDK Buffer Overflow) being exploited in the wild?

What “exploited in the wild” means for this CVE

For a vulnerability question like this, the practical answer is not whether a proof of concept exists, but whether authoritative sources treat the issue as actively abused. CISA’s KEV listing is the strongest public signal here because it reflects confirmed exploitation, which is why defenders use it as a triage trigger rather than a theoretical warning. For current vulnerability handling, CISA Known Exploited Vulnerabilities Catalog is the right authoritative reference point.

The underlying weakness is a buffer overflow in the Realtek AP-Router SDK HTTP web server boa, caused by unsafe copying of overly long form parameters. That means exposure is not just about the CVE label, but about whether any router, embedded gateway, or downstream product actually includes that SDK component and accepts the vulnerable request path. For product and record confirmation, CVE Program and NIST National Vulnerability Database are the cleanest public starting points.

Because the issue is in network-facing router software, the operational question is not limited to patch status. Exposed management interfaces, internet-reachable embedded devices, and inherited firmware all widen the blast radius, especially where vendors repackaged the SDK into multiple products. In practice, exploitation in the wild usually means the attacker only needs remote reachability and a vulnerable build, not authenticated access or local foothold.

Why router SDK overflows become high-value targets

Router and gateway vulnerabilities are attractive because they sit at a trust boundary. If the device is exposed, an attacker can target the web interface directly; if it is internal, compromise can still matter because the device often mediates traffic, DNS, VPN, or administrative access. A buffer overflow in a web service is especially dangerous because it can move from denial-of-service into code execution depending on the implementation and surrounding protections, so even when the published description emphasizes DoS, defenders should treat the attack surface seriously.

The exploitation path is straightforward in most embedded cases: send a crafted HTTP request, trigger unsafe memory handling, and then use the device’s privileged network position for persistence or pivoting if the bug yields more than a crash. That is why KEV inclusion matters operationally, it indicates the issue has crossed from “patch eventually” into “assume hostile attention.”

For broader vulnerability triage and prioritisation of exploited issues, the Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV as an emergency response input, not a reporting artifact.

What defenders should do when patching is not immediate

Start by confirming whether the affected SDK is actually present in any router, modem, gateway, or OEM derivative you operate. Then isolate exposed management surfaces, restrict administrative access to trusted networks, and remove unnecessary internet exposure while you validate vendor remediation. If the device supports temporary hardening, use it, but do not assume a configuration workaround is equivalent to a fix.

If patching must wait, treat the device as an active-risk asset. That means monitoring for unusual HTTP requests, service instability, repeated crashes, or any configuration changes that would suggest post-exploitation activity. For router-class devices, the right fallback is usually containment and replacement planning, not extended exception handling.

When you need a broader prioritisation lens for remediation queues, FIRST EPSS can complement KEV by helping separate “known exploited” from “likely to be exploited soon” issues, but KEV should still win immediate attention here.

Risk and Threat Considerations

This kind of flaw creates both exposure and trust risk. A vulnerable router or embedded gateway can be crashed for denial-of-service, but it can also become a foothold in a network path that defenders often trust too much, especially when management ports or web consoles are reachable beyond an intended admin segment.

Failure mechanism: An attacker sends oversized form parameters to the boa web server, which performs unsafe copies and overflows memory. Depending on the build and protections in the specific product, the result can range from service disruption to deeper compromise.

Impact: The immediate impact is service instability or denial-of-service, but the broader consequence is loss of trust in a perimeter device that may sit on a critical access path. If the device is exploited, it can also become an entry point for lateral movement, traffic interception, or repeated abuse until it is rebuilt or replaced.

Practitioner Guidance

What to verify: Confirm the exact OEM firmware lineage, not just the brand name on the chassis. Embedded devices often inherit SDK components silently, so a clean bill of health from one model family does not prove another derivative is unaffected.

Decision rule: If the device is internet-facing or reachable from untrusted segments, treat it as higher priority than an internally isolated unit even before you confirm active abuse on your own network. KEV status already justifies emergency handling.

Practitioner takeaway: For router and embedded-device CVEs, “exploited in the wild” should drive containment and replacement planning as much as patching, because the real risk is often the device’s network position, not just the overflow itself.

Related resources from NHI Mgmt Group

• Guide: IoT Security Guide
• How do you patch or mitigate CVE-2021-35395 (Realtek AP-Router SDK Buffer Overflow)?
• CVE-2021-35395 (Realtek AP-Router SDK Buffer Overflow)
• Is CVE-2021-31755 (Tenda AC11 Router Stack Buffer Overflow) being exploited in the wild?
• Is CVE-2014-3931 (Multi-Router Looking Glass (MRLG) Buffer Overflow) being exploited in the wild?