On 23 June 2026, CISA added four vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalogue and set a 26 June remediation date for US federal civilian agencies.
The striking part is not only the deadline. It is where the flaws live: not in a laptop or an application server, but in the equipment that manages the network and in a serial-to-IP converter that connects industrial devices to IP networks.
Three of the vulnerabilities affect UniFi OS, the Ubiquiti platform used to manage network controllers, gateways and devices across many offices, branch sites, SMEs, education environments and small data centres. The fourth affects the Lantronix EDS5000, a serial-to-IP converter used to expose legacy serial equipment to modern IP networks.
In both cases, the risk is uncomfortable: these are devices many organisations do not treat as critical servers, but they can hold a privileged position inside the network.
Before CISA added these flaws to KEV, several administrators had already reported suspicious super-admin accounts appearing in exposed UniFi consoles under the name “John Sim”. Those reports should be handled carefully: they are not official attribution and they are not a full forensic report. But they are consistent with automated exploitation patterns against vulnerable, exposed management consoles.
When the device that manages access to your network starts creating phantom administrators, the problem has stopped being theoretical.
This article explains what failed, how the UniFi OS vulnerabilities can be chained, why the Lantronix converter deserves the same attention, what signals to look for and what organisations running this class of equipment should do next.
Executive summary: what to review today
If you manage UniFi OS, Ubiquiti devices or Lantronix EDS5000 converters, the priorities are clear:
- Update UniFi OS according to Ubiquiti’s Security Advisory Bulletin 064. For UniFi OS Server, the fixed version is 5.0.8 or later.
- Update Lantronix EDS5000 to firmware 2.2.0.0R1 or later.
- Check whether management interfaces are exposed to the internet.
- Look for unknown administrator accounts, especially any “John Sim” style account or other unauthorised super-admins.
- Review configuration changes, backups, logs and administrative sessions.
- Segment the management plane and isolate devices that connect IT and OT networks.
- Forward logs to your SIEM or SOC, rather than leaving them only on the device.
- Treat any sign of exploitation as an incident, not merely as a patching task.
This is exactly the kind of case that attack surface management should cover: not only servers and endpoints, but also routers, gateways, controllers, network appliances, serial-to-IP converters and the devices that sustain connectivity.
Which vulnerabilities CISA added to KEV
CISA added four vulnerabilities to the KEV catalogue on 23 June 2026:
A KEV listing does not simply mean that a vulnerability is severe. It means CISA has evidence of exploitation in the wild. For that reason, a KEV-listed vulnerability should not be treated as “just another CVE”, but as an operational priority.
This is the same logic we explain in our analysis of KEV, EPSS and SSVC for prioritising exploitable vulnerabilities: priority should not depend on CVSS alone, but on real-world exploitation, exposure and asset criticality.
Anatomy: three UniFi OS flaws that, together, hand over the device
The three UniFi OS vulnerabilities added to KEV each carry a CVSS score of 10.0, the maximum possible. Individually, they are already serious. The deeper risk appears when they are chained.
CVE-2026-34908 is an improper access control vulnerability. It allows an attacker with network access to make unauthorised changes to a UniFi OS device.
CVE-2026-34909 is a path traversal vulnerability. It allows access to files on the underlying operating system, including files that may contain sensitive information or support further compromise.
CVE-2026-34910 is an improper input validation vulnerability that enables operating system command injection.
Bishop Fox’s technical analysis shows how these issues can be connected into a full exploitation chain. At a high level, the first two vulnerabilities allow attackers to bypass the authentication gateway by abusing differences between how a crafted path is evaluated before and after normalisation. In practice, a request can begin as if it were targeting an authentication-exempt path and then resolve to an internal route that should have required authentication.
From there, the input validation flaw allows command injection in functionality related to updates or package handling. The result is remote command execution with elevated privileges, without valid credentials, provided the vulnerable service is reachable over the network.
This does not need to become an exploitation guide. The defensive lesson is enough: if a vulnerable UniFi OS console is exposed to untrusted networks, an attacker may be able to move from an unauthenticated request to control of the platform.
And in many environments, that platform manages the network.
The “John Sim” signal: useful, but not definitive
One of the most widely discussed community indicators was the appearance of super-admin accounts named “John Sim” in UniFi consoles.
It is a practical signal worth checking, but it should not be overinterpreted.
What we know:
- Several administrators publicly reported the appearance of that account.
- The reports appeared around the publication and discussion of the Ubiquiti advisory.
- The pattern is consistent with automation against vulnerable and exposed consoles.
- Any unknown privileged account should be treated as a potential compromise.
What should not be claimed without further evidence:
- That every case belongs to the same actor.
- That “John Sim” is a universal indicator.
- That attackers will not use other account names.
- That the presence or absence of this name is enough to confirm or rule out exploitation.
The operational recommendation is simple: review every administrative account, not only “John Sim”. Any unauthorised super-admin is a critical signal.
The forgotten link: the Lantronix serial-to-IP converter
The fourth vulnerability, CVE-2025-67038, affects the Lantronix EDS5000 on vulnerable firmware. It is an operating system command injection issue in the HTTP RPC module.
The flaw exists because the device runs a shell command to log failed authentication attempts and concatenates the supplied username without proper sanitisation. That allows an attacker to inject arbitrary commands, executed with root privileges.
From the outside, this may look less attractive than a firewall or a network controller. In industrial and operational environments, however, serial-to-IP converters can be highly sensitive. They connect machinery, sensors, medical equipment, legacy systems or industrial devices to modern IP networks.
And they are often overlooked.
They may not appear in the main asset inventory. They do not run EDR agents. They are not always integrated into the SIEM. They may not follow the same vulnerability management cycle as servers and laptops. But they may be connecting critical equipment to the rest of the network.
That is why this case should also be read through an industrial OT security lens, not only as another vulnerability story.
What we know and what we do not
It is important to be clear about the evidence.
What we know:
- CISA added the four vulnerabilities to the KEV catalogue based on evidence of exploitation.
- The three UniFi OS vulnerabilities can be chained into unauthenticated compromise in specific scenarios.
- Ubiquiti published Security Advisory Bulletin 064 and fixed versions.
- Lantronix published updated firmware for EDS5000.
- The Lantronix flaw can lead to command execution with root privileges.
- Public reports describe unknown administrative accounts appearing in UniFi consoles.
What is not publicly certain:
- Which specific actors are exploiting each vulnerability.
- Whether all exploitation belongs to the same campaign.
- Whether “John Sim” accounts map to one attacker infrastructure.
- Whether the four vulnerabilities are being used in specific ransomware campaigns.
- How many organisations experienced confirmed compromise versus scanning, probing or reconnaissance.
That distinction matters. Good analysis does not need to fill gaps with speculation. What is confirmed is enough: exploitation has been observed, patches exist, edge and network management devices are affected, and the risk is real for enterprise and industrial environments.
Why usual controls do not see this
These devices share an uncomfortable trait: they are not simply “behind” the perimeter. In many cases, they are the perimeter.
A network controller manages access, configuration, gateways and policy. A serial-to-IP converter connects physical or industrial systems to a digital network. If an attacker compromises one of those devices, they do not need to climb over the wall. They have taken over one of the components that defines the wall.
There are three reasons traditional defence often falls short.
1. EDR does not reach them
An EDR agent normally does not run on a network gateway, a UniFi controller or a serial-to-IP converter. These devices sit outside the tool many organisations consider their first line of defence.
That is why the strategy cannot depend only on endpoint telemetry. It must include inventory, exposure, segmentation, logs, threat hunting and correlation in a managed SOC.
2. Credentials may never come into play
If a flaw allows authentication bypass or unauthenticated command execution, MFA and password policy help less than usual.
That does not mean MFA is irrelevant. It remains essential for legitimate administrative access. But it does not compensate for a vulnerable management interface exposed to untrusted networks.
The defence of these devices starts earlier: do not expose administration to the internet, segment access, patch quickly, restrict access and monitor activity.
3. You cannot patch what you never inventoried
A converter connecting a machine on the shop floor may have been running for years without appearing in the critical asset inventory.
That is the problem.
You cannot protect what you do not know. You cannot patch what has no owner. You cannot monitor what never sends logs. And you cannot respond well if the first time you discover the asset is during the incident.
This is where an infrastructure and network security audit and a vulnerability management programme must explicitly include network devices, gateways, controllers and industrial connectivity devices.
Detection: what to look for in UniFi OS
While patching and exposure reviews are underway, there are concrete signals worth checking.
The recommendation is not to stop at the device. UniFi logs should be centralised and included in security operations. If logs remain only on the compromised device, the attacker may be able to damage visibility.
Detection: what to look for in Lantronix EDS5000
For Lantronix EDS5000, hunting should focus on HTTP RPC activity, authentication attempts and signs of unexpected command execution.
In OT environments, detection must be careful. Not every industrial environment tolerates aggressive scanning. The strategy should combine passive inventory, configuration review, traffic analysis and controlled maintenance windows.
Defence: from urgent patching to surface reduction
The first step is obvious: update.
But patching closes these specific flaws. It does not solve the deeper pattern: critical network and OT devices sitting outside inventory, outside the SIEM and outside exposure management.
1. Update
For UniFi OS, apply the fixed versions indicated by Ubiquiti in Security Advisory Bulletin 064. For UniFi OS Server, upgrade to 5.0.8 or later.
For Lantronix EDS5000, upgrade to firmware 2.2.0.0R1 or later.
After updating, verify the version actually installed. Launching the update is not enough: confirm the device is no longer vulnerable.
2. Take management off the internet
Neither a UniFi console nor a serial-to-IP converter should expose its administrative interface directly to the internet.
If remote access is required, use:
- Corporate VPN.
- Administrative bastion.
- Dedicated management network.
- MFA.
- Session logging.
- Strict source rules.
- Periodic access review.
This is a basic systems hardening measure.
3. Segment
Network controllers and devices that touch OT should live in their own segments.
Network segmentation should prevent compromise of a management interface from becoming automatic lateral movement into users, servers, domain controllers, backups or industrial systems.
At minimum:
- Separate management network.
- Access only from authorised workstations or jump hosts.
- No administration from user networks.
- Explicit rules between IT and OT.
- Logging of north-south and east-west traffic.
- Review of exceptions.
4. Inventory the invisible
Network and OT devices should appear in the asset inventory with the same discipline as critical servers.
The inventory should include:
- Vendor.
- Model.
- Firmware.
- Owner.
- Location.
- Network segment.
- Internet exposure.
- Active interfaces.
- Business function.
- Dependencies.
- Criticality.
- Maintenance window.
- Update procedure.
A continuous threat exposure management model helps move from “we have devices” to “we know which devices are exposed, exploitable and business-critical”.
5. Integrate logs into the SOC
These devices cannot remain outside monitoring.
At minimum, send the SOC:
- Administrative access events.
- Configuration changes.
- User creation or modification.
- Backup export or download events.
- Reboots.
- Authentication errors.
- Firmware changes.
- Connections from external IPs.
- Interface or service events.
A managed SOC adds value when it can correlate a network event, a configuration change, a firewall alert and a KEV-listed vulnerability in the same context.
Response if you find signs of exploitation
If you find an unknown administrator account, altered configuration or signs of exploitation, do not treat it as “patch and move on”.
The response should include:
- Isolate or limit exposure of the affected device.
- Preserve current logs and configuration.
- Remove unauthorised accounts.
- Rotate administrative credentials.
- Revoke active sessions.
- Review backups and exported configurations.
- Confirm fixed firmware is installed.
- Hunt for lateral movement from the device.
- Review firewall, NAT and VPN rules.
- Document impact and timeline.
- Assess internal, contractual or regulatory notification needs.
If there is evidence of real compromise, the situation moves into incident response territory. In industrial environments, it may also require digital forensics with operational care to avoid disrupting production.
Compliance implications: NIS2 looks at this equipment too
For many European organisations, this type of vulnerability is not only a technical issue.
NIS2 requires organisations in scope to manage risk across network and information systems, apply appropriate technical and organisational measures, manage vulnerabilities, control access, monitor incidents and protect continuity.
A network gateway, a UniFi controller or a converter connecting a production line is not “plumbing”. It is an in-scope asset.
If the organisation operates industrial technology, the angle becomes stronger. Serial-to-IP converters are boundary assets between IT and OT, and they should be part of the industrial OT security strategy.
CISA’s KEV listing is also a useful reference when justifying prioritisation to management: these are not theoretical vulnerabilities. Exploitation has been observed.
If a relevant incident occurs, the organisation must be able to respond with evidence: which assets were affected, what versions they were running, what exposure existed, which logs are available, what changes were observed and what remediation was applied.
Without inventory, logs and response readiness, notification becomes blind reporting.
For organisations working across several frameworks, it is also worth reviewing the relationship between ENS, ISO 27001, NIS2 and DORA, because the same controls — inventory, exposure management, hardening, monitoring, patching and response — appear under different names.
The lesson: the perimeter has not disappeared, it has become harder to see
For years, we have repeated that the traditional perimeter has dissolved. That is true: cloud, SaaS, remote work, identity and third parties have changed how organisations defend themselves.
But cases like UniFi OS and Lantronix remind us of something uncomfortable: the perimeter has not disappeared. It still exists in controllers, gateways, firewalls, VPNs, converters, routers, cloud consoles and management tools.
The difference is that it is now distributed, exposed and often poorly inventoried.
The uncomfortable conclusion is not that UniFi or Lantronix are insecure. It is that too many organisations still treat network controllers, gateways and industrial converters as invisible infrastructure, when in reality they are exposed critical assets.
Attackers have known this for a long time.
The question is how long it takes the rest of us to look there.
Do you know which network and OT devices you have exposed?
Hard2bit helps organisations identify, prioritise and reduce real risk across network infrastructure, edge devices, OT environments and exposed assets.
We can support you with:
- Attack surface management
- Vulnerability management
- Infrastructure and network security audit
- Industrial OT security
- Managed SOC
- Threat hunting
- Incident response
- Systems hardening
- NIS2
If you want to review whether your network controllers, gateways, VPNs, industrial converters or exposed devices are properly inventoried, patched and monitored, contact the Hard2bit team through our contact page.
Recommended sources
- CISA: Four Known Exploited Vulnerabilities added to KEV
https://www.cisa.gov/news-events/alerts/2026/06/23/cisa-adds-four-known-exploited-vulnerabilities-catalog - CISA KEV Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog - Ubiquiti: Security Advisory Bulletin 064
https://community.ui.com/releases/Security-Advisory-Bulletin-064-064/84811c09-4cf4-42ab-bd61-cc994445963b - Bishop Fox: UniFi OS unauthenticated RCE chain and detection analysis
https://bishopfox.com/blog/popping-root-on-unifi-os-server-unauthenticated-rce-chain-detection-analysis - Bishop Fox: CVE-2026-34908 safe detector
https://github.com/BishopFox/CVE-2026-34908-check - Lantronix: CVE-2025-67038 EDS5000
https://www.lantronix.com/technical-support/security-updates/vulnerability-disclosure-policy/vulnerability-library/cve-2025-67038-eds-5000-eds-3000/ - INCIBE-CERT: CVE-2025-67038
https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-67038 - ShiftCTRL: “John Sim” UniFi super-admin reports
https://shiftctrl.net/articles/unifi-john-sim-super-admin-bulletin-064