Ten CVEs in one process: the headline is not enough to decide

Among the ten advisories WatchGuard published on 27 August about iked, there is one titled "Allows Unauthenticated Denial of Service". Its own impact field, four lines further down, opens like this: "A remote, authenticated IKEv2 peer (a legitimate VPN user with valid credentials…)". The headline says "unauthenticated". The body says "a user of your VPN holding valid credentials". Both are on the same page, and only one of them is any use in deciding whether you call somebody tonight.

We design and run multi-site networks with IPsec tunnels, so a bulletin like this one lands on our desk several times a month. This one seemed worth writing up because it is large — ten flaws in a single process, published on the same day — and because reading it in full, page by page, it comes apart into something rather different from what the count suggests. This is not about scaring anyone with one vendor: whoever made the box on your wall does not change the argument, and the method works for any of them. Everything below comes from the ten public advisory pages on the vendor's own PSIRT and from a couple of other sources, all cited at the end.

What iked is, and why ten is a lot

iked is the daemon that speaks IKE, the protocol two endpoints use to agree the keys for an IPsec tunnel: the one that brings up the VPN between head office and each branch, and the one that answers the laptop dialling in from a hotel. To do that job it has to read packets from an address it has not authenticated yet; it cannot work any other way, because authentication is precisely what is being negotiated. That is why a batch of flaws there reads differently than one in the management panel, which you lock down to four addresses and forget about.

The vendor's PSIRT index lists twenty-eight advisories dated 27 August 2026: sixteen for Dimension, their reporting platform, and twelve for Fireware OS, the firewall's operating system. Of those twelve, ten are in iked. Three are titled remote code execution, all three at 9.3 on CVSS v4; six are titled denial of service at 8.7, and one at 6.9. Nine of the ten are fixed in Fireware OS 2026.2.2, 12.12.2 and 12.5.20 for the T15 and T35 models; the 6.9 was already closed in the previous release of each branch. And the vendor states, on all ten pages, that it is not aware of any exploitation in the wild.

The word that falls out of the headline

The three 9.3 advisories are titled "Allows Remote Code Execution". None of the three bodies claims code has been executed. The heap overflow one says "causing a crash and denial of service, with the potential for remote code execution". The type confusion one says it crashes the daemon and that, because it reaches a free() on an attacker-influenced pointer, it "may also present potential for further memory corruption and remote code execution". The third, "may carry potential for remote code execution". Three times "potential", three times outside the headline.

This does not make them harmless, and that is not what we are saying. Two of the three take iked down from outside with no prerequisite at all, and taking iked down means no tunnels for the branches and no VPN for anyone working remotely; for those two a single well-formed IKE_AUTH message is enough. The third also needs a diagnostic switch left on, which we come back to shortly. What changes is the sentence you say to the board. "They can run code on our firewall" and "they can drop our VPNs, and there are signs it could go further" are not the same conversation, and only one of the two is backed by the document.

The ten, read by what it takes to reach them

A headline describes the class of the flaw — stack overflow, double free, integer underflow — and the score summarises its severity in the abstract. The decision, though, hangs on something else: what the attacker needs in order to get there. That is only in the body, and across this batch it is not the same for all ten.

Read that way, the batch sorts itself. Six are reachable by a stranger from the internet with nothing at all. One needs somebody to have left a diagnostic switch on. One needs valid credentials for your own VPN, which is a real scenario — an employee, a stolen laptop, a supplier — but not the same scenario. One needs to be an administrator of the device, that is, somebody who can already do far more damage by opening the menu. And for one, the vendor itself writes that "internal verification against a fixed build using a reconstructed proof-of-concept did not reproduce an iked crash": it publishes it anyway, 8.7 and all, and we think publishing it is the right call — but it is worth knowing it is there.

The one we would look at first is none of the three 9.3s

The advisory among the ten that worries us most is CVE-2026-78009, which carries 8.7 and is titled, once again, denial of service. Its body says an unauthenticated attacker who completes the initial exchange can send an encrypted INFORMATIONAL message with a malformed DELETE payload and make iked read up to roughly 196 KiB past the end of a heap allocation. And it continues: as well as reliably crashing the process, it "could potentially expose adjacent heap memory (e.g., other IKE SA key material or certificate data) to an attacker under favorable heap layout conditions".

A process that crashes comes back; several of these advisories say so themselves, crash and respawn. Key material that walks out of the door does not come back. One conditional stacked on another — "could", "under favorable conditions" — is exactly the kind of sentence that does not justify a three-in-the-morning alarm, and we are not going to pretend it does. But of the ten, it is the only one whose consequence outlives the restart without depending on a "potential" coming true, and it sits lower down the list if you sort by score. Sorting by CVSS is sorting by severity in the abstract; sorting by "what is left once this is over" gives a different order.

