FortiBleed: What the June 2026 Campaign Tells Us About Internet-Facing Appliance Risk

What happened

In mid-June 2026, threat intelligence feeds began surfacing indicators of a coordinated credential compromise campaign targeting organizations with internet-exposed FortiGate management interfaces. Tracked informally as "FortiBleed," this isn't a new vulnerability — it's an exploitation wave against CVE-2024-21762, patched in early 2024 but still unpatched in a significant number of production appliances.

What makes this campaign notable isn't the technique — it's the scale, and the specific targeting of management plane credentials rather than just VPN session tokens. Attackers want the keys to the management kingdom, not just a tunnel in.

The vulnerability: CVE-2024-21762

An out-of-bounds write in FortiOS and FortiProxy's SSL-VPN functionality. Successful exploitation allows an unauthenticated remote attacker to execute arbitrary code via specially crafted HTTP requests. Assetnote's research on the chunked transfer encoding bypass path became the basis for most public validation tooling, including the script below.

# FortiOS
7.4.x → 7.4.3+    7.2.x → 7.2.7+
7.0.x → 7.0.14+   6.4.x → 6.4.15+

# FortiProxy
7.4.x → 7.4.3+    7.2.x → 7.2.9+
7.0.x → 7.0.16+

What the campaign is actually doing

Phase 1 — Reconnaissance. Automated scanning against known FortiGate IP ranges identifying internet-exposed management interfaces. Fingerprint: high-volume chunked transfer encoding requests to /remote/login and /api/v2/ from rotating IP ranges.

Phase 2 — Credential extraction. On vulnerable appliances, attackers extract local admin credential hashes and VPN session tokens. In confirmed cases, extracted credentials were used within hours against downstream AD and RADIUS infrastructure.

Validation methodology

Safe probe — version detection and management interface exposure check only. No exploitation. Run against your own estate before the patch window opens.

#!/bin/bash
# CVE-2024-21762 patch validation
# Usage: ./fortibleed_check.sh --target <IP>
TARGET=$2; PORT=${4:-443}
echo "[*] Checking $TARGET:$PORT"
VERSION=$(curl -sk --max-time 5   "https://$TARGET:$PORT/api/v2/monitor/system/firmware"   -H "Content-Type: application/json" |   python3 -c "import sys,json;d=json.load(sys.stdin);  print(d.get('results',{}).get('current',{}).get('version','unknown'))" 2>/dev/null)
echo "[*] FortiOS: $VERSION"
MGMT=$(curl -sk --max-time 5 -o /dev/null -w "%{http_code}" "https://$TARGET:$PORT/login")
[ "$MGMT" = "200" ]   && echo "[!] Management interface INTERNET-REACHABLE"   || echo "[+] Management interface not directly reachable"

IOCs

# Source IP ranges (Jun 2026)
185.220.101.0/24    185.220.102.0/24
45.142.212.0/24     194.165.16.0/24
23.129.64.0/18

# User-agents in probes
"python-requests/2.28.2"
"Go-http-client/1.1"

# Targeted endpoints
POST /remote/login
GET  /api/v2/monitor/system/firmware
GET  /api/v2/cmdb/system/admin

What to do right now

1. Find internet-exposed management interfaces. Shodan your ASN or run the script above. If management is reachable from the internet, isolate it immediately — before patching.

2. Validate patch status. Use the version table. Below minimum safe version with internet-exposed management = assumed-compromise posture, not patch-and-move-on.

3. Review logs from June 10 onward. Anomalous admin logins, API key creation events, configuration changes.

4. If compromise is suspected. Rotate all local admin credentials, revoke VPN certificates, audit downstream trust relationships where FortiGate acts as authenticator.