Is CVE-2020-24363 (TP-link TL-WA855RE Missing Authentication for Critical Function) being exploited in the wild?

What “being exploited in the wild” means for this CVE

For a CVE that has been added to CISA’s Known Exploited Vulnerabilities catalogue, the practical meaning is simple: there is credible evidence that attackers are already using it, not just testing it in labs. That moves the issue from theoretical exposure to active operational risk. For this TP-link device, the missing authentication flaw should be treated as an internet-facing compromise path until proven otherwise.

For owners, the first question is whether the device is present anywhere in the environment, including branch sites, home-office deployments, lab networks and “temporary” edge setups that tend to be forgotten. The second is whether the device is reachable from untrusted networks. Internet exposure, remote administration, and shared management paths raise the urgency because active exploitation usually targets the widest, easiest access path first.

Because CISA’s KEV catalogue is tied to known exploitation, the relevant operational decision is not whether the bug is interesting, but whether the affected asset can be found, isolated and remediated quickly. Readers should use the CISA Known Exploited Vulnerabilities Catalog as the authoritative exploitation signal and confirm product details in the vendor advisory before planning action.

Why missing authentication on an edge device is dangerous

A missing authentication for a critical function means the device may expose administrative or state-changing capability without properly verifying who is calling it. On consumer and small-office network equipment, that often translates into configuration changes, device takeover, traffic manipulation or use of the device as a pivot point into the local network. This is especially hazardous when the device sits at the edge of a trust boundary.

The main operational problem is that exploitation can be low-friction. Attackers do not need to defeat a password policy if the function is reachable without authentication in the first place. In practice, that can let them alter settings, disrupt availability, or use the device as a foothold for broader reconnaissance. If the device is embedded in a flat network, the blast radius can extend well beyond the router or extender itself.

For vulnerability verification and triage, a useful reference point is the NIST National Vulnerability Database, which centralises CVE records and is useful for cross-checking product naming and downstream references. The broader class of active-exploitation issues is also covered by the CVE Program, which is the canonical identifier source for the flaw itself.

What to do now if the device is in use

Start by identifying every deployed instance of the model and then confirm whether any management interface is exposed beyond the internal network. If the device is in production, prioritise removal from exposed networks, replacement, or the vendor’s recommended remediation path. When a flaw is on KEV, delay should be the exception, not the default.

If immediate patching or replacement is not possible, reduce exposure aggressively. Put the device behind restrictive network controls, remove any unnecessary remote administration, and limit who can reach its management interface. Then preserve logs, configuration snapshots and network telemetry so you can determine whether the device was accessed before remediation. On edge equipment, “patch later” often means “investigate compromise first.”

For prioritisation, a standard vulnerability workflow helps keep the response disciplined. The FIRST EPSS model can support exploit-likelihood triage, but a KEV listing should already place the issue near the top of the queue. For an operational playbook on confirmed exploitation, use the Zero-Day and Exploited Vulnerabilities Guide to structure emergency response, even when the issue is not a zero-day.

Risk and Threat Considerations

Devices with unauthenticated critical functions are attractive because they can be abused quickly, often with little noise and little need for valid credentials. If the device is externally reachable, attackers may use it for initial compromise, configuration tampering or as a pivot into a larger internal environment. In many cases, the real risk is not the device alone, but the trust boundary it protects.

Failure mechanism: The management or control function can be invoked without proper authentication, so an attacker who can reach it may change settings, disrupt service or establish a foothold without first defeating normal access controls.

Impact: Exposure can extend from a single device outage to network-wide compromise, depending on what the device can reach, what credentials it stores, and how flat the surrounding network is.

Practitioner Guidance

What to prioritise: Confirm exposure first, then isolate or retire the device before you spend time on low-value tuning. If the device is internet-facing or remotely administered, treat it as urgent and assume it has a materially higher chance of abuse.

What to verify: Check whether the device has been accessed unexpectedly, whether its configuration changed, and whether any adjacent systems saw new logins or unusual traffic after the vulnerable device appeared in the environment. On edge devices, compromise is often discovered indirectly.

Decision rule: If the device cannot be remediated quickly and safely, remove it from service or place it behind compensating network restrictions while you replace it. If you must keep it online, assume containment is only temporary and continue compromise assessment until the exposure window is closed.

Practitioner takeaway: For KEV-listed edge-device flaws, the key judgement is not “is exploitation possible?” but “how much of the surrounding environment becomes reachable if this box is taken over?”

Related resources from NHI Mgmt Group

• Guide: IoT Security Guide
• How do you patch or mitigate CVE-2020-24363 (TP-link TL-WA855RE Missing Authentication for Critical Function)?
• CVE-2020-24363 (TP-link TL-WA855RE Missing Authentication for Critical Function)
• Is CVE-2020-6207 (SAP Solution Manager Missing Authentication for Critical Function) being exploited in the wild?
• Is CVE-2025-32433 (Erlang Erlang/OTP SSH Server Missing Authentication for Critical Function) being exploited in the wild?