CVE-2025-25253: Fortinet FortiProxy Info Disclosure Flaw

CVE-2025-25253 Overview

CVE-2025-25253 is an Improper Validation of Certificate with Host Mismatch vulnerability [CWE-297] affecting Fortinet FortiProxy and FortiOS Zero Trust Network Access (ZTNA) proxy components. The ZTNA proxy fails to validate that the certificate presented during a TLS handshake matches the expected hostname. An unauthenticated attacker positioned on an adjacent network can intercept and tamper with connections to the ZTNA proxy. This breaks the trust model that ZTNA deployments rely on to broker secure access to internal applications.

Critical Impact
A man-in-the-middle attacker on an adjacent network can intercept and modify ZTNA proxy traffic, compromising the confidentiality and integrity of authenticated user sessions.

Affected Products

Fortinet FortiProxy versions 7.6.1 and below, 7.4.8 and below, all 7.2.x, all 7.0.x
Fortinet FortiOS versions 7.6.2 and below, 7.4.8 and below, all 7.2.x, all 7.0.x
ZTNA proxy component in the above releases

Discovery Timeline

2025-10-14 - CVE-2025-25253 published to NVD
2025-10-15 - Last updated in NVD database

Technical Details for CVE-2025-25253

Vulnerability Analysis

The vulnerability stems from improper certificate validation in the ZTNA proxy code path within FortiProxy and FortiOS. When the ZTNA proxy establishes a TLS connection, it does not properly verify that the certificate's Subject or Subject Alternative Name (SAN) matches the intended host. This violates a core requirement of TLS authentication defined in RFC 6125.

An attacker who can present a valid certificate for any host, or who controls a certificate the proxy trusts, can impersonate the legitimate endpoint. The proxy accepts the connection without flagging the hostname mismatch. The result is a successful man-in-the-middle (MITM) interception of ZTNA traffic.

The flaw affects confidentiality, integrity, and availability. An attacker can read tokens, session cookies, and application data flowing through the proxy. The attacker can also inject or modify content in transit. Because ZTNA is the access broker for backend applications, compromising the proxy connection can extend to downstream resources.

Root Cause

The ZTNA proxy performs TLS handshake validation but omits or incorrectly implements hostname verification. CWE-297 describes this exact class of defect: a certificate may be cryptographically valid yet bound to a different host than the one the client intended to reach. Without strict host matching, certificate-based authentication provides no assurance of endpoint identity.

Attack Vector

Exploitation requires adjacent network access, meaning the attacker must be on the same logical network segment as the ZTNA proxy or its clients. Common positions include shared Wi-Fi, compromised infrastructure between the client and proxy, or ARP/DNS spoofing within a broadcast domain. The attacker intercepts the TLS handshake, presents a certificate the proxy will accept, and proxies traffic between the legitimate endpoints while observing or modifying it. No prior authentication or user interaction is required.

No public proof-of-concept code is currently available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2025-25253

Indicators of Compromise

Unexpected TLS handshakes to ZTNA proxy endpoints originating from non-standard internal hosts
Certificate fingerprints in proxy logs that do not match the issued Fortinet ZTNA infrastructure certificates
ARP table anomalies or duplicate MAC addresses on segments hosting FortiProxy or FortiOS appliances
Unusual latency or session resets on ZTNA-brokered application connections

Detection Strategies

Inspect FortiOS and FortiProxy logs for TLS handshake errors, repeated re-authentications, or session anomalies tied to the ZTNA proxy service
Compare observed server certificates against an authoritative inventory of certificates issued to ZTNA infrastructure
Enable network-based TLS monitoring to flag certificates with hostnames that do not match the destination FQDN
Correlate adjacent-network indicators such as ARP spoofing alerts with ZTNA session events

Monitoring Recommendations

Forward FortiProxy and FortiOS logs to a centralized analytics platform and alert on certificate validation failures or downgrade events
Monitor management VLANs and ZTNA client subnets for layer-2 attacks that enable MITM positioning
Track ZTNA session counts, source IPs, and authentication outcomes for deviations from baseline

How to Mitigate CVE-2025-25253

Immediate Actions Required

Identify all FortiProxy and FortiOS appliances running affected versions and inventory their ZTNA proxy usage
Apply the fixed releases referenced in the Fortinet Security Advisory FG-IR-24-457 as soon as a maintenance window allows
Restrict network paths between ZTNA clients and the proxy to trusted segments until patches are deployed
Rotate any credentials, tokens, or session keys that may have transited an unpatched ZTNA proxy

Patch Information

Fortinet has published remediation guidance in advisory FG-IR-24-457. Administrators should upgrade FortiProxy and FortiOS to releases above the affected version bands documented in the advisory. Refer to the Fortinet PSIRT advisory for the exact target versions and upgrade paths for each branch.

Workarounds

Disable the ZTNA proxy feature on affected appliances if it is not in active use
Enforce certificate pinning or strict CA constraints at upstream network controls where supported
Place ZTNA proxy interfaces on dedicated, access-controlled VLANs to limit adjacent-network exposure
Require additional transport-layer protection such as IPsec between ZTNA clients and the proxy until patched

bash

# Verify FortiOS or FortiProxy version and identify ZTNA proxy configuration
get system status
show firewall vip | grep -i ztna
show ztna traffic-forward-proxy
# After upgrade, confirm the build matches the fixed version listed in FG-IR-24-457