In 2023 patching the appliance was enough; the 2026 entry asks you to know how to switch it off

On 10 November CISA added two flaws in Barracuda appliances to its known exploited vulnerabilities catalog and set the deadline for the 13th. Three days. The vendor's patch had been available since 2 November. What caught our attention is not the deadline: it is what that entry demands compared with what the entry for the same appliance demanded in 2023. Back then it asked for one sentence. Now it asks for a list, and the last line of that list contemplates discontinuing use of the product if no mitigation is available.

The chain, in the catalog entry's own words

There are two CVEs and you need both. The first, CVE-2026-116606, affects only the Email Security Gateway, the box that filters mail. The catalog description calls it an authentication bypass "using an alternate path or channel" that lets an unauthenticated remote attacker "invoke a configuration-import function and restore a crafted, compatible backup archive", resulting in unauthorized modification of "the appliance's global configuration". The second, CVE-2026-111560, is an OS command injection that allows "an authenticated administrator" to run commands with root privileges "when the crafted timezone value is subsequently processed".

Chained, the first one puts you inside as an administrator and the second one gives you root. Barracuda's advisory, published on 2 November and updated on the 5th and the 9th, says it plainly: "If exploited in combination, these vulnerabilities could allow an attacker to bypass authorization controls and obtain root access to the device." Scores from that same advisory: 9.3 and 8.6. The gateway patch is BNSF-40425 for 9.4.017 and later, and BNSF-40430 below that version. The other five products on the list —Load Balancer ADC, Message Archiver, WAF Control Center, Web Application Firewall and Web Security Gateway— are only affected by the second CVE.

Our reading of the chain, which is opinion and not quotation: the interesting part is where the two doors are. The first is not a flaw in the login form; it is a function that accepts a file, and the file acting as the key is a configuration backup — that is, an artifact of the recovery procedure. The second runs code from a timezone field. If you sit down tomorrow to audit a mail gateway, neither of those places is on your list. Nobody's list has the timezone dropdown on it.

The same appliance, 1,264 days earlier

This gateway had been in the catalog before. On 26 May 2023 CVE-2023-2868 was added: improper validation of a user-supplied .tar file, leading to remote command injection. A file you upload to the appliance ending up as code. The same shape as now, with a different file format and three and a half years in between. We put the two entries side by side, and what changed is not the appliance.

There are 1,264 days between the two entries. In that time the regulator stopped assuming that patching solves the problem. It now also asks you to check whether someone got in, to know what you have exposed to the internet, and to have a plan in case the vendor does not make it in time. That last one is no longer answered by patching: it is answered in the design.

Where the three days come from

Nobody picked them by hand. On 10 June 2026 CISA issued directive BOD 26-04, "Prioritizing Security Updates Based on Risk", replacing CVSS-derived deadlines with a four-variable model. The four, quoted from the directive: asset exposure ("Is the vulnerable asset publicly exposed?"), KEV status ("Is the vulnerability... on CISA's Known Exploited Vulnerabilities Catalog?"), exploit automation ("Is an adversary able to automate all the steps necessary to exploit the vulnerability?") and technical impact ("Does an adversary gain partial control or total control of the vulnerable asset after exploitation of the vulnerability?"). Out of that come the windows: three days with forensic triage, three days, fourteen, sixty, or defer to the next system upgrade.

Put another way — and this is the part we find usable by anyone who is not a federal agency: the deadline has stopped being only a property of the CVE. Three of the four variables describe the flaw and come to you as given. The first one does not: asset exposure is decided by you, the day you install the appliance and every time someone opens a port "just for a minute". It is the only one of the four you can move without waiting for anybody, and it moves the whole window.

Our own count: "three days" no longer means exceptional

Back in August we counted the same thing on the catalog file and wrote that the short window had eaten the others: 42 of the 48 entries added after the directive carried three days. We downloaded the file again today (version 2026.11.10) to look at the full year. That is 295 entries:

