CISA dropped an alert on June 18 telling everyone with internet-facing FortiGate firewalls and SSL VPN gateways to lock things down. The campaign is being called FortiBleed.
The important part: this is NOT a new zero-day. CISA and Fortinet both say it comes from reused and un-rotated credentials from earlier infostealer leaks, combined with brute-force activity. Fortinet says no new vulnerability exists in their products.
CISA says the activity "involves the exposure of leaked credentials associated with approximately 74,000 Fortinet devices." SOCRadar says it is worse, citing "over 86,644 confirmed working credentials across 194 countries."
Researcher Bob Diachenko found an exposed server with valid VPN creds, usernames, emails, and plaintext passwords, attributed to a Russian-speaking cybercrime group.
Kevin Beaumont, working with Hudson Rock, verified the data is real: "I have worked with several orgs listed, and can confirm the logins and passwords are real. Many of the devices sampled are on fairly recent patches."
Even 25+ character passwords showed up in plaintext, so these were pulled from harvested infostealer logs, not cracked.
Huntress identified 845 impacted partner orgs. TechCrunch named alleged victims including Accenture, Comcast, Foxconn, Lenovo, Oracle, Samsung, Siemens, and PwC. Bitsight confirmed active exploitation with tunneling tools Chisel and Neo-reGeorg.
NCSC, Canada's Cyber Centre (AL26-014), the FBI, and HKCERT all put out warnings too.
What CISA wants you to do now: kill all SSL VPN and admin sessions, reset every VPN and admin password, turn on phishing-resistant MFA, and dig through logs for unauthorized access or lateral movement. Canada also says audit for rogue accounts like forticloud-sync and forticloud-tech, and verify patches for CVE-2024-55591, CVE-2025-59718, and CVE-2025-59719.
So basically, if you run Fortinet edge gear, today is a password rotation day whether you planned one or not.
https://www.cisa.gov/news-events/alerts/2026/06/18/cisa-urges-hardening-fortinet-devices-after-reports-credential-exposure
Fortinet customers are seeing attackers exploiting a patch bypass for a previously fixed critical FortiGate authentication vulnerability (CVE-2025-59718) to hack patched firewalls.
CVE-2025-59718, a critical authentication bypass flaw that attackers exploited in December 2025 to compromise FortiGate appliances, appears to persist in newer, purportedly fixed releases of the underlying FortiOS.
An issue was discovered in Fort before 1.6.3. A malicious RPKI repository that descends from a (trusted) Trust Anchor can serve (via rsync or RRDP) a resource certificate containing a bit string that doesn't properly decode into a Subject Public Key. OpenSSL does not report this problem during parsing, and when compiled with OpenSSL libcrypto versions below 3, Fort recklessly dereferences the pointer. Because Fort is an RPKI Relying Party, a crash can lead to Route Origin Validation unavailability, which can lead to compromised routing.
An issue was discovered in Fort before 1.6.3. A malicious RPKI repository that descends from a (trusted) Trust Anchor can serve (via rsync or RRDP) a resource certificate containing an Authority Key Identifier extension that lacks the keyIdentifier field. Fort references this pointer without sanitizing it first. Because Fort is an RPKI Relying Party, a crash can lead to Route Origin Validation unavailability, which can lead to compromised routing.
An Improper Neutralization of Input vulnerability affecting FortiGate version 6.2.0 through 6.2.1, 6.0.0 through 6.0.6 in the hostname parameter of a DHCP packet under DHCP monitor page may allow an unauthenticated attacker in the same network as the FortiGate to perform a Stored Cross Site Scripting attack (XSS) by sending a crafted DHCP packet.
A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI Relying Parties (such as Fort) are supposed to maintain a backup cache of the remote RPKI data. This can be employed as a fallback in case a new fetch fails or yields incorrect files. However, the product currently uses its cache merely as a bandwidth saving tool (because fetching is performed through deltas). If a fetch fails midway or yields incorrect files, there is no viable fallback. This leads to incomplete route origin validation data.
An integer underflow was discovered in Fort 1.6.3 and 1.6.4 before 1.6.5. A malicious RPKI repository that descends from a (trusted) Trust Anchor can serve (via rsync or RRDP) a Manifest RPKI object containing an empty fileList. Fort dereferences (and, shortly afterwards, writes to) this array during a shuffle attempt, before the validation that would normally reject it when empty. This out-of-bounds access is caused by an integer underflow that causes the surrounding loop to iterate infinitely. Because the product is permanently stuck attempting to overshuffle an array that doesn't actually exist, a crash is nearly guaranteed.
A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI manifests are listings of relevant files that clients are supposed to verify. Assuming everything else is correct, the most recent version of a manifest should be prioritized over other versions, to prevent replays, accidental or otherwise. Manifests contain the manifestNumber and thisUpdate fields, which can be used to gauge the relevance of a given manifest, when compared to other manifests. The former is a serial-like sequential number, and the latter is the date on which the manifest was created. However, the product does not compare the up-to-dateness of the most recently fetched manifest against the cached manifest. As such, it's prone to a rollback to a previous version if it's served a valid outdated manifest. This leads to outdated route origin validation.
A heap-based buffer overflow vulnerability in the processing of Link Control Protocol messages in FortiGate versions 5.6.12, 6.0.10, 6.2.4 and 6.4.1 and earlier may allow a remote attacker with valid SSL VPN credentials to crash the SSL VPN daemon by sending a large LCP packet, when tunnel mode is enabled. Arbitrary code execution may be theoretically possible, albeit practically very difficult to achieve in this context
An insufficient logging vulnerability in FortiGate before 6.4.1 may allow the traffic from an unauthenticated attacker to Fortinet owned IP addresses to go unnoticed.
A heap-based buffer overflow [CWE-122] in the firmware signature verification function of FortiOS may allow an attacker to execute arbitrary code via specially crafted installation images.
A debug functionality in FortiGate may allow a privileged user to execute unauthorized code or commands via specificchains of print str and cmd mem cli commands to, respectively, read and write hexadecimal values to any memory address.
A clear text storage of sensitive information (CWE-312) vulnerability in both FortiGate and FortiAuthenticator may allow a local unauthorized party to retrieve the Fortinet private keys used to establish secure communication with both Apple Push Notification and Google Cloud Messaging services, via accessing the files on the filesystem.
The potentially exposed private keys have been revoked, please upgrade to the versions provided in the solutions to support push proxy.
The FTP component in FortiGate 2.8 running FortiOS 2.8MR10 and v3beta, and other versions before 3.0 MR1, allows remote attackers to bypass the Fortinet FTP anti-virus engine by sending a STOR command and uploading a file before the FTP server response has been sent, as demonstrated using LFTP.
Interpretation conflict in Fortinet FortiGate 2.8, running FortiOS 2.8MR10 and v3beta, allows remote attackers to bypass the URL blocker via an (1) HTTP request terminated with a line feed (LF) and not carriage return line feed (CRLF) or (2) HTTP request with no Host field, which is still processed by most web servers without violating RFC2616.
FortiGate's and FortiADC's read-only admins are able to point an LDAP server connectivity test request to a rogue LDAP server instead of the configured one, in order to obtain the LDAP server login credentials configured in the FortiGate.