Saturday 3 October 2026 522 stories on file Full archive
Daily Edition
newscms

Volume III Edition Daily

Two 9.8s in 48 Hours: Cisco Patched the SD-WAN Manager Auth Bypass, Fortinet Still Has No FortiMail Fix

Two critical, unauthenticated vulnerabilities in internet-facing security infrastructure landed in the CISA Known Exploited Vulnerabilities catalog within 48 hours of each other this week, and the difference in how the…

Cybersecurity 2,037 words 10 min read

Two 9.8s in 48 Hours: Cisco Patched the SD-WAN Manager Auth Bypass, Fortinet Still Has No FortiMail Fix — Cybersecurity No Image Cybersecurity
Lead image · Filed 3 October 2026, 04:50

Two 9.8s in 48 Hours: Cisco Patched the SD-WAN Manager Auth Bypass, Fortinet Still Has No FortiMail Fix

Introduction

Two critical, unauthenticated vulnerabilities in internet-facing security infrastructure landed in the CISA Known Exploited Vulnerabilities catalog within 48 hours of each other this week, and the difference in how the two vendors responded is the story worth tracking.

On September 30, Cisco published an advisory for CVE-2026-76504, an authentication bypass in the API of Cisco Catalyst SD-WAN Manager that lets an unauthenticated remote attacker reach the management API with admin privileges. The fix shipped the same day. Cisco added a temporary Live Protect shield as a bridge, published the exact fixed release for six different software trains, and handed customers a specific log file and log string to hunt for. CISA listed the flaw in KEV the same day with a remediation deadline of October 3.

Twenty-four hours later, Fortinet disclosed CVE-2026-104286, a path traversal in the FortiMail email security gateway that lets an unauthenticated attacker write arbitrary files to the underlying system and from there run commands on the appliance. It scores the same 9.8. CISA listed it in KEV on October 1 and set an October 4 deadline. There is no patch. FortiMail 7.4.9, 7.6.7 and 8.0.2 have not shipped, and the only thing a customer can do today is turn off a feature or pull the management interface off the internet.

Both bugs sit in the same uncomfortable place: the management and authentication layer of appliances that are, by design, bolted to the public internet. Neither is a bug in the traffic-filtering logic defenders think they are paying for. They are bugs in the front door. Our ongoing cybersecurity coverage has tracked this management-plane pattern through the year, and this week added two more entries to it.

The Cisco Flaw: One Encoded Character Is the Whole Attack

CVE-2026-76504 is a textbook improper-input-normalisation defect, classified as CWE-177, improper handling of URL encoding. Cisco's own advisory describes the mechanism plainly: the vulnerability is due to improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule intended to restrict access to a specific API endpoint.

The security consequence is not incremental. A successful exploit grants the attacker access to the API as the admin user. Because Cisco Catalyst SD-WAN Manager is the centralised console from which an operator monitors and manages an entire SD-WAN fabric — in some deployments thousands of devices — admin API access is effectively control of the WAN. An attacker in that position can view or modify the configuration of every device that Manager instance controls.

The exploitation technique is almost embarrassingly simple. Cisco's indicators of compromise point at requests to the j_security_check login-handler path where a single character has been URI-encoded, giving a log line like POST /%6a_security_check HTTP/1.1. Cisco is explicit that %6a is only an example and that an attacker can encode any one character in the request to achieve the same bypass. The second log to check is /var/log/nms/vmanage-server.log, where requests to j_security_check appear against usernames beginning with viptela-reserved-, the system's internal service accounts.

Two details matter for anyone triaging this. First, Cisco warns that these log entries can also occur during standard operations, so they must be assessed against normal network posture rather than treated as proof on their own. Second, the flaw is not configuration-dependent — it affects the product regardless of system configuration, with no feature toggle that removes the exposure. That is why the MS-ISAC advisory rates the risk HIGH across large and medium government entities, small government, large and medium business, and small business, with only home users assessed as LOW.

The uncomfortable context is recurrence. Cisco Catalyst SD-WAN Manager was already hit earlier in 2026 by two critical unauthenticated peering authentication flaws, CVE-2026-20127 and a second issue Rapid7 discovered and tracked as CVE-2026-20182. Both were distinct bugs in the vdaemon service and related parts of the networking stack. Rapid7's assessment is that the recurrence of authentication bypasses in internet-facing Catalyst SD-WAN control components reinforces the case for emergency remediation. Three separate authentication defects in one control plane in a single year is a design-review problem wearing a patch-management costume.

What Cisco got right was the response. Fixed releases were published for every supported train — 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 and 26.2.1 — with instructions for anything older to migrate. The cloud-hosted Cisco SD-WAN Cloud release 20.15.605 was fixed with no customer action required. Cisco then shipped a Live Protect shield under Snort Rule 67179 as temporary partial coverage while customers plan the upgrade, while being straight about its limitation: a legitimate user employing URI encoding may be unable to log in. Cisco also asked affected customers to open a Severity 3 TAC case with the CVE in the title and to generate an admin-tech file with the request admin-tech command before upgrading, so forensic evidence survives the rebuild. The full advisory was updated to version 1.1 on October 2 to add the Live Protect information.

The Fortinet Flaw: No Patch, Only a Feature to Switch Off

