Barracuda's advisory said authentication required, then it did not

On 2 November Barracuda published an advisory covering two flaws in its appliances. Chained, they give an attacker root on an Email Security Gateway without logging in. watchTowr Labs demonstrated the chain.

Go to that advisory today and the first thing on the page, above the title, is this:

"Updated November 5, 2026, at 2:30pm EST: The Authentication Required field for CVE-2026-116606 has been changed from Yes, administrative access to No (Administrative UI Access Required). Authentication is not required to exploit this vulnerability; however, exploitation requires the administrative user interface (Admin UI) to be accessible to the attacker."

Three days after publication, the vendor corrected the single field that determines how urgently anybody reads the rest of the document.

Why that field decides everything

An administrator triaging advisories on 2 November saw a bug that needed administrative credentials. That goes in the queue. Credentialed attacks on an appliance are a real risk, but they are a second-order risk, and there are always more advisories than afternoons.

The same administrator reading the same page on 5 November saw a bug that needs no credentials at all. That is a different ticket with a different deadline.

Nothing about the vulnerability changed between those two readings. Only the description did.

And the correction is not quite a simple reversal, which is why it is worth quoting in full rather than summarising. Authentication is not required. Reach to the administrative interface is. Those are different conditions, and for an email security gateway the second one is often satisfied by the internet, because appliances of this kind are routinely deployed with management interfaces exposed to networks wider than their owners intend.

The second flaw, CVE-2026-111560, still reads "Yes (Administrative Access)" on the page. That is the command injection. Which is tidy, in a way nobody wanted: the bug that needs administrative access is reachable through the bug that no longer needs authentication.

What the two bugs actually are

CVE-2026-116606, CVSS 9.3, is an authorization bypass, and watchTowr's description of it is the sort of thing that makes you put your coffee down. When an unauthenticated attempt to change a password fails, the code writes an error response and keeps going. It returns the low-privilege login-screen role and carries on processing. The patch adds an early return.

A failure path that reports the failure and then does the work anyway is one of the oldest shapes in this business, and it is still shipping in security appliances in 2026.

CVE-2026-111560, CVSS 8.6, is a command injection. The restore path builds a shell command out of a timezone value using Perl backticks, and the script it ends up in runs through sudo, so the injection executes as root. Reaching it needs a crafted configuration backup, and the backup's integrity check is an MD5 over the file combined with a hardcoded string, which means anybody who knows the string can produce a valid checksum. watchTowr published the string.

An integrity check whose secret is a constant in the product is not an integrity check. It is a formality.

Three more things on the page

No fixed version. The advisory never names one. It says to upgrade to the latest firmware and gives patch identifiers: BNSF-40425 for 9.4.017 and later, BNSF-40430 for earlier. watchTowr tested 9.4.0.027 as vulnerable and 9.4.0.029 as fixed. If you want a version number to compare against your fleet, the vendor's own document will not give you one.

A severity that does not match. watchTowr reports that a comment inside the bypass patch's installer carries 9.8, against the 9.3 on the advisory. Their reading is that the installer comment scores both bugs together, which is not how the scoring system works. Either way, the number in the shipped artefact and the number on the public page disagree.

A patch identifier used twice. The advisory lists BNADC-16586 for the Load Balancer ADC and the same BNADC-16586 for the Web Application Firewall. That either means shared firmware or it means a mistake on the page, and the page does not say which.

CVE-2026-111560 is the wider of the two: it reaches the ADC, the Message Archiver, the WAF Control Center, the Web Application Firewall and the Web Security Gateway as well as the email gateway. The bypass is email gateway only.

The reason this gets written up at all

Barracuda says there is no active exploitation and no public proof-of-concept code exists. Both appear to be true today.

The reason to pay attention anyway is that these appliances have history. In 2023 a campaign against Email Security Gateways ended with Barracuda telling customers to physically replace hardware rather than patch it, because the intruders were resident below the patch line. That is context and not part of this chain, but it is why "no exploitation yet" reads differently on this product than it does on most.

Credit where it is due: the vendor found the error in its own advisory and corrected it in public with a timestamp, rather than editing it quietly. That is better behaviour than the quiet edit, and it is the only reason this article can be written.

What is not established

• Whether the amendment came before or after watchTowr published. The page timestamps the change but not the research, and we did not establish watchTowr's publication time.
• Who reported the bugs to Barracuda. The advisory does not say.
• Whether the repeated patch identifier for the WAF and the ADC is deliberate.
• Whether any appliances have been compromised. Barracuda says no exploitation has been observed, and absence of observation is not absence of exploitation on a device that holds mail.
• Which figure, 9.3 or 9.8, Barracuda considers correct. The advisory and the patch installer disagree and nobody has reconciled them.