>
av.Amit VijayanCYBERSECURITY & RESEARCHLet\u2019s connect
Back to the library

Threat Hunting Playbooks

Hunting Barracuda ESG Exploitation: CVE-2026-116606 and CVE-2026-111560 Chain to Root in Splunk and CrowdStrike

AV
Amit Vijayan
14 min read
Thumbnail for: Hunting Barracuda ESG Exploitation: CVE-2026-116606 and CVE-2026-111560 Chain to Root in Splunk and CrowdStrike

Why this matters now

On November 10, 2026, CISA added two Barracuda flaws to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of November 13 — three days from the listing. The pair chains into unauthenticated root access on the Barracuda Email Security Gateway (ESG), the appliance that sits in front of an organization's mail and decides what gets through. Barracuda updated its advisory on the evening of November 9 to say it has identified exploitation activity affecting a small number of organizations. A public analysis and a working detection tool from watchTowr Labs have been available since November 5, so the window between disclosure and exploitation is already closed.

CVECVE-2026-116606 (pre-authentication authorization bypass) and CVE-2026-111560 (OS command injection)
CVSS9.3 Critical (Mandiant/Barracuda, CVSS 4.0) for CVE-2026-116606 — CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. NVD has not published its own score for either CVE yet (both records are still "Undergoing Analysis" as of November 11). watchTowr found a 9.8 rating in a comment inside Barracuda's patch; the researchers' best guess is that it scores both flaws together. This article leads with the vendor CNA's 9.3 and notes the difference. CVE-2026-111560 scores 8.6 High — CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
WeaknessCWE-288 — Authentication Bypass Using an Alternate Path or Channel (CVE-2026-116606); CWE-78 — Improper Neutralization of Special Elements used in an OS Command (CVE-2026-111560)
Affected productCVE-2026-116606: Barracuda Email Security Gateway (ESG) versions earlier than 9.4.0.030. CVE-2026-111560: ESG 9.4.0.27 and earlier, Load Balancer ADC 6.4.0 and earlier, Web Application Firewall 11.0.1 and earlier, Web Security Gateway 16.1.100.100 and earlier, Message Archiver 5.5.4.0 and earlier, WAF Control Center 2.2.1 and earlier.
VendorBarracuda Networks (Mandiant acted as CVE Numbering Authority)
DisclosureBarracuda advisory and Mandiant disclosures MNDT-2026-0041 and MNDT-2026-0042 published November 2, 2026; watchTowr Labs published the full chain analysis on November 5, 2026
CISA KEVBoth CVEs added November 10, 2026; federal remediation due November 13, 2026. Known ransomware use: Unknown.
Fixed inESG 9.4.0.030 or later — patches BNSF-40425 (firmware 9.4.017 and later) or BNSF-40430 (older firmware). Other products: latest firmware — BNADC-16586 (ADC and WAF), BNMA-32468 (Message Archiver), BNWF-60060 (WAF Control Center), BNYF-24789 (Web Security Gateway). Note the fixed-build disagreement: Mandiant's CVE record says the bypass affects ESG versions earlier than 9.4.0.030, while watchTowr compared vulnerable build 9.4.0.027 against patched build 9.4.0.029. Treat 9.4.0.030 as the target.
ExploitationConfirmed — Barracuda reported on November 9, 2026 that exploitation activity is affecting a small number of organizations; CISA's KEV listing on November 10 confirms active exploitation. No victim count beyond "a small number" has been published, and no actor has been named for this chain.

The ESG has been a target before, and that history is why this hunt is urgent rather than routine. In 2023, the group Mandiant tracks as UNC4841 exploited a different ESG flaw, CVE-2023-2868, as a zero-day, and Barracuda told affected customers to replace their appliances outright. Nothing public connects the new flaws to UNC4841 or any other actor — but the pattern is the same: an edge appliance that inspects every email, reachable from the internet, with a flaw that hands an attacker the keys to the device. The chain also needs no credentials and no user interaction. The only prerequisite is network access to the admin interface, which Barracuda says should never be internet-facing — yet the exploitation Barracuda confirmed means at least some appliances were reachable.

