November 13, 2026 13 min to read

Barracuda ESG Root Chain: A Forged Backup Hands Over Your Email Gateway

Two chained bugs give unauthenticated attackers root on Barracuda Email Security Gateways, and attacks have started. Here is what to check today.

Your email security gateway sits in front of every message your company sends and receives. It holds mail routing rules, quarantined messages, LDAP bind credentials and, often, a privileged spot on the network. That is exactly why attackers love it, and why the Barracuda Email Security Gateway (ESG) is back in the headlines three years after the infamous 2023 campaign that forced customers to physically replace appliances.

This time it is a chain of two bugs, CVE-2026-116606 and CVE-2026-111560. Together they let an attacker who can reach the ESG’s web interface, with no username or password, upload a forged configuration backup and run commands as root. Barracuda shipped patches on 2 November, watchTowr Labs published a full technical analysis on 5 November, and on 9 November Barracuda confirmed it had seen “exploitation activity affecting a small number of organizations.” CISA added both flaws to its Known Exploited Vulnerabilities (KEV) catalog on 10 November with a due date of 13 November: today.

If you run a Barracuda ESG, or one of the five other products touched by the second bug, here is who is exposed, how to check, and what to do first.

TL;DR / Key takeaways

• What: CVE-2026-116606 (CVSS 4.0 score 9.3) is an authentication bypass in the ESG web UI that lets an unauthenticated request trigger a full configuration restore. CVE-2026-111560 (CVSS 4.0 score 8.6) is an OS command injection through the restored timezone value that runs as root. Chained, they give pre-auth remote root on the ESG.
• Who: Barracuda Email Security Gateway is exposed to the full unauthenticated chain. The command injection alone also affects Load Balancer ADC, Message Archiver, WAF, WAF Control Center and Web Security Gateway, where it needs an admin login.
• Status: Exploited in the wild (Barracuda, 9 November). Public technical analysis and a detection tool are available. CISA KEV since 10 November.
• Fix: Bring ESG to firmware 9.4.0.030 or later with patch BNSF-40425 (BNSF-40430 if you are below 9.4.017), and apply the listed patches on the other products. Check that auto-patching actually applied them.
• Then hunt: Patching does not remove an attacker who is already in. Look for configuration restores nobody scheduled, odd timezone values and unexpected outbound traffic from the appliance.

Timeline

Dates are from Barracuda’s advisory, watchTowr’s write-up and press coverage. Some sources disagree by a day, which we note.

• 15 and 22 October 2026: The two bugs are reported. Mandiant acts as the CVE Numbering Authority (CNA) for both records.
• 2 November 2026: Barracuda publishes its security advisory and releases patches for all affected products.
• 5 November 2026: Barracuda updates the advisory to state that “Authentication is not required to exploit this vulnerability.” The same day, watchTowr Labs publishes a detailed root-cause analysis and a “Detection Artefact Generator” on GitHub. (One outlet dates public code to 3 November; watchTowr’s own post is timestamped 5 November.)
• 8 November 2026: A detection template for the chain is merged into the public Nuclei template library, according to ThreatDefence.
• 9 November 2026 (evening, US Eastern): Barracuda updates the advisory: “We have identified exploitation activity affecting a small number of organizations.”
• 10 November 2026: CISA adds both CVEs to the KEV catalog, with a 13 November remediation deadline for US federal agencies.

How the chain works (conceptually)

No exploit details here, just enough to understand why this is so serious and what traces it leaves.

Bug 1: CVE-2026-116606, a login screen that does not stop

The ESG web interface handles many actions in one request. watchTowr found that when a password-change request fails, the vulnerable code sends back an error but does not actually end the request. It returns the “login screen” role and carries on processing the rest of the parameters in that same request.

One of the handlers further down the line is the upload for the Bayesian spam filter. That handler accepts an uploaded backup file and passes it straight to the appliance’s full configuration restore routine. In other words, a request that should have been rejected at the login stage ends up restoring an entire configuration supplied by the attacker.

Backups do have an integrity check, a hash over the file plus a secret value. According to watchTowr, that secret is hardcoded in the firmware, so an attacker can produce a backup the appliance will accept.

Barracuda’s patch makes a failed password change return a dedicated login response and stop, and it writes a new failed_password_change audit event.

Bug 2: CVE-2026-111560, a timezone that runs commands

During a restore, the appliance reapplies the saved system timezone. The vulnerable code inserts that value into a shell command (a sed call run via Perl backticks), and a helper script that does the same job is run through sudo. Single quotes around the value do not stop shell metacharacters, so a crafted “timezone” becomes a command that runs as root.

