Two Ways to Lose a VPN Gateway: FortiBleed's Credential Harvest and PAN-OS's Forged Auth Cookie

Three posts this week already covered VPN-edge trouble on this site: an unauthenticated DoS in Cisco Secure Firewall’s RA VPN service, a certificate-trust gap in FortiManager’s FGFM protocol, and a RADIUS wildcard misconfiguration letting anyone into FortiWeb’s admin GUI. This one goes back a little further, to two incidents from earlier in the summer that between them make a cleaner point than any single CVE could: the VPN gateway is where an organization’s entire trust model gets tested at once, and it can fail in completely different ways that look identical from the outside.

FortiBleed hit Fortinet FortiGate devices in June 2026. It has no CVE number and no patch, because it isn’t a vulnerability in the traditional sense. CVE-2026-0257 hit Palo Alto Networks PAN-OS GlobalProtect around the same time. It is a vulnerability, a real one, with a CWE classification and a code fix. Both ended with an attacker inside the network with no valid credentials of their own. The paths there couldn’t be more different.

FortiBleed: nothing to patch, because nothing was broken in the code

CISA’s own framing of FortiBleed is the right place to start: “this campaign does not exploit a software vulnerability: there is no patch that closes it.” Security researcher Volodymyr “Bob” Diachenko first flagged it publicly on June 13, 2026, after finding an exposed attacker-controlled directory of what looked like working FortiGate credentials. Arctic Wolf published its own technical bulletin on June 17, and CISA issued a hardening alert on June 18, urging Fortinet customers to reset every VPN and administrative password immediately rather than wait for anything to patch.

The scale estimates vary depending on who ran the count and when. SOCRadar identified operational infrastructure belonging to the threat group, including a database of confirmed working credentials for over 30,791 devices. A separate analysis by researcher Kevin Beaumont, done in collaboration with Hudson Rock, put the figure closer to 75,000 devices, roughly half of all internet-facing FortiGate firewalls by Shodan’s count, across 194 countries. Different snapshots, different methodologies, same conclusion: a very large fraction of the internet’s exposed FortiGate estate had real, working administrator credentials sitting in a criminal’s hands.

The mechanism, per Arctic Wolf’s write-up, comes down to a hashing migration that never finished. FortiOS historically stored administrator passwords as salted SHA-256 hashes. Fortinet introduced PBKDF2-based hashing in FortiOS 7.2.11, 7.4.8, and 7.6.1, a meaningfully stronger algorithm against offline cracking. But upgrading FortiOS doesn’t retroactively rehash existing admin passwords. They stay as SHA-256 until that specific administrator logs in again after the upgrade. On a device nobody has touched since the version bump, the credential sitting in the configuration file is still cracked in the old, weaker format. Threat actors extracted configuration files from internet-facing FortiGate devices, whether through exposed management interfaces, prior compromises, or leaked backups, and cracked the SHA-256 hashes offline at scale.

There’s a second layer to this worth knowing if you administer FortiGates: even after an admin’s password does get migrated to PBKDF2, Fortinet keeps the old SHA-256 hash around in a hidden old-password field for backward compatibility. It’s invisible in the GUI, but it’s sitting right there in any configuration backup a super_admin pulls. The actual fix isn’t just “upgrade and wait”: it’s enabling login-lockout-upon-weaker-encryption under system password-policy, which is what forces the legacy hash out for good.

One thing worth being precise about, since a few secondary write-ups blur it: this is not the same incident as CVE-2026-24858, the FortiCloud SSO authentication bypass Fortinet disclosed back in January 2026 (an attacker with any FortiCloud account reusing an SSO token to log into other customers’ devices). That’s a real, separate CVE with its own patch and its own IOCs, and it’s worth patching regardless. But FortiBleed’s root cause, per CISA and Arctic Wolf’s own technical detail, is credential exposure through configuration extraction and offline cracking, not SSO token abuse. Two different Fortinet incidents in the same year, worth not collapsing into one story.

CVE-2026-0257: a certificate doing a second job it was never checked for

Palo Alto Networks published the advisory for CVE-2026-0257 on May 13, 2026: an authentication bypass in the GlobalProtect portal and gateway, CWE-565, reliance on cookies without validation and integrity checking. It only applies to a specific configuration: GlobalProtect’s “authentication override cookie” feature enabled (the Generate or Accept cookie for authentication override options), combined with what Palo Alto’s advisory calls “a specific certificate configuration.”

That configuration is the interesting part. GlobalProtect can be set up to reuse the same certificate for the portal or gateway’s ordinary HTTPS service and for encrypting the authentication override cookie. The portal’s HTTPS certificate is not a secret. Every client that connects to it during a normal TLS handshake receives that certificate, public key included. If the cookie mechanism doesn’t separately validate a real signature on top of that shared certificate, an attacker who has simply visited the portal already has everything needed to forge a cookie that looks legitimate. No credentials, no MFA prompt, just a crafted cookie and a fully authenticated VPN session.

