CVE-2026-77543: Critical RCE in UniFi Access Application With Public PoC — Patch Now

TL;DR

CVE-2026-77543 is a critical improper input validation vulnerability in the UniFi Access Application that allows a low-privileged, network-reachable attacker to execute commands on the underlying host. The CVSS v3.1 base score is 9.9 (Critical), the vulnerability has a public proof-of-concept reference on GitHub, and it has been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. If you run UniFi Access in production, assume it is a target and prioritize remediation immediately.

• CVE: CVE-2026-77543
• Severity: Critical (CVSS 9.9, vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
• Type: Improper Input Validation leading to OS Command Injection (CWE-20 / CWE-78)
• Affected product: UniFi Access Application (vendor attribution incomplete in source feeds)
• Public PoC: Yes — GitHub reference observed
• CISA KEV: Yes — added 2026-08-26
• EPSS: 0.00804 (55th percentile) — low probability score, but KEV status overrides statistical scoring

What happened

On 2026-08-26, CVE-2026-77543 was published and simultaneously added to the CISA KEV catalog. The vulnerability affects the UniFi Access Application, a physical access control platform widely deployed in offices, campuses, and multi-tenant buildings. According to the official summary, a malicious actor with network access and low privileges can exploit an improper input validation flaw to perform command injection on the host device.

The source intelligence does not name the vendor explicitly, but the product family — UniFi Access — is clearly identified. Defenders should treat this as a Ubiquiti product until the vendor advisory confirms otherwise. The lack of complete vendor attribution in the feed is a data quality issue, not a reason to delay action.

The presence of a public proof-of-concept on GitHub significantly lowers the barrier to exploitation. Even if the PoC is incomplete or requires adaptation, it signals that the vulnerability is understood and that scanning and exploitation attempts are likely to increase. Combined with KEV status, this is a clear signal to move quickly.

Why this matters

Access control systems sit at the intersection of IT and physical security. A command injection flaw in UniFi Access is not just another web application bug — it can translate into unauthorized door access, denial of legitimate entry, or a foothold for lateral movement into the management network.

The CVSS vector tells a specific story:

• AV:N (Network): Exploitable remotely over the network.
• AC:L (Low complexity): No special conditions required.
• PR:L (Low privileges): The attacker needs a valid low-privileged account, not admin.
• UI:N (No user interaction): No victim needs to click anything.
• S:C (Scope Changed): The vulnerable component can affect resources beyond its own security authority — in this case, the host operating system.
• C:H/I:H/A:H: High impact on confidentiality, integrity, and availability.

That combination — network reachable, low privilege, no interaction, scope change — is why the score is 9.9. The prerequisite of a low-privileged account is meaningful, but in many environments, access control systems share a management VLAN with other infrastructure, and guest or contractor accounts may exist. That makes the barrier lower than it first appears.

Technical details

The root cause is improper input validation that allows attacker-controlled data to reach a command execution context on the host device. The application fails to sufficiently constrain or sanitize input before passing it to a system-level operation. This is consistent with CWE-20 (Improper Input Validation) and CWE-78 (OS Command Injection).

The affected version range is not specified in the source intelligence. Defenders must consult the vendor advisory to determine exactly which UniFi Access Application builds are impacted. Until that is confirmed, assume all versions are potentially vulnerable and apply the vendor-supplied fix as soon as it is available.

The trust boundary that is crossed is between the web/application layer and the host operating system. That is why the impact is rated high across all three security objectives. Once an attacker can execute commands on the host, they can read configuration data, credentials, and integration secrets; modify application behavior; and disrupt the availability of the access control service.

Exposure validation

Before you can prioritize remediation, you need to know where UniFi Access is running and who can reach it. Exposure validation is not just about internet-facing assets — it is about network reachability from any segment that untrusted or low-privileged users can access.

Ask these questions:

1. Where is UniFi Access deployed? Inventory all instances, including test, staging, and forgotten pilots.
2. Who can reach the management interface? Is it exposed to the internet, a guest VLAN, or a shared management network?
3. What accounts exist? Are there low-privileged accounts, service accounts, or dormant accounts that could be used as a foothold?
4. What integrations are configured? Does the application hold API tokens or credentials for other systems?
5. What is the blast radius? If the host is compromised, what else can the attacker reach from that network position?

If you cannot answer these questions quickly, that is itself a finding. Treat UniFi Access as a high-value asset and apply the same rigor you would to a domain controller or VPN concentrator.

Detection and hunting

Because a public PoC exists, detection should focus on both exploitation attempts and post-exploitation activity. The following indicators are worth hunting for:

• Unexpected child processes spawned by the UniFi Access service, such as /bin/sh, cmd.exe, powershell.exe, or curl/wget.
• Web or application log entries containing shell metacharacters (;, |, &&, backticks, $()) in parameters tied to input handling.
• Authentication events from low-privileged accounts at unusual hours or from unexpected network ranges.
• Outbound network connections from the UniFi Access host to IP addresses or domains not present in the approved integration baseline.
• New or modified files in application, temporary, or persistence directories on the host.
• Sudden changes to access control configuration, door schedules, or badge permissions that were not authorized.
• Gaps or anomalies in physical access logs that coincide with application restarts or service interruptions.
• EDR alerts for process injection, credential access, or lateral movement originating from the UniFi Access host.

If you find evidence of command execution, treat the host as compromised. Isolate it from the network, preserve logs and forensic evidence, and rebuild from a known-good image rather than attempting in-place cleanup.

Indicators of compromise

The following list consolidates the most actionable IOCs for CVE-2026-77543. Note that these are behavioral indicators — they may also appear in benign contexts, so correlate with other evidence before declaring a compromise.

• Child processes spawned by the UniFi Access service that should never run in that context.
• Shell metacharacters in application logs, especially near input-handling endpoints.
• Low-privileged account logins from unexpected source IPs or at unusual times.
• Outbound connections to unfamiliar destinations from the UniFi Access host.
• New or modified files in application, temporary, or startup locations.
• Unauthorized changes to door schedules, badge permissions, or access control configuration.
• Anomalies in physical access logs that coincide with service restarts.
• EDR alerts for process injection, credential access, or lateral movement from the host.

Mitigation and workarounds

Apply the vendor-supplied fix for CVE-2026-77543 as soon as it is available. Verify the installed build against the official advisory. Until patching is complete, take the following steps:

1. Restrict network access to the UniFi Access Application so that only trusted administrative networks and jump hosts can reach it.
2. Enforce least privilege on application accounts. Remove or disable unused accounts and rotate credentials and API tokens.
3. Segment the host on a dedicated management VLAN with strict egress filtering.
4. Monitor for the indicators listed above, with particular attention to child processes and outbound connections.
5. If compromised, isolate and rebuild. Do not attempt in-place cleanup.

Because this CVE is in CISA KEV, align remediation timelines with your organization's KEV policy. If immediate patching is not possible, document compensating controls and set a hard deadline for remediation.

What to do next

1. Confirm exposure. Determine whether UniFi Access is deployed and who can reach it.
2. Check for exploitation. Hunt for the indicators above, especially child processes and unusual outbound connections.
3. Patch or mitigate. Apply the vendor fix or implement the workarounds described above.
4. Rotate credentials. Assume any secrets stored on or accessible from the host may be compromised.
5. Review physical security impact. Check door schedules, badge permissions, and access logs for unauthorized changes.
6. Document and report. If you confirm exploitation, follow your incident response process and consider notifying relevant stakeholders, including physical security and compliance teams.

Community reactions

The CISA KEV addition on 2026-08-26 has driven urgent discussion among defenders. The primary focus is the fact that a low-privileged, network-reachable flaw in an access control product can have physical security implications. A public proof-of-concept reference on GitHub has been noted in the intelligence feed, which increases the likelihood of broader scanning and exploitation attempts.

Security media and community trackers have highlighted the Critical severity rating and the RCE tag, while noting that vendor and product attribution in the source feed is incomplete. The general consensus is that organizations should not wait for a mature exploit chain to appear before patching, given the KEV status and the sensitive nature of access control systems.

Some practitioners have pointed out that the EPSS score (0.00804, 55th percentile) is relatively low, but this is a statistical probability estimate, not a risk assessment. KEV status and the presence of a public PoC are stronger signals of real-world risk. Do not let a low EPSS score delay action.

Frequently asked questions

Is CVE-2026-77543 in CISA KEV?

Yes. It was added to the CISA Known Exploited Vulnerabilities catalog on 2026-08-26. That means CISA has evidence of active exploitation in the wild.

Is there a public proof-of-concept?

Yes. A public PoC reference has been observed on GitHub. Trusteed does not publish or link to weaponized exploit code, but defenders should assume that exploitation attempts will increase.

What is the CVSS score?

The CVSS v3.1 base score is 9.9 (Critical) with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

What is the EPSS score?

The EPSS score is 0.00804, which is the 55th percentile. This is a low probability estimate, but KEV status and the public PoC override statistical scoring for prioritization purposes.

Which versions are affected?

The affected version range is not specified in the source intelligence. Consult the vendor advisory for exact version information.

Who is the vendor?

Vendor attribution in the source feed is incomplete, but the affected product is identified as the UniFi Access Application. Treat this as a Ubiquiti product until the vendor advisory confirms otherwise.

What is the attack prerequisite?

The attacker needs network access to the application and a valid low-privileged account. No user interaction is required.

What is the impact?

Successful exploitation gives the attacker command execution on the host device. From there, they can read sensitive data, modify application behavior, disrupt access control services, and pivot into the broader network.

How do I mitigate if I cannot patch immediately?

Restrict network access to trusted administrative networks, enforce least privilege, segment the host, rotate credentials, and monitor for the indicators listed above. Document compensating controls and set a hard deadline for patching.

What should I do if I suspect compromise?

Isolate the host, preserve logs and forensic evidence, and rebuild from a known-good image. Do not attempt in-place cleanup. Follow your incident response process and notify relevant stakeholders.

Additional resources

• CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Public PoC reference on GitHub: https://github.com/HORKimhab/CVE-Ubiquiti
• NVD entry for CVE-2026-77543: https://nvd.nist.gov/vuln/detail/CVE-2026-77543
• CWE-20 Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
• CWE-78 OS Command Injection: https://cwe.mitre.org/data/definitions/78.html

Trusteed will update this post as vendor advisories and additional intelligence become available. For continuous exposure tracking, see the Trusteed vulnerability catalog.