The deadline is what makes today the right day to hunt. CISA's November 13 due date binds federal agencies, but the KEV listing is the signal every other ESG operator should act on: if your appliance missed the November 2 patch, assume it was probed, and hunt for the restore and the timezone injection before you trust the gateway again. Patching alone is not a clean bill of health — a restore that already happened survives the patch, and so does anything the attacker planted with the configuration they rewrote.

The technique, in hunt terms

The chain has two halves, and each leaves different evidence. The first half, CVE-2026-116606, lives in the ESG's Index.pm request handler. When a password change fails, the handler builds a JSON error response — and then, instead of stopping the request, returns the current user role, which for an unauthenticated request is the low-privilege login-screen role. Processing continues into handlers that role can reach, including the bayesian_upload_handler, an upload routine named after the ESG's Bayesian spam filter. That handler accepts a pu_bayesian_upload parameter and a file, then passes the file to Barracuda::Backup2::restore_all, the appliance's full configuration-restore routine. A crafted backup archive therefore restores whatever configuration the attacker wrote into it. Barracuda backups carry an integrity check — an MD5 of the file bytes plus a secret — but watchTowr found the secret is hardcoded in the firmware, so an attacker who knows it can forge checksums the appliance accepts.

The second half, CVE-2026-111560, is the payload inside that backup. The archive's Spam_Config component loads a MySQL dump that restores the system_timezone setting. Two pieces of code then feed that value into a sed command run through Perl backticks: finalize_restore in Backup2.pm, and the fix_tz.pl script, which runs as root through sudo. The value was wrapped in single quotes, which do not stop shell metacharacters — a timezone string shaped like Region#';<attacker-command>;# closes the quote, starts a fresh command, and comments out the rest. watchTowr demonstrated the chain by writing a file to the appliance with exactly that shape. Barracuda's fix replaces both sed calls with Perl file reads and writes, and rejects any timezone that does not exist under /usr/share/zoneinfo/.

The whole chain is one unauthenticated multipart POST to /cgi-mod/index.cgi: a deliberately failed password change (mismatched new_password and retype_password fields, answered with HTTP 200 and a JSON failure body) plus the backup upload. That single request shape is what the hunts below are built around.

In MITRE ATT&CK terms, the chain maps to T1190 (Exploit Public-Facing Application) for the unauthenticated request against the admin interface, T1133 (External Remote Services) for the exposed admin interface itself, and T1059.004 (Unix Shell) for the root command execution through the timezone value. Two further mappings are hunting hypotheses, not documented behavior: T1098 (Account Manipulation), because a restored backup rewrites global configuration and could plausibly plant or alter admin accounts, and T1562.001 (Impair Defenses: Disable or Modify Tools), because the same restore could weaken filtering or logging. Treat hits on those two as leads to confirm in the appliance's own audit log, not as confirmed technique.

The shape will feel familiar if you ran the VeloCloud Orchestrator hunt: another management plane, another exploited flaw, another case where the patch does not evict an attacker who already got in. The difference here is the entry point — no login at all, not even a stolen read-only account — which is why Hunt 1 starts with the request itself rather than with identity. The same edge-appliance lesson from the Fortinet edge deep-dive applies: the appliance is the perimeter, so its own logs are the primary evidence, and the surrounding network telemetry is the corroboration.

A note on what is a hunting hypothesis and what is confirmed: the endpoint (/cgi-mod/index.cgi), the failed-password-change trigger, the pu_bayesian_upload parameter, the backup-restore routine, the system_timezone sink, and the sed-via-backticks mechanism are all documented by watchTowr's patch-diff analysis and Mandiant's disclosures. No public report gives the source addresses or the exact commands used in the confirmed exploitation, so the hunts look for the pattern — the request shape, the restore, the poisoned timezone — not a single tell-tale indicator, and the triage section tells you how to confirm a hit against the appliance itself.

Hunt 1: The upload — unauthenticated POSTs to /cgi-mod/index.cgi

The chain starts with a POST to the ESG admin interface's /cgi-mod/index.cgi carrying a failed password change and a backup upload. Legitimate admin traffic hits that endpoint too, so the signal is not the endpoint alone — it is the source. Admin traffic comes from known admin workstations, jump hosts, or VPN ranges. A POST from an address that has never authenticated to the admin interface, especially one outside your admin ranges, is the strongest single signal in this playbook. Run this over at least 30 days, back to mid-October: the bypass was reported on October 22, the public analysis landed November 5, and exploitation was confirmed November 9.

