Barracuda ESG Root Without a Password: The One Check to Run This Morning

November 8, 2026 · 11 min read

Barracuda ESG Root Without a Password: The One Check to Run This Morning

TL;DR - This week watchTowr Labs published a chain that takes a Barracuda Email Security Gateway from an unauthenticated HTTP request to a root shell: an authorisation bypass (CVE-2026-116606, CVSS 9.3) chained to an OS command injection (CVE-2026-111560, CVSS 8.6). Barracuda's advisory landed 2 November and was updated 5 November to sharpen one point: no login is required, but the attacker does need the administrative interface reachable. Proof-of-concept code is public, and the box in question terminates every inbound email your business receives. What you need to do: confirm whether your ESG (or any Barracuda appliance in the advisory) is internet-reachable at the admin interface, apply the vendor patches today, and if you cannot patch immediately, put the admin UI behind VPN or internal-only access until you can.


By The Numbers

ItemValue
CVEsCVE-2026-116606 (pre-auth authorisation bypass) and CVE-2026-111560 (OS command injection)
SeverityCVSS 9.3 and 8.6 per Barracuda's advisory; the patch installer itself says 9.8 for the bypass
Chained outcomeRoot access without logging in (Barracuda, watchTowr, The Hacker News)
Credentials requiredNone, but the admin UI must be reachable by the attacker (advisory updated 5 November)
Advisory published2 November 2026, updated 5 November 2026
Products affectedESG (both CVEs), plus Load Balancer ADC, Message Archiver, WAF Control Center, WAF, Web Security Gateway (command injection only)
Patched in watchTowr's diffESG 9.4.0.027 (vulnerable) to 9.4.0.029 (fixed); per-product patch files listed in the advisory
Exploit codePublic, published by watchTowr alongside the write-up

This week I sat down with watchTowr's latest write-up, which is not how I expect to start any morning, and by the end of it I had restarted the same conversation I have had with customers for years: who can reach the admin page of the box that handles your email?

The write-up is about a Barracuda Email Security Gateway, the email hygiene appliance that sits in front of a lot of small and mid-sized businesses here and in New Zealand. Two bugs, both published this week. Alone, one gets you a foot in the door. Chained, watchTowr shows them going from a single unauthenticated POST request to writing files to the appliance as root, with no account and no password involved at any point.

The patches exist. Barracuda shipped them with the 2 November advisory and updated the advisory on 5 November after some confusion in the field about what "pre-authentication" means for this one. So the patch story is the boring part. The interesting part is what the clarification tells you about your own estate, and it is one sentence long: authentication is not required to exploit this, but the administrative interface has to be reachable by the attacker.

Let me walk you through what happened, why it matters, and what to do about it today.

What watchTowr actually found

WatchTowr does patch diffing as a craft: take the fixed appliance firmware, take the version before it, and work out what changed. They compared Barracuda ESG 9.4.0.027 against 9.4.0.029 and reconstructed the attack from Barracuda's own fixes.

The first bug, CVE-2026-116606, is an authorisation bypass in the password-change path. When a password change fails, the pre-patch code returns the current session's role object instead of stopping the request. A failed request keeps running, as the low-privilege role of the login screen, and it keeps running into functions that were never meant to be reachable from an unauthenticated session. One of those functions restores a configuration backup. Barracuda's own patch installer describes the fix as stopping an "arbitrary Spam_Config restore", which is a very polite way of naming the problem.

The second bug, CVE-2026-111560, is a command injection in how the appliance handles timezone values during that same restore. The timezone string from the configuration ends up in a shell command executed as root. The patched code now validates the value against the system's zoneinfo directory before it goes near a shell.

Between them sits the backup file. Barracuda signs backups with a checksum, which should make forged backups impossible, except the secret used to compute it is embedded in the appliance's code. WatchTowr's published proof-of-concept builds a backup archive containing a MySQL dump with the attacker's command hidden in the timezone row, computes the checksum with the hardcoded secret, and uploads it unauthenticated to the configuration import endpoint. The appliance restores it, runs the timezone fix-up script, and the command executes as root.

That is the whole chain: a failed password change that doesn't stop, a restore function it can reach, a forgeable checksum, and a timezone field that meets a shell.

The 5 November clarification, and why it matters more than the CVSS score

Barracuda updated the advisory on 5 November to change the "Authentication Required" field for CVE-2026-116606 from "Yes, administrative access" to "No (Administrative UI Access Required)".

Read those two lines next to each other, because the difference defines your exposure. The first version implied you needed an account. The corrected version says you do not need an account, you need a network path. If the admin interface is reachable from the internet, an attacker has everything the exploit needs. If it is not reachable, you have a much smaller problem, and the vendor says as much: organisations whose administrative interfaces are not publicly accessible are less exposed, and they recommend restricting admin access to trusted internal networks.

So the practical question for anyone running this kit is not "what is my CVSS score". It is one line on a diagram: does the management interface of this appliance answer requests from the public internet, or only from inside?

Why an email gateway is the worst place for this

Email gateways are staple small-business kit in Australia and New Zealand, and they fail in an unglamorous way. The appliance is installed by a provider or a contractor, the admin page gets left reachable "so the MSP can manage it", firmware updates ride whenever someone schedules them, and the box quietly becomes the single most exposed thing on the network while doing a boring job well.

I have had that exact conversation about a remote management module on a customer site: login page loads from my kitchen, admin/admin gets me in, and the fix took ten seconds once someone owned the problem. The pattern repeats because the incentive structure repeats. Nothing about an email gateway complains when its admin page is open to the world.

This week's chain upgrades that exposure from "bad hygiene" to "one request from root". The box receives every inbound email for the domain. It holds credentials for mail flow and often directory integration. And it is the machine an attacker reaches before anyone has logged a single failed sign-in.

