BlackTree Security · Infrastructure · Automation · AI

The WatchGuard Firebox Flaw Patched Nearly Nine Months Ago Is Now Tied to Ransomware

A critical WatchGuard Firebox vulnerability that received fixes in December 2025 now carries a more serious warning. CISA’s current Known Exploited Vulnerabilities catalogue identifies CVE-2025-14733 as used in known ransomware campaigns. The flaw can give an unauthenticated remote attacker code execution in the IKE process of a vulnerable firewall.

For organisations still running an affected Fireware release, this is no longer only a patch-management problem. It is an incident-response question. Installing a fixed version closes the vulnerable path, but it cannot establish whether an attacker already used that path to take configuration data, management credentials or other secrets from the appliance.

CISA does not name a ransomware group, describe individual victims or connect every exploitation attempt with ransomware. WatchGuard separately reports active attempts to exploit the vulnerability and two forms of post-exploit data theft. Those findings are serious, but they must not be combined into a more specific attribution than the public evidence supports.

The ransomware warning arrived long after the patch

WatchGuard published its advisory on 19 December 2025. CISA added the vulnerability to the KEV catalogue on the same date and required US federal civilian agencies to remediate it by 26 December. WatchGuard updated its advisory on 10 August 2026 with field observations, indicators and response guidance.

The current CISA record goes further by marking known ransomware campaign use. That field is a prioritisation signal, not a complete incident report. It tells defenders that the vulnerability has appeared in ransomware activity, but it does not disclose which operation used it, when that use occurred or how many organisations were affected.

The absence of those details should narrow the language, not the response. An internet-facing security appliance that can be compromised before authentication and can expose locally stored secrets sits at the beginning of several plausible intrusion paths. Ransomware operators do not need the firewall itself to encrypt files for control of the appliance to become valuable.

The vulnerable configuration is narrower than the product name

CVE-2025-14733 is an out-of-bounds write in the Fireware OS iked process. WatchGuard says a remote attacker can exploit it without authentication to execute arbitrary code. The affected path is associated with mobile-user VPN using IKEv2 and branch-office VPN using IKEv2 with a dynamic gateway peer.

There is an easy-to-miss configuration trap. A Firebox can remain vulnerable after the mobile-user or dynamic-gateway IKEv2 configuration has been deleted if a branch-office VPN to a static gateway peer is still configured. A present-day configuration review alone may therefore miss appliances that retained exposure created by an earlier setup.

Fireware branchAffected releasesRequired destination
Default, current branch2025.1 up to, but not including, 2025.1.42025.1.4 or later
Default, 12.x branch12.0 up to, but not including, 12.11.612.11.6 or later
Default, legacy 11.x branch11.10.2 through 11.12.4+541730. This branch is end of life.Migrate to a supported branch and install its current fixed release. WatchGuard does not list a deployable 11.x fixed build.
T15 and T3512.0 up to, but not including, 12.5.1512.5.15 or later
FIPS12.0 up to, but not including, 12.3.1+72835212.3.1+728352 or later

Administrators should compare the running version and appliance branch with WatchGuard’s advisory rather than assuming that a numerically higher release on a different branch is equivalent. The 11.x branch is end of life, and the vendor does not identify an available 11.x fixed build. Any appliance still on 11.x must move to a supported branch and its current fixed release. Administrators should also verify the version on high-availability peers, standby appliances, branch units and customer devices managed by a service provider.

WatchGuard saw attackers steal the information needed for the next move

WatchGuard describes two observed post-exploit variants against exposed Firebox appliances. In one, the attacker encrypted and exfiltrated the active configuration file to the same IP address used for the attack. In the other, the attacker created a compressed archive containing both the active configuration and the local management-user database, then exfiltrated it.

That activity matters even when the appliance shows no conventional ransomware payload. A firewall configuration can reveal network relationships, VPN design and security policy. Locally stored secrets or management-account material can support renewed access, lateral movement or attacks on connected environments. WatchGuard therefore instructs administrators to rotate all locally stored secrets when successful exploitation is suspected.

