CVE-2024-52965: Fortinet FortiProxy Auth Bypass Vulnerability

CVE-2024-52965 Overview

CVE-2024-52965 is a missing critical step in authentication vulnerability [CWE-304] affecting Fortinet FortiOS and FortiProxy. The flaw permits an API user authenticating with an API key plus a Public Key Infrastructure (PKI) user certificate to log in even when the certificate is invalid. This defeats a core assumption of certificate-based authentication and reduces the login process to a single-factor check against the API key.

The vulnerability affects widely deployed network security appliances used at the perimeter of enterprise environments. Fortinet published advisory FG-IR-24-511 covering affected releases and fixed versions.

Critical Impact
An attacker holding a valid API key can authenticate using an expired, revoked, or otherwise invalid PKI certificate, bypassing a control intended to enforce strong mutual authentication.

Affected Products

Fortinet FortiOS 7.6.0 through 7.6.1, 7.4.0 through 7.4.5, 7.2.0 through 7.2.10, and versions before 7.0.16
Fortinet FortiProxy 7.6.0 through 7.6.1, 7.4.0 through 7.4.8, 7.2.0 through 7.2.13, and versions before 7.0.20
API accounts configured with api-key plus PKI user certificate authentication

Discovery Timeline

2025-07-08 - CVE-2024-52965 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-52965

Vulnerability Analysis

The vulnerability is a certificate validation bypass in the REST API authentication path of FortiOS and FortiProxy. When an API account is configured to require both an API key and a PKI user certificate, the authentication handler accepts the login even if the presented certificate fails validation. The certificate check is effectively skipped or its result is not enforced.

Exploitation requires the attacker to already hold high-privilege credentials, specifically a valid API key for an existing API user. The impact is not remote code execution against an unauthenticated attacker. Instead, it degrades a control that administrators explicitly deploy to raise the bar against key theft, insider misuse, and lateral movement.

Because administrators layer PKI user certificates on top of API keys to defend against exactly this scenario — a leaked or exfiltrated API key — the flaw removes a compensating control. A revoked certificate belonging to a terminated employee, or an expired certificate that should no longer be trusted, will still succeed.

Root Cause

The root cause is a missing critical step in authentication [CWE-304]. The authentication routine validates the API key but does not enforce the outcome of the PKI certificate validation. Fortinet's advisory FG-IR-24-511 documents the flaw and the fixed builds.

Attack Vector

The attack vector is network-based against the FortiOS or FortiProxy management API. An attacker with a valid API key and any certificate (expired, revoked, self-signed, or otherwise untrusted) can complete the login and obtain the privileges of the associated API user. Successful exploitation yields full read and write access to configuration and management functions available to that API account.

No public proof-of-concept exploit is listed in Exploit-DB, and the vulnerability is not present on the CISA Known Exploited Vulnerabilities catalog. See the Fortinet Security Advisory FG-IR-24-511 for vendor-supplied technical details.

Detection Methods for CVE-2024-52965

Indicators of Compromise

Successful API authentications from API users configured with PKI certificate requirements where the presented certificate is expired, revoked, or issued by an untrusted certificate authority (CA)
API sessions originating from source IP addresses that do not match the expected administrative network ranges for a given API account
Configuration changes, policy edits, or firmware operations performed by API users outside of normal change windows

Detection Strategies

Correlate FortiOS and FortiProxy authentication events (event=auth, API login subtypes) with the certificate serial number and validity state to identify logins accepted despite failed certificate checks
Baseline each API user's typical source IPs, request patterns, and user-agents, then alert on deviations
Review recent additions or modifications to API user accounts and their attached certificates for suspicious activity

Monitoring Recommendations

Forward FortiOS and FortiProxy syslog to a centralized analytics platform and retain administrative and API events for at least 90 days
Enable alerting on API-driven configuration changes, especially those affecting firewall policies, VPN, and administrator accounts
Track certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP) status for every certificate mapped to an API user, and alert when a revoked certificate is used for any login attempt

How to Mitigate CVE-2024-52965

Immediate Actions Required

Upgrade FortiOS to 7.6.2 or later, 7.4.6 or later, 7.2.11 or later, or 7.0.16 or later as applicable
Upgrade FortiProxy to 7.6.2 or later, 7.4.9 or later, 7.2.14 or later, or 7.0.20 or later as applicable
Rotate all API keys for accounts that use PKI user certificate authentication, particularly those tied to certificates that are expired or revoked
Audit API user accounts and remove any that are not actively required

Patch Information

Fortinet has released fixed builds documented in advisory FG-IR-24-511. Apply the vendor-recommended upgrade path for each affected branch. After patching, verify that authentication with an invalid certificate is rejected in a controlled test.

Workarounds

Restrict management and API access to a dedicated administrative network using trusthost entries on each API administrator account
Place the FortiOS or FortiProxy management interface behind a jump host or VPN and block API access from the internet
Temporarily disable API accounts that combine api-key and PKI certificate authentication until the patch is applied

bash

# Configuration example: restrict API admin access by source (trusthosts)
config system api-user
    edit "automation-user"
        set accprofile "super_admin"
        set vdom "root"
        config trusthost
            edit 1
                set ipv4-trusthost 10.10.20.0 255.255.255.0
            next
        end
    next
end