CISA lists two actively exploited Barracuda email gateway flaws
News
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-116606 and CVE-2026-111560 to its Known Exploited Vulnerabilities (KEV) catalog on November 10, 2026 UTC. Both flaws affect Barracuda Email Security Gateway (ESG) appliances, and CVE-2026-111560 affects five other Barracuda product lines. The November 10 catalog release was at 19:03 UTC, or 6:03 a.m. AEDT on November 11 in Sydney. See the CISA KEV catalog.
The government listing follows Barracuda's confirmation of exploitation activity affecting a small number of organizations. Gateway administrators should check whether each appliance has the correct patch, restrict the administrative interface to trusted networks, and involve incident response if they find exposure or unexplained changes. CISA lists November 13, 2026 as the due date for covered U.S. federal civilian agencies and requires forensic triage for both entries.
What changed on November 10
Barracuda first published its advisory on November 2. On November 5, it clarified that CVE-2026-116606 requires access to the administrative interface but does not require a login. That distinction matters when reviewing exposure. A login prompt on a reachable management interface is insufficient protection against a flaw that bypasses authorization before login.
Barracuda disclosed the observed exploitation in an update posted November 9 at 9:00 p.m. EST, which was November 10 at 02:00 UTC. Later on November 10 UTC, CISA listed both CVEs as known exploited vulnerabilities. The KEV entries mark the flaws for urgent remediation. Each operator still needs to determine which of its own appliances were exposed.
Federal due date and forensic triage
CISA's November 13 due date applies to covered U.S. federal civilian agencies. Both KEV entries require forensic triage under CISA's guidance as well as vendor-directed mitigation. Other operators should prioritize the fixes based on confirmed exploitation and their own exposure.
Which Barracuda products are affected
CVE-2026-116606 is a pre-authentication authorization bypass in ESG. CVE-2026-111560 is a command injection flaw that Barracuda describes as requiring administrative access when considered on its own. The vendor says the two flaws in combination can give an attacker full control of an affected gateway.
An email gateway's administrative controls govern how it accepts, filters and routes mail. The risk is that someone with control of the appliance can change how it handles messages. Barracuda's public update gives the scale of observed exploitation only as a small number of organizations and does not detail what happened to their mail.
|
|
|
|---|---|---|
Email Security Gateway (ESG) | Affected | Affected |
Load Balancer Application Delivery Controller | Outside scope | Affected |
Message Archiver (BMA) | Outside scope | Affected |
WAF Control Center (WCC) | Outside scope | Affected |
Web Application Firewall (WAF) | Outside scope | Affected |
Web Security Gateway (WSG) | Outside scope | Affected |
Product scope for the two CVEs. Check the vendor advisory for the appropriate patch and firmware.
The wider scope of CVE-2026-111560 matters if a different team manages your archivers, load balancers, or web security appliances. Send the second CVE to those owners so they can confirm the status of their own systems. The ESG patches apply to ESG firmware, so check the product-specific patch for every other affected line.
What gateway administrators should do now
Start with an inventory and an exposure check. Include every ESG instance, including standby nodes and appliances at remote sites. Record the running firmware and installed patch for each one. Check the actual firewall and remote access rules governing the administrative interface, including any exceptions that give it a path outside the trusted management network.
For ESG, Barracuda lists patch BNSF-40425 for firmware 9.4.017 and later, and BNSF-40430 for firmware earlier than 9.4.017. Check the running firmware and installed patch against the Barracuda security advisory.
Barracuda recommends current firmware and all applicable security patches. Older appliances might need more than one firmware update. If the appliance cannot take the recommended update or you cannot verify the installation, contact Barracuda Support to confirm the supported remediation path.
- Inventory appliances. Record each device's product, firmware and patch status, along with its owner and management network. Check each member of a redundant pair individually.
- Verify patch installation. Confirm that the appropriate patch is present even if automatic patching is enabled. If it did not apply, follow Barracuda's instructions to apply the correct patch manually and verify the result on the appliance.
- Restrict management access. Limit the administrative interface to trusted internal networks with network access controls. If administrators need remote access, use your approved management path. Preserve the separate network access required for normal mail delivery.
- Escalate suspicious findings. If the administrative interface was exposed or you find unexplained changes, contact incident response and coordinate evidence preservation with them. Record the exposure window and capture the relevant configuration and log history under your response procedures.
Use the running version and patch evidence to close each appliance's update task. If an appliance is offline or its patch status is unclear, leave that device open in the incident or change record and assign an owner to verify it before it returns to service.
When to involve incident response
If an affected appliance's administrative interface was reachable from an untrusted network, ask incident response to review the period of exposure, even if email delivery looked normal. Include the period before you restricted access or confirmed the patch. Current firewall rules show today's access, so use change history and retained records to establish what was reachable at the time.
Review administrative activity and configuration changes against approved work. Useful records include appliance audit logs, firewall and remote access logs, and any copies already retained outside the device. Compare current settings with a trusted baseline where one exists. An unexplained change to a privileged account, a mail route, or a filtering rule is a reason to investigate with the response team.
Coordinate any restart, reset, or recovery action with responders when evidence is at risk. Keep the timestamps for exposure, containment, and patch verification in the same record. If log retention leaves gaps, record those gaps so the team can judge what the review covers.
How to verify mail flow after recovery
Once the recovered gateway is ready for production traffic, send ordinary test messages through the inbound and outbound routes it is expected to handle. Confirm receipt at the destination, check the expected routing and filtering, and watch for deferred messages in the gateway queue. If a failover route carried mail during the response, verify that route too before closing out the recovery.
SPF checks whether the sending host is authorized for the envelope domain, DKIM verifies a message signature, and DMARC checks whether a passing SPF or DKIM domain corresponds to the visible From domain. These are sender authentication controls. They do not protect the gateway's administrative interface. A passing test message gives you evidence about that message. Patch verification and forensic triage require evidence from the appliance and the response review.
Check a delivered message
Send a message through the normal outbound route and inspect the receiving side's SPF, DKIM, and DMARC results with an email tester. Use a test sender that normally goes through the recovered gateway.
Check published DNS
If mail was rerouted or the sending setup changed during recovery, check the sending domain's published SPF, DKIM, and DMARC records with a domain health check.
Record when each message was sent, the route it used, and the result at the receiving end. If one route passes and another does not, compare the sending IPs and the domain used to sign each message before changing DNS. Keep the test results with the change record so the next shift can reproduce the normal mail-flow checks.
For a gateway that handles several outbound relays or DKIM signing configurations, test a representative sender on each path. Compare results with your normal baseline and repeat the checks after queued mail clears if delivery timing was affected during maintenance.
What to record before closing the response
Keep one record per appliance with the verified firmware and patch, the management access restriction and when it took effect, and the outcome of any incident response review. Add the inbound and outbound mail-flow checks once service is restored. Covered federal teams should also record the forensic triage required for both KEV entries and track remediation against the November 13 due date.
Frequency asked questions
Barracuda Email Security Gateway appliances are in scope for both CVEs. The other five product lines in the advisory are in scope for CVE-2026-111560. Check the firmware and patch requirements for each product you operate.
Check the installed patch on each device against the advisory. Automatic patching is a delivery setting. The running firmware and installed patch give you the evidence that the update reached the appliance.
CISA's November 13, 2026 due date applies to covered U.S. federal civilian agencies, and CISA requires forensic triage for both entries. Other organizations should use the known exploitation and their own exposure to prioritize remediation.
A DMARC pass confirms that the message met DMARC's requirements at the receiver. Return-to-service decisions also depend on the device's patch status, management access controls, and the outcome of any required incident response review.
