Fortinet security advisory (AV26-023) - Update 1

CVE-2025-25249 is a heap-based buffer overflow (CWE-122) in the cw_acd daemon, the CAPWAP control-plane service FortiOS runs for fabric and access-point management, present in FortiSwitchManager as well. Fortinet disclosed it on January 13, 2026 in advisory FG-IR-25-084 as an internal discovery by Gwendal Guegniaud: a remote unauthenticated attacker can reach code execution with crafted packets, with ASLR and PIE flagged as raising exploitation effort, and the branch list is wide, FortiOS 7.6.0 through 7.6.3, 7.4.0 through 7.4.8, 7.2.0 through 7.2.11, 7.0.0 through 7.0.17, all of 6.4, FortiSwitchManager 7.2.0 through 7.2.6 and 7.0.0 through 7.0.5, with FortiSASE 25.2.b and 25.1.a.2 named in the same January batch. On September 9, 2026 CISA added the CVE to the KEV catalog with a September 12 federal deadline and the BOD 26-04 forensic triage requirement attached, which is the entire content of this story. NVD scores it CVSS 3.1 9.8 while the vendor page shows 7.4, the gap being an attack-complexity disagreement.

That scoring argument is now settled by evidence: KEV listing means exploitation is observed, so the AC:H stance aged badly, and the eight months between patch and exploitation telemetry say something about who the victims are. Nobody running the January fix is in scope; the exposed population is precisely the long-lived, unattended installs, the branch and edge sites where an interface keeps 'fabric' in allowaccess because a FortiAP hangs off it and nobody revisits the config. A hit here is the perimeter device itself, not one more server: the firewall holds credentials and tunnel state, sees all traffic, and becomes the pivot into everything behind it. CISA's triage tag makes the correct posture breach-presumption rather than patch-and-move-on, and any hunt has to reach back to at least January 13, 2026, since the vulnerable code predates the disclosure by years, not months.

The remediation is exact. Upgrade to FortiOS 7.6.4, 7.4.9, 7.2.12, or 7.0.18 at minimum, migrate off 6.4, and take FortiSwitchManager to 7.2.7 or 7.0.6, following Fortinet's upgrade-path tool for branch chains. Where patching waits, FG-IR-25-084 gives two mitigations: remove 'fabric' from set allowaccess on every interface, or define a CAPWAP-CONTROL service for UDP 5246-5249 and enforce local-in policies that accept only known AP and switch subnets while denying everyone else. The hunt follows the protocol: local-in hits on UDP 5246-5249 from sources outside management and FortiAP subnets, fabric device registrations or admin objects you did not create, configuration revisions in the event log without a matching change ticket, and outbound sessions originated by the appliance itself, which has no normal reason to phone out.

Two developments would move this assessment. Confirmation of ransomware use would sharpen it from targeted access to infrastructure destruction, since CISA currently lists ransomware campaign use as Unknown for this CVE, and Fortinet gateways have historically been pre-positioning targets rather than final stops. And any public proof-of-concept or mass-scanning telemetry against UDP 5246-5249 would collapse the mitigation window, because local-in policies then become the only thing standing between thousands of unpatched fabric-enabled appliances and background-noise exploitation.