This Splunk search counts POSTs to the endpoint by source in your web or reverse-proxy logs. Replace index=web and sourcetype=access_combined with your own web-log index and sourcetype; the field names follow Splunk's Common Information Model for web access logs.

index=web sourcetype=access_combined earliest=-30d http_method=POST uri_path="/cgi-mod/index.cgi"
| stats count as posts, earliest(_time) as first_seen, latest(_time) as last_seen by clientip
| sort - posts

If your WAF or reverse proxy inspects request bodies, the upload itself has a marker the access log cannot show: the pu_bayesian_upload parameter. This second Splunk search finds it — but only where body inspection is on, which is uncommon, so treat a lack of results here as absence of logging, not absence of attack.

index=waf earliest=-30d "pu_bayesian_upload"
| table _time, src, dest, uri_path, status
| sort _time desc

On the CrowdStrike side, the ESG's syslog forwarded into Falcon LogScale carries the same story. This CQL query looks for the upload parameter in the ingested syslog; adjust the field names to how your ESG syslog parser lands the message text in LogScale.

message=/pu_bayesian_upload|bayesian_upload/
| table([@timestamp, host, src, user, message])
| sort(@timestamp, order=desc)

And this CQL query covers the surrounding hosts: Falcon-monitored admin workstations and servers talking to the ESG admin interface. Replace the placeholder address with your ESG's admin-interface IP; any host on the list that is not a known admin workstation deserves the same scrutiny as a hit in the web logs.

#event_simpleName=NetworkConnectIP4
| RemoteAddress="203.0.113.10"
| table([@timestamp, ComputerName, UserName, ImageFileName, RemoteAddress, RemotePort])
| sort(@timestamp, order=desc)

Hunt 2: The restore — configuration imports and poisoned timezones

If Hunt 1 fires, the next question is whether a restore actually happened. The patched code audits failed password changes, and the vulnerable code does too — so a failed_password_change audit event from the same source, followed minutes later by a configuration restore, is the chain in your own logs. This Splunk search pulls the failed password changes from the ESG's forwarded syslog; replace the index and sourcetype with your own.

index=barracuda sourcetype=barracuda:esg earliest=-30d "failed_password_change"
| stats count as failures, earliest(_time) as first_seen, latest(_time) as last_seen by src, user
| sort - failures

This Splunk search finds the restore itself — configuration import or backup restore events in the ESG audit trail. A restore with no matching change ticket, from an unusual source, or outside a maintenance window is the event to chase.

index=barracuda sourcetype=barracuda:esg earliest=-30d ("restore" OR "import") AND ("backup" OR "config")
| table _time, host, src, user, _raw
| sort _time desc

The injection itself is the timezone value. A legitimate timezone is a plain region name such as America/New_York — it never contains a semicolon, a backtick, a dollar sign, an ampersand, or a pipe. This Splunk search finds system_timezone values carrying shell metacharacters; any hit is a command that already ran, not an attempt to watch.

index=barracuda sourcetype=barracuda:esg earliest=-30d "system_timezone"
| search (";" OR "&&" OR "`" OR "$(" OR "||")
| table _time, host, src, user, _raw
| sort _time desc

The CrowdStrike equivalents, against the same LogScale-ingested ESG syslog:

message=/failed_password_change/
| table([@timestamp, host, src, user, message])
| sort(@timestamp, order=desc)
message=/system_timezone/
| message=/[;`$&|]/
| table([@timestamp, host, src, user, message])
| sort(@timestamp, order=desc)

Hunt 3: Post-exploitation — what a rooted appliance does next

A compromised ESG is a Linux host with root access sitting on the mail path, so hunt it like one. The appliance should only initiate outbound connections to a short list of destinations: update servers, DNS, NTP, and upstream mail hosts. Anything else — especially a first-seen external destination, or a connection on an unusual port — is the post-exploitation signal. This Splunk search lists outbound connections from your ESG appliances in firewall or proxy logs; replace the placeholder addresses with your appliances' real IPs, and baseline the destinations against the known-good list before calling anything a hit.

index=firewall earliest=-30d src_ip IN ("203.0.113.10", "203.0.113.11")
| stats count as connections, dc(dest_ip) as distinct_dests, values(dest_ip) as destinations by src_ip, dest_port
| sort - connections

The CrowdStrike equivalent, against firewall or proxy data ingested into LogScale:

src="203.0.113.10"
| table([@timestamp, src, dest, dest_port])
| sort(@timestamp, order=desc)

One more hunt, labelled a hypothesis: a restored backup rewrites the appliance's global configuration, so a planted admin account is a plausible persistence path — but no public report documents account creation in this chain. This Splunk search looks for admin account creation in the ESG audit trail; treat a hit as a lead to confirm against your change records, not as proof of compromise on its own.

index=barracuda sourcetype=barracuda:esg earliest=-30d ("user" AND ("created" OR "added"))
| table _time, host, src, user, _raw
| sort _time desc

There is no Microsoft Defender KQL set in this article, deliberately: the target is an appliance, not a Windows endpoint, so there is no Defender telemetry on it. The surrounding-host coverage is in the CrowdStrike queries above.

Triage: sorting real compromise from noise

First, confirm the hit in the appliance's own logs. A Hunt 1 hit (a POST to /cgi-mod/index.cgi from an unknown source) plus a Hunt 2 hit (a failed_password_change audit event and a restore from the same source within minutes) is a confirmed compromise, not a false positive to tune away. Pull the ESG audit log for the matching window and look for the restore, the timezone value that was set, and any configuration change that followed it.

Second, check the timezone value directly on the appliance. A system_timezone that is not a real region under /usr/share/zoneinfo/ is suspect by definition — the patched code refuses exactly that. Check the files the injection writes through: /home/product/code/config/tz and /etc/sysconfig/clock for injected commands, and /tmp for unexpected files (watchTowr's demonstration wrote a marker file there). A Nuclei detection template for the chain was proposed on November 6 and merged into the public template library on November 8, and watchTowr published a Detection Artefact Generator on GitHub — both can confirm exposure against appliances you own.

Third, separate the noise. Legitimate restores happen during maintenance or recovery, by a known administrator, inside a change window — check the ticket before you escalate. Legitimate timezone changes are plain region names with no metacharacters. What has no innocent explanation is a restore nobody started, a timezone value carrying shell characters, or an outbound connection from the appliance to a destination nobody can name.

Fourth, if the chain is confirmed, do not trust the version number alone. Even after patching to 9.4.0.030, review every admin account, every global configuration change, and every mail-flow rule from before the patch. If any account or rule cannot be explained, rotate it and treat the appliance as compromised until the review is clean — the same discipline the Ivanti edge hunt applies to a patched management plane.

Remediation and hardening

Patch the ESG to 9.4.0.030 or later — BNSF-40425 for firmware 9.4.017 and later, BNSF-40430 for older firmware — and apply the per-product patches for the other five affected products: BNADC-16586 for the Load Balancer ADC and the Web Application Firewall, BNMA-32468 for the Message Archiver, BNWF-60060 for the WAF Control Center, and BNYF-24789 for the Web Security Gateway. If automatic patching is off, turn it back on; Barracuda's advisory asks for that explicitly, and this chain is the reason. Where sources disagree on the fixed build — Mandiant says earlier than 9.4.0.030 is affected, watchTowr tested patched build 9.4.0.029 — target 9.4.0.030 and confirm with Barracuda Support if 9.4.0.029 is the newest build your appliance is offered.

Restrict the admin interface to trusted internal networks permanently, not just until the patch window closes: fill in the Administrator IP/Range field under BASIC > Administration, and block the web interface port — HTTP 8000 by default — at the perimeter. A management plane should never be reachable from general user networks, and this chain requires nothing more than reachability. Audit every admin account on the appliance, remove stale ones, and require phishing-resistant multi-factor authentication for admin access where the appliance supports it.

Finally, keep the ESG's syslog and admin audit log in your SIEM with standing alerts on the Hunt 1 and Hunt 2 patterns — POSTs to /cgi-mod/index.cgi from unknown sources, failed_password_change events, configuration restores, and timezone values with shell metacharacters — so the next exploited edge-appliance flaw is a detection, not a disclosure.

Sources

Keep exploring.

All articles