Wavlink returns 3,502 fingerprint matches, 73 title matches, and zero hosts that carry both
CVE-2026-113802 was published on 20 October 2026 against Wavlink WL-WN530BE1-A firmware through M30BE1_V251117, an OS command injection in the ioos binary.
The sub_23B54 function passes the unsanitised file_id parameter of /protocol.csp?opt=ovpn_file requests with type=del to popen(). A remote unauthenticated attacker can send a forged IP-FROM: 127.0.0.1 header to bypass login and execute commands as root.
NVD scores it 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0. That combination, unauthenticated and root, makes the deployment count the question worth answering, and the data returns a conflict.
The measurement
Queries ran through the ZoomEye SDK on 27 October 2026 with sub_type=all and pagesize=1.
| Query | Role | Matched total |
|---|---|---|
app="Wavlink" |
vendor application fingerprint | 3,502 |
title="Wavlink" |
page title text | 73 |
app="Wavlink" && port=80 |
fingerprint on port 80 | 2,992 |
app="Wavlink" && port=443 |
fingerprint on HTTPS | 449 |
app="Wavlink" && service="http" |
fingerprint with HTTP service | 2,905 |
app="Wavlink" && title="Wavlink" |
fingerprint and title together | 0 |
No count identifies a WL-WN530BE1-A, and no scan field reports firmware version.
Zero is the finding
app="Wavlink" && title="Wavlink" returns 0 against a fingerprint population of 3,502. Not a small overlap, not a partial one. Zero.
Two explanations are available and both are plausible. The first is that Wavlink's administrative interface does not put the vendor name in the HTML title, so the two fields describe genuinely disjoint sets of pages: the fingerprinter recognises a banner or a header that a title query cannot see, and the title never contains the word.
The second is that the conjunction is measuring a field combination that the indexer does not produce for this class of device, in the same way that service="http" undercounts TLS listeners in other measurements in this series.
Whichever holds, the operational conclusion is the same. Title-based inventory of this product is useless, and the fingerprint is the only handle. A team that searched by title would find 73 hosts out of a population of at least 3,502.
Ports: 85 percent on plain HTTP
app="Wavlink" && port=80 returns 2,992, which is 85 percent of the fingerprint total. app="Wavlink" && port=443 returns 449, or 13 percent. app="Wavlink" && service="http" returns 2,905, almost exactly the port 80 figure.
For consumer networking equipment this is a coherent picture. The devices serve their management interface over plain HTTP on port 80, TLS is uncommon, and the service classification agrees with the port because the listener is unambiguously HTTP.
The figure that matters for the vulnerability is 2,992. An unauthenticated command injection on a device whose management interface is on port 80 is reachable by anyone who can route to that port, and the header-bypass in the advisory means the normal credential prompt does not stand in the way.
The header bypass is worth understanding on its own
The advisory describes a forged IP-FROM: 127.0.0.1 header as the way to bypass login. The application trusts a client-supplied header to decide whether a request came from the loopback interface, and treats loopback as authenticated.
The pattern is a trust inversion, where a value the client controls decides how the client is treated. Applications behind reverse proxies do something similar when they trust X-Forwarded-For, and the mitigation is the same.
The header must only be honoured when the request arrived from an address that is genuinely the proxy or the loopback interface, and the check must be on the socket's peer address rather than on a header. On a device where the web server is the same process as the application, there is no proxy and no legitimate reason for a client to supply that header at all. It should be stripped on ingress.
What an operator can do
There is no patch described in the advisory beyond the firmware version in the affected range. The device is consumer-grade, so the realistic controls are network-level: do not expose the management interface to the internet, and if remote access is a requirement, put it behind a VPN or an authenticating reverse proxy that strips inbound IP-FROM headers.
Check the firmware version on any Wavlink device in service and compare it with the range in the record. Then enumerate which of those devices answer on port 80 from outside the local network, since that is the set where the vulnerability is reachable without a further step.
References
- ZoomEye cyberspace search, queried 27 October 2026 with
sub_type=all - NVD record for CVE-2026-113802
- Wavlink WN530BE1 analysis referenced by the CVE
- VulnCheck advisory for the Wavlink command injection
Comments
No comments yet. Start the discussion.