Researchers at watchTowr Labs published a technical breakdown this month of two flaws in Barracuda's Email Security Gateway (ESG) appliance that can be chained by an unauthenticated attacker to gain root-level access. The flaws are tracked as CVE-2026-116606 and CVE-2026-111560, and Barracuda has shipped a fix in version 9.4.0.029.
CVE-2026-116606 is a pre-authentication authorization bypass rated 9.3 critical by Barracuda, though watchTowr argues the combined chain scores closer to 9.8. CVE-2026-111560 is an OS command injection rated 8.6 high that affects the ESG, Load Balancer ADC, Message Archiver, WAF Control Center, Web Application Firewall, and Web Security Gateway product lines. Both are fixed by the same 9.4.0.029 release, so admins who have not patched yet are exposed on two fronts at once.
ESG appliances sit at the mail edge for thousands of organizations, inspecting every message for spam and malware before it reaches a user's inbox. A pre-authentication path to root on that device gives an attacker a position inside the perimeter before any login screen appears. Barracuda has been here before, when UNC4841 exploited CVE-2023-2868 as a zero-day in 2023 and forced physical appliance replacements. The new chain shows that the same class of edge-appliance risk has not gone away, and that is why this story matters right now.
How the bypass works
The first flaw lives in Index.pm, the module that handles password-change attempts on the appliance's web interface. In the vulnerable code, a failed password change returns the session's role object, which for an unauthenticated request is the low-privilege login-screen role. Returning that object does not stop execution. The request keeps moving through the response handler, and the attacker effectively holds a valid session role without ever supplying correct credentials.
watchTowr's analysis shows the vulnerable path clearly. When new_password and retype_password are supplied but do not match, the code sets a JSON authentication response indicating failure, audits the attempt, and then returns $userrole instead of a hard stop. The patched version replaces that return with a bailout call that ends the request. Barracuda's own patch comment spells out the reason: returning a userrole would let response() run module handlers.
That single missing stop is what makes the second flaw reachable. On its own, the command injection in Backup2.pm would require an authenticated session with enough privilege to set the system_timezone value. Chained behind the bypass, the same injection becomes a pre-authentication remote code execution. The attacker never needs a password.
The mechanism is worth stating precisely because it is easy to miss in review. The password-change code runs inside _process_params, which is called by response(). When the change succeeds, the code calls bailout() and stops. When it fails with ERROR_PASSWD_CHANGE, it returns $userrole and lets response() continue. An unauthenticated visitor therefore gets past the gate by failing a password change on purpose, then feeds a backup bundle into the restore path that the same request is now authorized to reach.
The command injection and the hardcoded checksum
The second flaw is a textbook shell injection hiding behind a Perl backtick. In Backup2.pm, the appliance runs a sed command to rewrite the timezone line in a config file, interpolating system_timezone directly into the shell string. Single quotes in the source look protective, but they are just characters in the generated command, not a safety boundary. A value shaped like Region#';<attacker-command>;# closes the intended sed expression and runs whatever follows.
Barracuda's patch replaces the backtick call with a Perl-native file rewrite that validates system_timezone against /usr/share/zoneinfo/ before use. That is the correct fix, and it is the kind of change that should have been there from the start.
The injection is triggered through the backup restore path, which is the clever part of the chain. watchTowr found that a crafted backup bundle can carry a SQL payload that sets system_timezone to the injected value. Each file in the backup is checksummed, and the restore rejects mismatches, but the checksum is md5(file_bytes + secret + ".") with a hardcoded secret: "Barracuda Networks is your new best friend." Anyone who reads the binary can compute a valid checksum, so the integrity check adds no real protection.
The full exploit request is a single multipart POST to /cgi-mod/index.cgi carrying the mismatched passwords, the activation code, the bayesian upload flag, and the malicious backup file. watchTowr published a proof-of-concept and a detection artifact generator so defenders can test their own appliances.
The watchTowr team noted that Barracuda released several patch files to address both CVEs, and they reviewed two specifically, referred to as Patch-1 for the authorization bypass and Patch-2 for the command injection. In the bypass patch, the installer's own comments describe the issue plainly: a pre-authentication authorization bypass permits arbitrary Spam_Config restore. The CVSS score in that comment reads 9.8 critical, versus 9.3 in Barracuda's public advisory, which watchTowr attributes to the two flaws being scored together rather than anything untoward.
What defenders should do now
Patch to 9.4.0.029 or later, and treat that as urgent rather than routine. The chain is unauthenticated, the endpoint is the appliance's normal web interface, and the payoff is root. There is no compensating control short of taking the device off the network, which defeats its purpose.
Admins should also review backup restore logs and any unexpected configuration changes on ESG devices. watchTowr's detection artifact generator can help determine exposure. If an appliance cannot be patched immediately, restrict management access to a trusted network and monitor for POST requests to /cgi-mod/index.cgi carrying backup uploads from unexpected sources.
For organizations running Barracuda appliances, the practical takeaway is simple. Treat this like the 2023 incident in terms of urgency, not in terms of outcome. There is no indication yet of mass exploitation, but the proof-of-concept is public, the endpoint is unauthenticated, and the payload is a single HTTP request. Patch first, then hunt.
It is not clear this will be the last appliance-class RCE we see this year. The pattern is familiar: a web-facing management interface, a Perl or shell boundary, and a hardcoded secret dressed up as integrity. Barracuda fixed both flaws correctly this time, but the underlying design habits that produced them are the part worth watching.
For more detail, see the watchTowr Labs analysis.
More cybersecurity coverage is available on this site.