CVE-2026-104286 is the mirror image, and the operational situation is worse. Fortinet's advisory FG-IR-26-175, published October 1, describes an improper limitation of a pathname to a restricted directory (CWE-22) combined with improper neutralisation of NULL byte or NULL character (CWE-158). An unauthenticated attacker can write arbitrary files on the underlying system via crafted HTTP or HTTPS requests. The stated impact is execution of unauthorized code or commands.

The affected surface is broad: FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. That is essentially every currently supported release branch of the product.

The remediation is the problem. Fortinet lists 8.0.2, 7.6.7 and 7.4.9 as the upcoming releases containing the fix, and none of them have shipped. Customers on 7.2 are told to upgrade to the 7.4 branch or later. For everyone else, the advisory's field for Virtual Patch reads "No," and the workaround section is the entire defensive story. Administrators can disable Identity-Based Encryption support — via the GUI under Encryption to IBE to IBE Service 'off', or with a three-line CLI sequence that turns the feature's status to disabled. Alternatively they can remove internet access to the FortiMail webmail and management interfaces entirely, or restrict access to trusted private networks only. For deployments with a web application firewall in front, Fortinet adds a third option: block POST requests to /ibe that contain ../.

The workaround is not cosmetic. Turning off IBE breaks a real mail function, and the affected appliance is an email security gateway sitting between an organisation and the public internet — exactly the class of device that should never be reachable from it in the first place. The disclosure path is also notable: the flaw was found internally by Gwendal Guégniaud of Fortinet's Product Security team, not by an outside researcher or a bug bounty, and the advisory timeline contains a single entry, 2026-10-01 initial publication. SecurityWeek noted that neither Fortinet nor CISA has provided details on the observed attacks.

The indicators of compromise are unusually detailed for a disclosure this early, and they read like an intrusion already in progress. Two IP addresses are listed: 79[.]141.169.187 and 45[.]129.0.192. Seven filesystem artefacts are named with SHA-256 hashes, split into files that were added and files that were modified. The added set includes /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice and /data/etc/ld.so.preload — a preloaded shared object is a textbook route to intercepting every process on the box. The modified set includes /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz.

The log entries are more telling than the hashes. One shows a root cron job executing /bin/sh -c 'O=/migadmin ...'. Another shows an administrator logging out from a null interface. The most revealing is a configuration event: an archive account named archive234 being added from the command line, with 79.141.169.187 as the remote IP, credentials embedded, and /uploads as the remote directory. That is not persistence, it is exfiltration plumbing — a mail gateway reconfigured to ship stored mail to an attacker's server. A fourth entry, an Identity-Based Encryption decryption failure complaining of invalid Base64 encoding, ties the activity back to the exact code path Fortinet identified as the workaround.

Why the Asymmetry Is the Lesson

The two advisories describe the same severity class, the same attack profile — unauthenticated, remote, internet-facing — and the same regulatory clock, with CISA deadlines of October 3 for Cisco and October 4 for Fortinet. What separates them is whether a fix existed on the day the news broke.

For a defender running Cisco Catalyst SD-WAN Manager, this week has a concrete finish line. Upgrade out of cycle, check two log files for encoded-character requests to the login handler, capture admin-tech before you touch anything. For a defender running FortiMail, the work is defensive and uncomfortable: disable Identity-Based Encryption or cut the management interface off the internet, then run Fortinet's indicator list against the appliance. That last step is not optional theatre. An attacker who wrote a preloaded library and configured a remote archive destination has already done more than read mail, and the absence of a patch does not mean the absence of a compromise.

There is a broader signal in the timing. CISA said this month that it is ending its weekly Vulnerability Bulletin, published since early 2004, as part of a shift from severity-based to risk-based vulnerability management, directing agencies to prioritise on real-world risk factors such as evidence of exploitation and exposure rather than CVSS scores alone. Both of this week's flaws score 9.8, which is precisely the scenario the new model was designed for — severity is not what separates these two advisories. Exploitability and patch availability are. Vendors and defenders who still triage by score alone will rank a fixable bug and an unfixable one identically, and then discover the difference only after the unfixable one is in the hands of an attacker. That is the wrong order to learn it in.

Conclusion

The lesson of this week is not that nine-point-eight bugs are inevitable. It is that the gap between a vendor who ships a fix and a vendor who ships a workaround is the gap between a Tuesday and a quarter of exposure. Cisco found its bug through a support case, learned of active exploitation in September, published and patched within the same news cycle, and even offered a temporary shield for customers who cannot upgrade immediately. Fortinet found its bug internally, confirmed exploitation in the wild, and told the world to switch off a feature until an unspecified date.

Both flaws sit in the same architectural blind spot: the authentication and management layer of the perimeter devices organisations bought specifically to be the hardened edge. Both are CWE-class input-handling defects that a code review and a fuzzing pass should have caught before release. Both were reachable without a single credential. For anyone who has ever exposed an appliance console to the internet for convenience, the practical takeaway is unglamorous and unchanged — put the management plane behind a VPN or a filtering device, and treat the two October deadlines as hard stops rather than targets.

Images

A Fortinet FortiGate network-security appliance photographed from the front, showing the vendor logo, honeycomb ventilation grilles and the row of Ethernet and SFP ports along its lower panel. The appliance is a sibling product line to the FortiMail gateway discussed above, shown here as illustrative of the edge-security hardware class rather than the affected unit itself.

An open 19-inch network cabinet containing rackmount Ethernet patch panels, dense runs of grey patch cords with service loops, and two stacked rackmount switches with status LEDs illuminated. This is the kind of access layer that sits behind an SD-WAN control plane's management interface.

References