Who found them, which is also published

The advisories carry the credit, and the split explains a fair bit. Six of the ten name a researcher at an external offensive-security firm. Three — the three in the 780xx series — say, word for word, "Discovered Internally by WatchGuard AI Security Research". And the tenth, the 6.9, comes from an independent researcher. Which means the ten did not appear on 27 August: they were published on 27 August, and they came out of two separate campaigns aimed at the same daemon.

Our reading, and it is opinion: a long list does not say the code got worse, it says somebody finally looked. A vendor standing up an internal team to hunt its own bugs and publishing what it finds under that name is one of the genuinely good things in this bulletin. Do not confuse the roles, though: whoever is credited with the finding does not write the advisory's headline. The headline comes out of the vendor's publication process, and that is where the word "potential" goes missing and where a flaw that needs credentials ends up announced as if it did not.

And even so: one update closes all ten

Time to deflate the article, because otherwise it would be dishonest. Nothing in this reading changes what has to be done: move to 2026.2.2, 12.12.2 or 12.5.20 depending on the branch, and that is it, all ten closed at once. Reading the ten pages takes about forty minutes and does not save you a single reboot.

What it decides is when, and what you say in the meantime. If the reading tells you six of them are reachable by anyone on the internet, the window is this week and it justifies itself. If it told you — which is not the case here — that the serious ones need credentials or console access, the window is next month's and that justifies itself too. The difference between those two decisions is forty minutes of reading, and the expensive mistake is not erring upwards: it is the habit of handling all ten bulletins of the month by their headline until one of them mattered. Why that window exists or does not, we already wrote about five days ago apropos of a different perimeter appliance, and we are not repeating it here.

How we read a bulletin like this

1. The impact field before the title. The title is the class of flaw; the impact is what happens and what it takes to make it happen. When the two disagree, the impact wins — and make a note: you have just learned something about how that vendor publishes.
2. Underline the weak verbs. "Could", "potential", "if exploitable", "under favorable conditions". They are not legal padding: they are the gap between what was demonstrated and what is feared, and your decision comes out of that gap.
3. Sort by what is left afterwards, not by the score. The list sorted by consequence rarely matches the one sorted by CVSS, and the one that decides your evening is the first.
4. Cross-check each prerequisite against your actual configuration, not the one you remember. "Requires diagnostic logging enabled" is a question you can answer this afternoon, and the answer says more about your operation than about the CVE.
5. Write down the sentence you are going to say out loud before you say it. If you cannot back it by pointing at the paragraph it came from, it is not yours yet.

And a note that puts the rest in order: not every bulletin deserves forty minutes. This one did, because of where it sat — the process that answers before authenticating — and because of its size. We covered the other side three days ago when we counted CISA's catalogue of exploited vulnerabilities: what actually ends up being used against somebody is almost never exotic. This same vendor's Firebox already produced two of those in two months: CVE-2025-9242, added to the catalogue on 12 November 2025 with a 3 December deadline, and CVE-2025-14733, added on 19 December with a 26 December one. Both out-of-bounds writes. When that happens there is no bulletin to read: you patch.

Sources

The count of advisories dated 27 August 2026 and their split between Dimension and Fireware OS come from WatchGuard's public PSIRT index. The titles, CVSS v4 scores, quoted impact fields, prerequisites, credits and fixed versions come from the ten individual advisories: 19313, 19314, 19315, 19316, 19317, 19318, 78009, 78010, 78011 and 81851. The English quotations are reproduced verbatim and the text explains in each case what they say. The two Firebox entries in CISA's Known Exploited Vulnerabilities catalogue — CVE-2025-9242, added 2025-11-12 with a 2025-12-03 deadline, and CVE-2025-14733, added 2025-12-19 with a 2025-12-26 deadline, both described as out-of-bounds writes — come from the catalogue's own public JSON; Security Affairs covered the second. The tally in the table — six reachable with nothing, one needing diagnostic logging on, one needing VPN credentials, one needing an administrator session and one not reproduced — is ours, made by reading the ten impact fields; anyone can redo it from the links above and land on a different split if they read some advisory differently. The opinions are ours: that the headline describes the class while the impact carries the decision, that losing the word "potential" changes the conversation with the board, that CVE-2026-78009 is the one we would look at first despite its 8.7, that a long list indicates somebody audited the code rather than that the code got worse, and that publishing a flaw you could not reproduce is the right call — these come from designing and running multi-site networks, not from the sources cited.