Five months on, the short window takes a little over half of the entire year. And what was a trend in August now shows up on the table: the two Barracuda entries are on three days, while the Outlook zero-day added on that same 10 November runs to the 24th. The catalog deadline has stopped being useful for ordering the queue, because most of it carries the same number. If you look for another signal in the entry, there is none either: all thirteen November entries carry "Unknown" in the known-ransomware-campaign-use field.

The four variables, turned into four questions of your own

The directive binds US federal agencies, not you. But the model is free and you can use it. This is what we ask when an advisory like this lands:

Of the four, the second, third and fourth can be read off the advisory and the catalog entry: they are written before you get there. The first one is answered cold, on an ordinary Tuesday, with an external scan and a date written down. If on advisory day you have to start by finding out whether the box is exposed, the deadline no longer matters: you are late for a reason that has nothing to do with Barracuda.

The setting that decides who arrives late

The gateway documentation describes three modes for Apply Patches, under Advanced > Firmware Update: Automatic, which will "check for patches on an hourly basis and automatically apply the patches"; Manual, to apply them by hand; and Disable, the mode for when you "want new patches to be visible, but do not want them to be applied". And it adds, verbatim: "This is the default mode." There is a second nuance on the same page: even in automatic mode, if a reboot is required the appliance will not reboot by itself — "You will be prompted to reboot the appliance to complete the update."

Now line that up with the dates. The patch came out on 2 November. The catalog recorded exploitation on the 10th. Eight days. For an appliance nobody ever took out of the default mode, eight days are eight days of nothing: the patch was listed in the interface, visible, waiting. We are not saying this to blame the vendor —a mail gateway not rebooting itself at eleven in the morning is a reasonable decision, and Barracuda does recommend enabling automatic patching. We say it because that setting is yours, and most people do not know which one they have. It is a one-minute question almost nobody asks until it matters.

The question almost nobody can answer

Back to the fourth demand in the entry: "discontinue use of the product if mitigations are unavailable". Translated for a 60-person company, it reads: can you take this appliance out of the path today? For a mail gateway the answer is an MX record and a half-hour decision. And it is almost never written down anywhere, because nobody has ever needed it.

This is where it stops being CVE news and becomes the same old conversation: failure is inevitable, an outage is a design decision. The failure is a vendor publishing a 9.3 on its gateway —it happens, and it happens to all of them. The outage is having no path for your mail that does not cross the compromised box. We have written that exercise twice already this year with other boxes: with the console that manages every machine you own and with the management plane of a firewall. It is the same pattern and only the product name changes: the more central the piece, the less anyone is prepared to switch it off.

When NOT to run

How we work this

We are not resellers of any particular platform: we design, deploy and maintain infrastructure, and we recommend based on the case. So what we take from this is not a gateway brand but four decisions. That a security appliance should not be trusted because of where it is plugged in, which is the whole idea of Zero Trust. That its admin interface should live on the management network and not on the internet. That the inventory should know which version each box runs and with which patching mode. And that someone should actually read its configuration change log — the one nobody does out of goodwill, and which ends up being the job of a managed detection and response service with the appliance's telemetry inside it.

And then there is the thing that actually changes the outcome on advisory day: having written down in advance how each central piece comes out of the path. Not because you are going to do it, which you almost never do, but because one day you will have to decide it in twenty minutes, and nobody improvises well at that hour. Writing it down costs you an afternoon. Not having it costs you the afternoon you do not have.

Sources (verified 12 Nov 2026): the CISA Known Exploited Vulnerabilities catalog file, version 2026.11.10 (verbatim descriptions and due dates for CVE-2026-116606, CVE-2026-111560 and CVE-2023-2868; the 2026 deadline count is ours, computed on that file); directive BOD 26-04 "Prioritizing Security Updates Based on Risk", 10 June 2026 (the four variables and the windows); Barracuda advisory "Pre-Authentication Authorization Bypass and Command Injection Vulnerabilities in Certain Barracuda Products", 2 Nov 2026, updated on the 5th and 9th (scores, products, patches and recommendations); vendor documentation on "Apply Patches" (the three modes and the default one).