SURIQ
TP-Link has patched a flaw in its Omada Controller that turns a network administrator's single sign-on rights into a file-reading tool. CVE-2026-84941, disclosed on September 10, is an XML external entity (XXE) injection in the way Omada parses the identity-provider metadata you paste in when wiring up SAML single sign-on. An administrator who can reach that configuration screen can feed the parser crafted metadata and read files off the controller host. TP-Link scores it 6.9, a medium. On a box that runs your whole network, that score is doing a lot of quiet work.
If you run the self-hosted Omada Software Controller, or a hardware controller such as an OC200 or OC300, this is a patch-this-week item, and the fix is already out. What the medium rating hides is which files someone in the admin seat can pull. The rest of this covers what to update, who genuinely needs to move fast, and how to catch an attempt in your logs.
What to patch, and who actually needs to hurry
| Omada controller | Update to at least |
|---|---|
| Software Controller (Windows / Linux) | 6.2.14.11 |
| OC200 / OC220 | Build 20260711 |
| OC300 | 1.35.11 (Build 20260711) |
| OC400 | 1.13.11 (Build 20260711) |
| OC2000 | Build 20260711 |
Update the Omada Software Controller for Windows and Linux to 6.2.14.11. The hardware controllers, the OC200, OC220, OC300, OC400 and OC2000, are fixed in the firmware build dated 20260711, which surfaces as 1.35.11 on the OC300 and 1.13.11 on the OC400. TP-Link's advisory lists the per-model builds and points to the download center (Omada security advisory).
The flaw needs an authenticated account that holds SAML configuration rights, which in most deployments is a full administrator. That is why it sits at medium and not critical: a stranger on the internet cannot trigger it. The people who should still treat it as this-week work are the ones where "administrator" is not one trusted person. Managed service providers running a single controller across many clients, teams with delegated or junior admins, and anyone who has to assume an admin account could be phished or resold all fall in scope. In those settings a scoped admin quietly reading arbitrary files is a real escalation, not a theoretical one.
Why a file-read bug on a controller earns your morning
Local file read sounds tame until you look at what lives on a controller host. The SAML configuration itself holds the trust material for your single sign-on. The controller keeps its own configuration and operational state for the whole network it manages. An XXE that reads arbitrary paths can walk toward those files, and toward anything else the controller process can read on that host: certificates, config files, credentials left on disk. The scored impact is confidentiality only, no tampering and no downtime, but confidentiality on this particular machine is the part that stings.
How to spot an attempt
Here is the detail the advisory does not hand you. Legitimate SAML identity-provider metadata is a plain XML document, an EntityDescriptor, and it never declares a document type definition (DTD). So a DTD, a <!DOCTYPE or <!ENTITY block, sitting inside metadata that someone is importing into your single sign-on configuration is not a formatting quirk. It is the shape of an XXE attempt.
grep -iE '<!DOCTYPE|<!ENTITY|\bSYSTEM\b|file://' idp-metadata.xmlThat is a detection signature, not an exploit: a working payload also needs a target path and a channel to smuggle the data back out. The tokens above are the benign structural markers that should never appear in real identity-provider metadata, so a single hit is worth a look. Pair the scan with a review of whatever record your controller keeps of SAML configuration changes, and watch for a config edit that lands right before an unexpected outbound connection from the controller host.
The pattern: parsers that trust what you feed them
File-read flaws like this are a steady presence in what we triage. Path traversal and local file read is one of the six bug classes we log most across the last quarter. XML metadata parsers are a recurring source of them, because accepting an externally supplied document while leaving document-type processing switched on is an easy default to ship and an easy one to forget. The defensive lesson reaches past Omada: treat every place your software ingests third-party XML, SAML metadata, SOAP bodies, config imports, as an untrusted parser whose external-entity handling should be off by default. It is the same broad surface, SSO plumbing that has to parse XML an attacker can influence, that produced a SAML signature bypass in Keycloak earlier this year.
CVE-2026-84941 will not make headlines, and it should not. It is a medium bug that needs an admin to pull off. But it is a short patch that closes a quiet path from "admin who manages logins" to "reader of everything on the controller," and the detection above costs nothing to bolt on. Do both, and move on.