Threat Analysis: Ubiquiti Max-Severity Flaws, Gitea Actively Exploited, and the Trusted Infrastructure Problem
Hello, Mauven here.
This is your Daily Threat Analysis for 26th August 2026.
Two items today. Both involve infrastructure that sits in a particular blind spot for UK SMBs: the hardware and services that are assumed to be sorted, managed, trusted, and therefore not checked.
Item One: Ubiquiti UniFi, Three Maximum-Severity Vulnerabilities, Patch Now
Ubiquiti has released firmware patches for three vulnerabilities rated at the maximum possible severity score. All three can be exploited remotely without any authentication. No login. No prior access. An attacker with network visibility can attempt exploitation directly.
The affected products are in the UniFi ecosystem, specifically the UniFi Network Application and UniFi Protect. If you do not recognise those names, check with whoever manages your office network. UniFi kit is used extensively across UK small and medium businesses, often precisely because it is affordable, reliable, and relatively easy to manage. That is not a criticism. It is context for why the exposure is significant.
The three flaws cover authentication bypass and command injection. The combination is unpleasant: bypass the authentication, then inject commands. That is not a theoretical attack chain; it is a straightforward one.
What the vendor advisory says: patch to the latest firmware versions immediately.
What it does not say: how many UniFi installations in the UK are managed by IT providers operating quarterly update cycles, or by business owners who handle their own router dashboard and have not logged into it since 2024. The answer, based on what I have seen across audits of businesses this size, is more than anyone would find comfortable.
What you need to do:
- Log into your UniFi controller and check the current firmware version on your access points, switches, and cameras
- If you use a managed IT provider, contact them today and ask specifically whether your UniFi firmware has been updated in response to this disclosure
- If UniFi Protect is running on a system with any public-facing exposure, treat this as urgent, not next-maintenance-window urgent, but today urgent
- If you do not know what UniFi products you are running, that is the first problem to solve
Item Two: Gitea RCE, CISA Confirms Active Exploitation
CISA has added a critical-severity code injection vulnerability in Gitea to its Known Exploited Vulnerabilities catalogue. That is the list of flaws confirmed to be actively exploited in the wild, not theoretical risks or proof-of-concept only. When something lands on that list, the window for deliberate consideration is closed.
Gitea is a self-hosted Git service, a platform for storing and managing code that runs on your own server rather than on GitHub or GitLab’s cloud infrastructure. It is popular with smaller software development firms, internal development teams at professional services businesses, and managed service providers who want to keep client code on infrastructure they control.
That instinct, keep the code on your own server rather than a third-party platform, is a sound one. The problem is that self-hosted means self-patched. And self-patched, in many environments, means patches applied when someone remembers, or when something breaks, rather than when a flaw is confirmed actively exploited.
The observed exploitation so far has involved cryptominer deployment. That sounds relatively benign compared to ransomware, but consider what it means operationally: the attackers have achieved remote code execution on your server. They chose to deploy a cryptominer. They could have chosen anything else.
The vulnerability is a code injection flaw. An attacker who can reach the Gitea instance can inject and execute arbitrary code. If that server holds client code, credentials stored in repository configuration, API keys, or deployment pipelines, the blast radius extends well beyond the Gitea installation itself.
What you need to do:
- If Gitea is in your environment, patch to version 1.23.1 or later immediately
- Audit what is stored in your Gitea repositories, credentials, API keys, and deployment scripts are common findings in repositories that were set up quickly and never reviewed
- Check access logs for any unusual activity, particularly from external IP addresses, going back at least 30 days
- If Gitea is managed by your MSP as part of a development pipeline, ask them today to confirm patch status and confirm whether any indicators of compromise have been observed
The Pattern Worth Naming
These two items share a characteristic that shows up repeatedly in post-incident analysis of UK SMB breaches: the compromised system was trusted infrastructure.
UniFi is not the public-facing web server. Gitea is not the customer database. They are the internal network layer and the development environment, systems that exist to support operations and are therefore assumed to be lower risk because they are not directly customer-facing.
That assumption is wrong, and it is worth being direct about why. Attackers understand network topology. When they get access to a UniFi controller, they get visibility into the entire network architecture. When they get code execution on a Gitea server, they get access to whatever that server touches, and development pipelines typically touch quite a lot.
The NCSC’s guidance on vulnerability management has addressed this for years. The fact that infrastructure sitting one layer behind the public-facing perimeter is still being treated as lower priority tells you something about how organisations are actually applying that guidance.
One other item worth flagging today, though it sits in a different category: a ClickFix phishing campaign has been identified distributing fake Cloudflare CAPTCHA pages through 24 malicious npm packages, using legitimate mirror infrastructure, unpkg, yarn, npmmirror, as free hosting for phishing content. This is not new technique, but the scale of package count and the use of trusted mirrors to bypass reputation-based filtering is notable. If your development team installs npm packages, a reminder to verify packages by name spelling and publisher before installation is not wasted.
Sources
Before tomorrow’s briefing: if Threat Analysis is useful to you, follow the show wherever you listen so it lands automatically, and if you know someone running a UniFi network or a self-hosted Gitea instance who has not seen this yet, pass it to them. Today is the day for that conversation, not next week.