Barracuda’s fix replaces the shell calls with native file handling and rejects any timezone that does not exist under /usr/share/zoneinfo/.

Why the chain matters

On its own, bug 2 needs someone who can already restore a configuration, which normally means an administrator. Bug 1 removes that requirement on the ESG. The result is a single unauthenticated web request that rewrites the appliance’s configuration and executes code as root. On the other five products, only bug 2 applies, so an attacker needs valid admin credentials first. That still matters if passwords are weak, shared or reused.

Real-world exploitation

What we know, and what we do not:

• Confirmed: Barracuda says it has seen exploitation “affecting a small number of organizations.” CISA independently listed both CVEs as known exploited.
• Not published: Barracuda’s advisory, as of its 9 November update, has no indicators of compromise (IOCs), and no victim count or attribution has been released. CyberKendra noted that “Nothing public connects the new flaws to UNC4841 or any other actor”, the China-nexus group behind the 2023 ESG campaign.
• Tooling: watchTowr released a detection artefact generator, and a public Nuclei template exists. Some outlets describe the watchTowr tool as a proof-of-concept exploit; either way, defenders should assume the technique is now widely understood.

Details are still emerging; recheck the advisory for IOCs before closing any investigation.

Am I affected?

Products and versions

Patch IDs are from Barracuda’s advisory. Barracuda’s advisory itself just says to upgrade to the latest firmware; the 9.4.0.030 build number comes from the CVE record and most coverage, while watchTowr compared 9.4.0.027 (vulnerable) against 9.4.0.029 (patched). If in doubt, go to the newest build available and confirm the patch IDs are installed.

ThreatDefence, working from the CVE records, lists these as the last vulnerable versions for the command injection: ESG 9.4.0.027, Load Balancer ADC 6.4.0, WAF 11.0.1, Message Archiver 5.5.4.0, WAF Control Center 2.2.1 and Web Security Gateway 16.1.100.100.

Quick self-check

1. Find every appliance. Include physical and virtual units, lab boxes, and that old ESG someone never decommissioned.
2. Check firmware: in the ESG web UI go to ADVANCED > Firmware Update and read “Current Installed Version”.
3. Check patches: look in the firmware patches section. Barracuda says: “If a patch has not been automatically applied, customers should manually apply the appropriate patch as soon as possible.” Do not assume auto-patching is on; ThreatDefence reports that the documented default for applying patches is disabled, which would leave patches listed but not installed.
4. Check exposure: is the web admin interface (TCP 8000 by default) reachable from the internet? Test from outside your network, not from the office.

If an ESG was unpatched and its admin interface was internet-facing at any point since 5 November, treat it as potentially compromised until you have checked it.

Detection: did someone already get in?

There is no official IOC list yet, so focus on behaviour. These hunting ideas come from watchTowr’s analysis and ThreatDefence’s guidance.

What a successful attack leaves behind:

• A configuration restore or import that nobody on your team started, especially outside a change window.
• Configuration changes with no preceding admin login from a known IP.
• A system timezone value that is not a normal region name (for example, containing ;, |, $(, backticks or quotes).
• Unexpected outbound connections from the appliance, beyond mail delivery, DNS, NTP and Barracuda update servers.
• New or changed admin accounts, mail routing rules, or LDAP and relay settings.

On patched appliances, failed_password_change audit events show someone tried the bypass and were stopped. Treat a burst of them from an unknown IP as a strong signal that you were targeted, and check what happened before the patch went on.

If you forward the ESG web logs or your perimeter firewall/WAF/reverse-proxy logs to a SIEM, start with unauthenticated POST requests to /cgi-mod/index.cgi from addresses outside your admin range. Adapt field names to your schema.

Splunk (proxy or firewall logs):

index~|=|network (dest_port~|=|8000 OR uri_path~|=|"/cgi~|-|mod/index.cgi") http_method~|=|POST
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as paths by src_ip, dest_ip
| sort ~|-| count

Microsoft Sentinel / KQL (CommonSecurityLog from your firewall):

let esg_ips ~|=| dynamic(["203.0.113.10"]);   // replace with your ESG public IPs
let admin_ranges ~|=| dynamic(["10.0.0.0/8", "192.168.0.0/16"]);
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DestinationIP in (esg_ips) and DestinationPort ~|=|~|=| 8000
| where not(ipv4_is_in_any_range(SourceIP, admin_ranges))
| summarize Requests~|=|count(), FirstSeen~|=|min(TimeGenerated), LastSeen~|=|max(TimeGenerated) by SourceIP
| order by Requests desc

Outbound traffic from the appliance:

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where SourceIP in (esg_ips)
| where DestinationPort !in (25, 53, 123, 443, 587)
| summarize Connections~|=|count(), Ports~|=|make_set(DestinationPort) by DestinationIP
| order by Connections desc

Check any port 443 destinations against Barracuda’s update servers.

What to do: a prioritised checklist

Immediately (today)

1. Restrict the admin interface. Set the Administrator IP/Range under BASIC > Administration to trusted internal ranges, and block the web admin port at the perimeter. Barracuda notes that admin interfaces not reachable from the internet are much less exposed.
2. Patch ESG to 9.4.0.030 or later with BNSF-40425 (or BNSF-40430 below 9.4.017). If you are several versions behind, Barracuda says more than one update may be needed; contact Barracuda Support.
3. Patch the other products (Load Balancer ADC, WAF, Message Archiver, WCC, WSG) with the patch IDs above.
4. Verify, do not assume. Confirm the patch shows as installed, and turn on automatic patch application as Barracuda recommends.
5. Save evidence (config backup, logs) from any appliance that was exposed while unpatched.

This week

1. Hunt using the signals above, covering at least the period since 2 November.
2. Rotate credentials stored on or used by the appliance: admin passwords, LDAP/AD bind accounts, SMTP relay credentials and any API keys. This is especially important for the non-ESG products, where bug 2 needs a login.
3. Review mail flow: routing rules, allow lists, forwarding and quarantine settings, in case an attacker changed them to intercept or relay mail.
4. Send appliance logs to your SIEM (ESG supports syslog) so the next incident is visible.
5. If you find signs of compromise, isolate the appliance, engage Barracuda Support and an incident responder, and treat any credentials it held as stolen. In 2023 Barracuda told customers with compromised ESGs to replace them “regardless of patch version level”; the 2026 advisory does not say this, but rebuilding from a known-good state is the safer path for a box that ran attacker code as root.

Longer term

1. Keep management planes off the internet for every edge device: firewalls, VPNs, email gateways, load balancers.
2. Build an inventory of edge appliances with owners, firmware versions and patch status, and review it monthly.
3. Subscribe to vendor advisories and the CISA KEV feed, and set an internal SLA (for example, 72 hours) for KEV-listed edge devices.

What this means for Pakistan and South Asia

Barracuda ESGs and WAFs are common in banks, telecoms, universities, government bodies and mid-sized enterprises across the region, often installed years ago by a reseller and rarely touched since. If your organisation bought a Barracuda box through a partner, ask them today which version it runs and who has admin access, and get the answer in writing.

OffensioX perspective

This is the same story we keep seeing in 2026: the security appliance at the edge becomes the way in. Ivanti, SonicWall, Fortinet and now Barracuda again. Two patterns stand out. First, backup and restore paths are attack surface. They are trusted, rarely tested, and by design they rewrite everything on the device, so a hardcoded integrity secret turns a feature into a skeleton key. Second, the gap between a vendor patch and active exploitation keeps shrinking: here it was about a week, and only days after a public write-up. Organisations that still rely on quarterly patch cycles for edge devices are effectively accepting compromise. The fix is not exotic: get management interfaces off the internet, keep an accurate inventory, and treat KEV listings as emergencies.

If you are unsure what your perimeter exposes, OffensioX offers external attack-surface reviews, penetration testing and security assessments that cover email gateways and other edge appliances.

References

• Barracuda Trust Center: Pre-Authentication Authorization Bypass and Command Injection advisory
• watchTowr Labs: Barracuda Email Security Gateway pre-auth remote root RCE (CVE-2026-116606, CVE-2026-111560)
• SecurityOnline: CISA adds six exploited flaws in Outlook, Chrome, Barracuda, Cisco and Openwave to KEV
• SecurityOnline: Barracuda ESG vulnerability chain exploited in the wild after PoC release
• ThreatDefence: CVE-2026-116606 Barracuda ESG patching and threat hunting
• Cyber Kendra: CVE-2026-116606 Barracuda ESG bug chain gives root access
• GBHackers: Barracuda Email Security Gateway flaws allow unauthenticated attackers to execute commands as root
• The Back Room Tech: Barracuda Email Security Gateway flaws actively exploited for root access
• Born’s Tech and Windows World: Barracuda Email Security Gateways hacked in November 2026 (German)
• CISA Known Exploited Vulnerabilities Catalog