That’s a near-exact structural echo of the FortiManager FGFM post from three days ago: a certificate meant to prove one kind of trust (TLS server identity) got reused to prove a second kind of trust (cookie authenticity), and the checks that made the first purpose safe were simply absent for the second. Palo Alto’s fix is to regenerate the cookie using a properly validated method, an HMAC toggle (set global-protect enable-auth-override-cookie-hmac yes) that customers can stage during mixed-version upgrades. Users need to re-authenticate once after the upgrade even with a previously valid cookie present, a one-time cost for closing the gap. Without upgrading, the two real workarounds are generating a dedicated certificate used exclusively for authentication override cookies, never shared with anything else, or disabling authentication override entirely.

One methodology note worth flagging: Palo Alto’s advisory carries a static CVSS Base Score of 7.8, but a “Suggested Urgency” of HIGHEST, and their FAQ explains why directly: the overall severity is tied to a dynamic Threat Score that moves with real-world proof-of-concept releases and observed exploitation, layered on top of the fixed base metrics. It’s a genuinely different scoring philosophy from a single static CVSSv3 number, and one to watch for on any future Palo Alto advisory where the base score looks lower than the actual urgency.

From forged cookie to Qilin ransomware

Palo Alto added CVE-2026-0257 to CISA’s KEV catalog on May 29, 2026. Unit 42’s own threat brief, published June 9, described “limited exploit attempts on unpatched devices” and published real indicators: nine attacker IP addresses, suspicious host identifiers including literally placeholder-looking values like aa:bb:cc:dd:ee:ff and hostnames like DESKTOP-GP01, and hardcoded proof-of-concept client configuration fields such as endpoint_os_version: Microsoft Windows 10 Pro 64-bit. As of that report, Unit 42 said plainly that only a small portion of the probed devices ever actually established a VPN session, and no post-access lateral movement had been identified yet.

Arctic Wolf’s own incident response work, published a month later as “Cookie Crumbles” on July 20, tells the rest of the story for at least some of those sessions. Arctic Wolf investigated multiple distinct June 2026 intrusions where CVE-2026-0257 was the confirmed initial access vector, and several of them went all the way to Qilin ransomware, a double-extortion ransomware-as-a-service operation active since 2022. This isn’t a contradiction of Unit 42’s snapshot, just a different vantage point a month later: broad opportunistic scanning produced a lot of noise that never went anywhere, and a smaller number of intrusions that did get through went the distance.

The post-exploitation pattern Arctic Wolf documented is worth knowing at a defensive level, without turning it into a how-to. Once inside, the actors dumped LSASS process memory via rundll32.exe and comsvcs.dll, extracted the full Active Directory database with ntdsutil’s Install From Media method, and moved laterally with PsExec over Windows administrative shares, all techniques this site has covered in detail across the Impacket, Pivoting and Tunneling, and BloodHound series. Ransomware payloads were consistently staged at C:\PerfLogs\, a directory that exists by default on Windows, is rarely monitored by file-integrity tooling, and is often writable without elevated privileges. Before detonating, several intrusions ran a PowerShell routine that enumerates and clears every Windows event log channel with a recorded entry, not just Security or System, specifically to remove the peripheral logs an investigator might otherwise lean on. Several sessions self-identified with the hostname kali, consistent with Kali Linux as the attack platform. Data theft, where it happened, went out over Rclone to MEGA’s cloud storage.

The same failure, from two completely different directions

Put side by side, these two incidents make an argument this site keeps returning to: a VPN gateway concentrates enough trust that a credential-hygiene failure and a genuine code defect end up looking identical from the business-impact side. Full network access, no legitimate credentials required, in both cases. But they demand opposite responses. FortiBleed has nothing to patch. Every fix is operational: rotate credentials, enforce MFA on every administrative and remote-access account, get management interfaces off the public internet regardless of vendor, and actually force the PBKDF2 migration to complete rather than assuming an upgrade did it silently. CVE-2026-0257 has a real fix that closes the hole completely once applied, plus a genuinely useful general lesson for anyone running certificate-backed authentication of any kind: a certificate scoped to one trust purpose should never quietly end up serving a second one without its own validation.

If you administer either platform, the practical list is short. On Fortinet gear, check whether any administrator account has gone untouched since a FortiOS upgrade, and if so, force a login or a manual password reset to complete the PBKDF2 migration, then enable login-lockout-upon-weaker-encryption to purge the legacy hash for good. On PAN-OS, check whether GlobalProtect’s authentication override cookie shares a certificate with the portal or gateway’s own HTTPS service, and if it does, split them or turn the feature off until you can patch. And on both platforms, and every other perimeter device you run: get the event logs off the box and into a central store you control, because clearing local logs before deploying ransomware is now standard tradecraft, not an edge case.