WatchGuard’s observations should not be represented as proof that the same actors described by CISA deployed ransomware. The defensible conclusion is more precise: attackers have exploited the vulnerability to steal sensitive appliance data, and CISA separately says the vulnerability has been used in known ransomware campaigns.

The logs can show an attempt, but one signal is not a verdict

WatchGuard has published network and device indicators for vulnerable appliances. Outbound connections to the listed threat-actor addresses are described as a strong indicator of compromise. Inbound connections from them may instead represent reconnaissance or an exploitation attempt.

An IKE_AUTH request with an abnormally large certificate payload, greater than 2,000 bytes in WatchGuard’s example, is a strong attack indicator when information-level IKE diagnostic logging is available. An error stating that a peer certificate chain is longer than eight entries is a medium indicator. During successful exploitation, the IKE process may hang and interrupt new VPN negotiations and re-keys while existing tunnels continue to carry traffic.

An IKE process crash is weaker evidence because unrelated faults can cause the same behaviour. Responders should correlate crashes, certificate-chain messages, outbound connections, configuration access and management changes rather than using any single event as automatic proof of compromise.

What Firebox operators should do now

  1. Find every appliance and verify its running version. Include high-availability peers, branch firewalls, cold spares brought online, customer-managed units and devices that have stopped reporting to central management.
  2. Reconstruct the relevant VPN history. Check whether mobile-user IKEv2 or a dynamic-gateway branch-office VPN was previously configured, even if it has since been deleted.
  3. Install a fixed Fireware release. Use the appropriate supported branch from WatchGuard’s current advisory and confirm the running build after the maintenance completes.
  4. Preserve evidence before disruptive remediation. Export relevant logs, fault reports, configuration-change records and network telemetry according to the organisation’s response process. A reboot or rebuild may remove useful evidence.
  5. Hunt with WatchGuard’s complete indicator set. Review inbound and outbound connections involving the published IP addresses, unusually large IKE_AUTH certificate payloads, certificate-chain errors, IKE hangs and crashes, unexplained configuration exports and access to the local management-user database.
  6. Rotate secrets when exploitation is suspected. Follow WatchGuard’s rotation guidance for locally stored secrets. Review connected VPN peers and administrative accounts rather than limiting the response to the firewall password.
  7. Assess downstream access. Investigate authentication, remote administration and network activity originating from or associated with the appliance. Determine whether stolen configuration or credentials could have been used elsewhere.
  8. Escalate when appliance integrity is uncertain. Contact WatchGuard support and follow the organisation’s incident-response process. A fixed version prevents exploitation of this flaw but does not prove that a previously exposed appliance is clean.

This is not the September 2026 Firebox bulletin

BlackTree recently covered three newer critical Firebox vulnerabilities disclosed in August 2026. Those flaws have different CVE identifiers and fixed releases. WatchGuard reported no exploitation of them at the time of that article.

Updating for the newer bulletin should bring an appliance beyond the older CVE-2025-14733 fixed baseline on the corresponding supported branch, but defenders must verify the actual running release. More importantly, installing today’s firmware does not answer whether an appliance was exposed and compromised before it was updated.

The distinction also applies to WatchGuard’s endpoint software. BlackTree’s analysis of two unauthenticated WatchGuard Agent vulnerabilities concerns a Windows security agent, not the Firebox IKE service. Similar vendor names do not make the attack paths or remediation interchangeable.

The patch date is not the incident date

Nearly nine months is a long time for an exposed perimeter appliance to sit between a published fix and a ransomware warning. Some organisations will discover that they patched long ago. Others may find an overlooked branch firewall, an unsupported release or a device whose historical VPN configuration kept it vulnerable in a way the current screen did not reveal.

The most dangerous assumption is that a successful update closes the entire event. It closes CVE-2025-14733. It does not rotate a stolen secret, reverse an unauthorised configuration export or explain an outbound connection that occurred before the maintenance window. Once an exploited edge flaw becomes associated with ransomware, the correct finish line is not merely patched. It is patched, investigated and able to account for what happened while the door was open.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *