On December 12, 2022, Fortinet published an advisory for CVE-2022-42475, a heap-based buffer overflow in the SSL-VPN component of FortiOS. The vulnerability had a CVSS score of 9.3, and Fortinet acknowledged it was being "exploited in the wild." What the initial advisory didn't fully convey was the sophistication of the attacks already underway. Threat actors, later attributed to a China-nexus group, had been exploiting this vulnerability for weeks before public disclosure, deploying custom implants designed to survive firmware upgrades.
The Vulnerability
The flaw existed in FortiOS's SSL-VPN daemon (sslvpnd). A specially crafted request could trigger a heap-based buffer overflow, allowing an unauthenticated remote attacker to execute arbitrary code on the FortiGate appliance. No credentials required. No user interaction needed.
Affected versions spanned FortiOS 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.10, and 6.2.0 through 6.2.11, along with FortiOS-6K7K versions. Given FortiGate's market share in enterprise networking, the exposure was massive.
VPN appliances occupy a uniquely dangerous position in network architecture. They sit at the network perimeter, are accessible from the internet by design, handle authentication for remote access, and have deep visibility into internal network traffic. Compromising a VPN appliance doesn't just give an attacker a foothold. It gives them a privileged vantage point that's difficult to monitor and detect.
Exploitation in the Wild
Mandiant and Fortinet's own PSIRT team documented the pre-disclosure exploitation campaign in detail. The attackers demonstrated an unusually deep understanding of FortiOS internals.
Custom implants. The threat actor deployed a modified version of the legitimate FortiOS IPS engine binary. This modified binary included a backdoor that communicated with attacker-controlled infrastructure. By masquerading as a legitimate FortiOS component, the implant evaded detection by Fortinet's own integrity verification mechanisms.
Persistence through firmware updates. The attackers modified the firmware upgrade process to ensure their implant survived updates. This is a particularly sophisticated technique that shows the attackers had reverse-engineered Fortinet's update mechanisms.
Log manipulation. The implant actively modified FortiOS log files to remove evidence of exploitation. Defenders reviewing logs on a compromised appliance would see no indication of the breach. Only network-level monitoring of traffic to and from the appliance would reveal the anomaly.
Targeted victim selection. The campaign focused on government entities and critical infrastructure, consistent with espionage motivations rather than financial crime.
Why VPN Appliances Keep Getting Hit
CVE-2022-42475 was not an isolated incident. Fortinet VPN vulnerabilities had been repeatedly exploited in prior years, including CVE-2018-13379 (path traversal for credential theft) and CVE-2020-12812 (authentication bypass). Other VPN vendors fared no better. Pulse Secure's CVE-2019-11510, Citrix's CVE-2019-19781, and SonicWall's multiple vulnerabilities all followed the same pattern.
The reasons are structural:
Closed-source firmware limits security research. Unlike open-source software where the community can identify and report vulnerabilities, VPN appliance firmware is proprietary. Security researchers have to reverse-engineer binaries to find flaws, creating a slower feedback loop between discovery and disclosure.
Legacy codebases accumulate debt. VPN appliances often run on decades-old codebases that predate modern memory-safe programming practices. Heap overflows, stack overflows, and format string vulnerabilities are endemic to C-based network daemons that have been extended and modified over many years.
Patching is slow. Unlike cloud services that can be updated instantly, VPN appliances require planned maintenance windows. Organizations running hundreds of FortiGate devices can't patch them all overnight without risking service disruptions.
Visibility gaps. Most organizations treat VPN appliances as "set and forget" infrastructure. They may not run endpoint detection on the appliance itself, and network monitoring may not inspect traffic patterns from the VPN concentrator.
The Detection Challenge
Detecting exploitation of CVE-2022-42475 was difficult for several reasons. The vulnerability was in a service that legitimately handles TLS connections from the internet, so the exploit traffic blended with normal VPN access patterns. The custom implant mimicked a legitimate FortiOS process, and log manipulation erased evidence on the device itself.
Fortinet eventually released indicators of compromise (IoCs) including specific file paths, process names, and network indicators. But by the time these IoCs were published, sophisticated attackers had likely evolved their tooling.
Organizations that detected the compromise early typically did so through:
- Network traffic analysis showing unexpected outbound connections from the FortiGate appliance
- File integrity monitoring that detected unauthorized modifications to FortiOS binaries
- Anomalous authentication patterns suggesting the VPN appliance was being used as a pivot point
Response and Remediation
Fortinet released patches across all affected version branches. However, simply patching wasn't sufficient for organizations that might have been compromised before the patch. The persistence mechanisms meant that a compromised device could remain backdoored even after updating to a fixed firmware version.
Fortinet's recommended remediation for potentially compromised devices included:
- Updating to the fixed firmware version
- Reviewing logs for IoCs (with the caveat that logs might have been manipulated)
- Checking for unauthorized modifications to system files
- Resetting all credentials that passed through the VPN
- In severe cases, reimaging the device from known-good firmware
For organizations that had been targeted, the response was far more extensive, involving network-wide compromise assessments and credential rotations.
Supply Chain Implications
VPN appliances are themselves supply chain components. Organizations trust them to securely bridge their internal networks with the outside world. When that trust is violated through a firmware-level compromise, the blast radius extends to every system accessible through the VPN.
This creates a supply chain risk that's distinct from software dependency vulnerabilities. You're not just trusting Fortinet's code. You're trusting it to maintain the integrity boundary between your internal network and the internet. A compromised VPN appliance is functionally equivalent to an attacker sitting inside your network perimeter.
How Safeguard.sh Helps
Safeguard.sh helps organizations maintain visibility into their security posture, including the infrastructure components that sit at trust boundaries. Our platform's continuous monitoring capabilities track the software and firmware versions deployed across your environment, flagging known vulnerabilities as soon as advisories are published.
For development teams building applications that rely on VPN infrastructure, Safeguard.sh's SBOM tracking ensures you understand the full chain of trust in your deployment pipeline. When a critical vulnerability like CVE-2022-42475 is disclosed, you can immediately assess which environments are exposed and prioritize remediation based on actual risk rather than guesswork. Policy gates can enforce security baselines that include infrastructure components, not just application code.