Is CVE-2010-5330 (Ubiquiti AirOS Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2010-5330 to its Known Exploited Vulnerabilities catalogue on 15 April 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Certain Ubiquiti devices contain a command injection vulnerability via a GET request to stainfo.cgi. Any organisation running the affected product should treat remediation as urgent.

Why this CVE belongs on an active exploitation watchlist

CVE-2010-5330 is not just a historical weakness to file away. The practical question is whether exposure still exists in your fleet, because KEV listing means CISA has reliable evidence that attackers are using it. For internet-facing or remotely managed gear, the operational issue is less about theoretical severity and more about whether the vulnerable surface is still reachable today.

That changes the response posture. If the product is still in service, this is a priority remediation item rather than a backlog candidate. The right next step is to confirm whether any device still accepts the vulnerable request path and whether compensating controls such as segmentation, management-plane restriction, or upstream filtering are actually in place.

For device-facing security hygiene, the most relevant baseline is the IoT Security Guide, because edge appliances often fail in the same ways as other embedded systems: weak hardening, broad management exposure, and slow patch adoption.

What active exploitation means for exposure, not just patch status

“Exploited in the wild” means you should think beyond version checks. A device can be reachable through a management interface, exposed through NAT or VPN, or reachable only from an internal segment and still be relevant if the attacker has any path to issue the malicious request. The key question is whether the vulnerable command injection via the CGI endpoint can be triggered from any trust zone you expose.

That is why exploitation watchlists matter operationally. They help you distinguish between a defect that exists in code and a defect that is already being used against real systems. The most useful triage is to locate every instance of the affected product, verify how it is administered, and determine whether any administrative or management traffic can reach the vulnerable endpoint.

The strongest general reference for this triage is CISA’s Known Exploited Vulnerabilities Catalog, because it is the authoritative signal that an issue has crossed from theoretical to operationally abused.

How to respond when patching cannot happen immediately

When a device cannot be remediated at once, the goal is to make exploitation materially harder and easier to detect. Restrict administrative access to trusted management hosts, remove the device from direct internet exposure, and verify that any proxy, firewall, or ACL rules actually block the vulnerable request path rather than just the login page. If you have asset inventory gaps, close them first, because you cannot protect what you cannot find.

For actively exploited vulnerabilities, exploitability often persists because organisations treat patching as the only control. In practice, temporary risk reduction may need to include isolation of the management interface, device replacement planning, tighter monitoring of unusual CGI requests, and emergency change approval so that remediation does not wait for the normal maintenance window.

The most useful operational companion here is FIRST EPSS, which helps teams separate merely known flaws from those with a higher likelihood of exploitation, especially when they must prioritise across many pending issues.

Risk and Threat Considerations

Command injection on network or edge devices is attractive because it can turn a simple HTTP request into device-level control. If the appliance sits on a management plane, an attacker may use it for persistence, configuration tampering, traffic interception, or as a foothold into a broader internal network. The risk is amplified when the device is widely deployed, rarely monitored, or used as infrastructure rather than as a normal server.

Failure mechanism: A crafted request reaches the vulnerable CGI handler, the input is executed by the underlying system shell, and the attacker gains arbitrary command execution with the device’s privilege level.

Impact: The result can include configuration changes, credential theft, network pivoting, denial of service, or a durable foothold on a trusted edge device that defenders may overlook during routine server-focused monitoring.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid identification and remediation prioritisation.
	CIS-12 — Network Infrastructure Management	Edge appliances become risky when management interfaces are exposed or weakly segmented.
Recommendation — Prioritise KEV-listed flaws in your vulnerability workflow and verify remediation status fast. Restrict and segment management access to vulnerable network devices immediately.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV status and exposure checks require ongoing vulnerability identification and verification.
	SC-7 — Boundary Protection	Limiting reachability to the vulnerable endpoint is central when patching must wait.
Recommendation — Scan for the affected product and validate exposure before you accept remediation risk. Block untrusted paths to the management interface until the flaw is fixed.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	The answer depends on locating exposed instances and confirming which assets are affected.
	PR.AA-05 — Identity Management, Authentication and Access Control Are Used and Enforced	Administrative access restriction is a key compensating control for exposed device interfaces.
Recommendation — Inventory all AirOS assets and record which ones remain exposed to the vulnerable path. Limit administrative access paths to the device and enforce them consistently.

Practitioner Guidance

What to verify: Confirm whether any Ubiquiti AirOS systems remain deployed, whether they are internet exposed, and whether the vulnerable management surface is still reachable from any trusted network segment. Treat “behind a firewall” as insufficient unless you have verified the control path.

Decision rule: If the device cannot be patched immediately, isolate it, restrict administrative reachability to a small management set, and increase logging or packet inspection around its web interface until replacement or remediation is complete.

Practitioner takeaway: For KEV-listed edge-device flaws, the practical question is not whether the bug is old, it is whether an attacker can still reach it, because reachability determines whether the vulnerability remains a live incident path.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org