When firewall rules are too late
Two crafted packets were enough to crash Ubiquiti's UniFi gateways before their firewall rules ever ran. Ubiquiti has confirmed 22 affected models and released fixes.
While assessing Ubiquiti’s UniFi gateways, we found four vulnerabilities that crash the device and force a reboot. Each one works against a factory-default configuration, and every model we tested was affected. Ubiquiti has since confirmed 22 affected models. What matters most is that the device’s own firewall rules offer no protection: one of the flaws can be exploited with just two crafted network packets, with no credentials and no user involvement.
We delayed publication until Ubiquiti had shipped fixes for every affected model. Those fixes are now available and documented in Security Advisory Bulletin 069. We are not publishing technical details of the individual vulnerabilities for now. These gateways are deployed widely, including in critical infrastructure, and the details could cause real harm in the hands of an attacker before operators have finished patching.
Configuration is not resilience
Product assessments are a regular part of our client work. We examine whether a product actually delivers the security function it is bought for, and whether it fits the client’s systems and network. The result is a concrete basis for choosing products, setting requirements and designing defences.
When we talk to clients and peers, the conversation often turns to network security boundaries. Network engineers ask whether VLAN segmentation can be broken, and we regularly encounter the belief that a correctly configured firewall is as trustworthy as a data diode. Both rest on the same false premise: that correct configuration guarantees secure separation. Configuration only tells the device what to do. It does not make the software correct.
In the VLAN case, the implicit assumption is that an attacker must first compromise the router or switch to breach the boundary. We ask a different question: can incoming traffic be used to attack the boundary itself? Which code parses the packets before separation is enforced, and can a bug in that code make the device misread packets or behave in unintended ways? The same logic applies to a firewall. A rule set can block every packet and still leave the software that processes those packets exposed, whereas a hardware data diode physically constrains the direction of traffic. The UniFi assessment was our way of demonstrating the gap between correct configuration and genuine resilience.
Two packets were enough
The most serious of the four, CVE-2026-77544, sits in the gateway’s Deep Packet Inspection (DPI) engine, the component that examines traffic to identify what it carries. A bug there allows a single byte to be written past the end of its buffer. This kind of off-by-one error corrupts adjacent memory, and once memory is corrupted the software no longer behaves as designed.
In our test, we sent two crafted packets to the device’s WAN address from outside the network. That alone crashed the gateway and forced a reboot. This was not a flood; the packets did not saturate anything. They simply hit a bug in the code responsible for processing them.
A firewall exists to block packets, but it has to process them first. That is where the flaws live. In the products we examined, packets reached the vulnerable code before the firewall rules had any say. In simplified form:
- 01 Packet arrives The packet reaches the router or firewall on the WAN port.
- 02 DPI processes the packet The memory corruption is exploitable at this stage.
- 03 Firewall rules evaluate the packet Rejection happens only here.
By the time the rules rejected the packet, the damage was done. The packet never had to be permitted by the rule set or reach anything behind the firewall. If an attacker’s packets could reach the vulnerable gateway at all, the flaw could be exploited, and no configuration change could prevent it. Only a firmware fix would do. A rejected packet, in other words, is not an unprocessed packet.
We tested the Dream Machine Pro, Dream Machine and UniFi Gateway Fiber on vulnerable firmware. All four flaws were exploitable on all three, in default configuration and before any firewall rule applied. In our correspondence, Ubiquiti confirmed the following 22 affected models:
- UDM
- UDM-Pro
- UDM-SE
- UDM-Pro-Max
- UDM-Beast
- UDR
- UDR7
- UDR5G
- UDW
- UCG-Ultra
- UCG-Max
- UCG-Fiber
- UCG-Industrial
- EFG
- EF-Core
- UniFi Express (UX)
- Express 7
- UXG-Lite
- UXG-Max
- UXG-Pro
- UXG-Fiber
- UXG-Enterprise
A crash is a security incident
For an organisation running critical operations, a firewall has two jobs: keep intruders out and stay up. A crash in a central piece of network equipment can sever communication, blind monitoring or halt operations outright. How bad it gets depends on the device’s role and on how well the surrounding system copes with losing it.
An attacker does not need to take control of a system to cause serious operational harm. Knocking a critical component offline can be enough.
Our objective was to document externally exploitable memory corruption that no device configuration could prevent. We did not pursue code execution, that is, running our own code on the device, so we cannot say whether any of the four flaws could be taken that far.
The test shows that a single security boundary is not always sufficient, even when it is a correctly configured firewall. This is the case for defence in depth: multiple layers of protection so that the failure of one is contained. Those layers must be genuinely independent, because several security functions hosted on the same device all fail together when it crashes. Critical operations therefore also need redundancy and rehearsed procedures for maintaining or restoring service during an outage. A second device carrying the same vulnerability is no defence against a shared software bug, and monitoring must be able to detect both outages and signs of compromise so the organisation can respond. None of this replaces security updates; it limits the damage and keeps operations running when something fails.
AI is reshaping the threat landscape. It can be used to analyse code and uncover previously unknown vulnerabilities; we use it in our own work and validate its output against the real systems. Our assessment is that AI substantially lowers the cost of examining and attacking complex products, which leaves Danish organisations and Danish-built solutions more exposed than before. Security can no longer rely on a product being too obscure, too local or too time-consuming to be worth examining.
Update affected equipment
Ubiquiti has assigned CVE-2026-77544, CVE-2026-77555, CVE-2026-77556 and CVE-2026-77558 to our four findings. If you operate affected UniFi equipment, check the firmware version and install the relevant security update. Version requirements and fixes are listed in Ubiquiti’s Security Advisory Bulletin 069. Our thanks to Ubiquiti’s security team for their cooperation in handling and fixing the reported issues.
There is more of this to come. We will publish further results from our product assessments as fixes and coordinated disclosures are completed. Through concrete findings and documented consequences, we want to show how much the threat to Danish organisations and Danish-built solutions has changed, and where defences need to be strengthened.
NULDAG is a Danish cybersecurity company founded by two specialists with backgrounds in offensive security. We help Danish organisations protect their critical systems through analysis of software, network equipment and system architecture. We are a specialised technical team, and we are growing: we are looking for colleagues who want to work in depth on software, network equipment and technical security analysis. Our ambition is to lead in Denmark, and rank among the best internationally, in applying AI to our field. See the open position (posted in Danish).