What watchTowr's write-up is, and what it is not

Some honesty about the source material, because overclaiming here helps nobody.

WatchTowr's post is a patch diff and a working proof-of-concept. It is not a report of the appliance being compromised in the wild, and neither their write-up nor Barracuda's advisory describes observed attacks. The CVE records were assigned through Mandiant, per The Hacker News's coverage. Public exploit code does change the clock though: the distance between "here is the mechanism" and "here is a scanner" has collapsed on every similar bug this year, and this one comes with ready-made tooling.

There is also a small scoring argument worth knowing before someone quotes it at you. Barracuda's advisory rates the bypass 9.3; the patch installer carries 9.8; watchTowr's reading is that the installer's number likely covers both vulnerabilities scored together. Treat 9.3 as the vendor's number and the argument as a distraction. The chain result, root without credentials, does not depend on which number wins.

Why this could be good

This is what usable coordinated disclosure looks like: vendor advisory with per-product patch files, a researcher write-up that explains the mechanism instead of just announcing it, public proof-of-concept for reproducing your own fix, and a vendor that updated its own advisory within days when the authentication field was wrong. If you run this kit, you are not guessing at any point in that chain. Compare that with the era when the first public word about an appliance bug was mass exploitation. Defenders got the mechanism, the fix and the field correction inside a week.

What to do today

  1. Find every Barracuda appliance on the estate. The advisory covers ESG for both CVEs, and the command injection also reaches Load Balancer ADC, Message Archiver, WAF Control Center, WAF and Web Security Gateway. If a provider manages them, that call is your first job this morning.
  2. Check admin UI reachability, from outside. Can the management interface answer a request from the internet? Test it the way an attacker would, from outside your own network, not from a LAN machine where everything looks private.
  3. Apply the patches. Barracuda's advisory lists the patch file per product and firmware line (BNSF-40425 and BNSF-40430 for the ESG depending on your version). WatchTowr's diff landed between 9.4.0.027 and 9.4.0.029, so if you are below that range you are in scope. Follow the advisory's firmware guidance rather than a version number quoted in a blog post, including theirs.
  4. If you cannot patch yet, cut the path. Restrict the admin interface to trusted internal networks or VPN-only until the patch is on. Barracuda's own mitigation advice starts there, and it works even before the firmware moves.
  5. While you are in there, check for signs. Configuration changes you did not make, unexpected timezone settings, new admin accounts. The chain's fingerprints are configuration-level, which is exactly what a restore leaves behind.
  6. Write down who owns this box. Not the MSP, not "the email people". One name, one number, because the next advisory about this appliance should reach a human in minutes rather than whenever the newsletter lands.

Key Takeaways

  • Two vulnerabilities, chained to root without logging in. CVE-2026-116606 (authorisation bypass, 9.3) plus CVE-2026-111560 (command injection, 8.6) on Barracuda ESG, published 2 November and updated 5 November.
  • "Pre-auth" here means no account, not no conditions. The 5 November advisory update is explicit: authentication is not required, but the administrative interface must be reachable by the attacker.
  • The mechanism is ordinary plumbing. A failed password change returns a role object instead of stopping the request, the request reaches a backup restore, the backup checksum uses a hardcoded secret, and a timezone value meets a shell as root.
  • Proof-of-concept code is public. WatchTowr published it with the write-up, which shortens the time between advisory and scanning.
  • Your morning check: is the admin UI reachable from the internet, are the patches applied per the advisory, and if not, is admin access VPN-only until they are.

FAQ

Is my Barracuda ESG affected? If it runs firmware below the versions in Barracuda's 2 November advisory, yes, and the ESG is the product affected by both CVEs. The command injection additionally reaches Load Balancer ADC, Message Archiver, WAF Control Center, WAF and Web Security Gateway. The advisory's per-product table is the source of truth.

Do I need to know if I was attacked? Not before you patch. The chain manipulates configuration through a restore, so afterwards it is worth looking for configuration changes, timezone values and admin accounts you did not create. The first move is closing the path, the second is checking what came through it.

Is the admin interface being on the internet really enough? That is what the advisory's 5 November update says: no authentication required, administrative UI access required. If your management interface answers requests from the internet, the exploit has everything it needs.

We use a managed service provider for email. Does that cover us? Only if the answer to "who patches this and who can reach its admin page" has a name attached to it. Ask them this morning, in writing, and ask them to confirm the firmware version on every appliance they manage for you.

What if we cannot patch today? Restrict the admin interface to trusted internal networks or VPN-only, which is the vendor's own mitigation advice. That closes the path the exploit needs while you schedule the firmware work.

How is this different from the usual email gateway CVE? The chain result. An unauthenticated request reaching root on the box that terminates your inbound email is the worst realistic outcome for this product category, and the fix is already out, which makes delay a choice.

My Take

The sentence that matters in this whole affair is the one Barracuda corrected on 5 November: no login required, admin interface must be reachable. Most of the exposure I have seen in fifteen years of looking at appliances sits in that gap between "the vendor assumed someone would restrict it" and "the installer left it open because the MSP needs access".

The industry likes to argue about CVSS scores while the actual variable is a network path. Nine point three or nine point eight changes nobody's Tuesday. Whether the management page of your email appliance answers the internet changes everything about your week.

Patch today. If you cannot, shut the path. Then write down who owns that box, because the next advisory is already being written, and it will land on the same desk this one did.


Mathew Clark Founder, SecureInSeconds Currently: checking which of the internet-facing appliances in my life still answer on an admin port Drafted with AI assistance - read, verified, and fixed by a human.


Further Reading

Share:
Buy me a coffee

You might also like