Fortinet Patches CVE-2026-84393: Certificate Validation Flaw in FortiOS/FortiProxy ZTNA

# security# cybersecurity# networking# devops
Fortinet Patches CVE-2026-84393: Certificate Validation Flaw in FortiOS/FortiProxy ZTNAShubham Chaudhary

# Fortinet Patches CVE-2026-84393: A Certificate Validation Flaw in FortiOS/FortiProxy ZTNA If...

 # Fortinet Patches CVE-2026-84393: A Certificate Validation Flaw in FortiOS/FortiProxy ZTNA

If you're running Agentless ZTNA anywhere in your infrastructure, this one's worth a version check today.

The TL;DR

Fortinet disclosed CVE-2026-84393 on September 8, 2026 (advisory FG-IR-26-174) — an improper certificate validation bug (CWE-295) in the Agentless ZTNA portal component of FortiOS and FortiProxy. CVSS score: 7.3. No authentication required to exploit.

What's actually broken

In an Agentless ZTNA architecture, the portal acts as a trust broker. It terminates the user's session, verifies their identity, then opens a separate connection to the backend resource on their behalf.

That second leg — portal to backend — is where this bug lives. The portal is supposed to strictly validate the backend server's certificate before trusting it. It doesn't enforce that match properly, which means an attacker sitting on the network path can present a forged or mismatched certificate and have it accepted without complaint.

No login. No brute force. Just network positioning + a bad cert.

Impact

Fortinet classifies this as information disclosure. A successful MITM position lets an attacker passively observe:

  • Session tokens
  • Authentication data
  • Application content in transit

Affected versions

Product Affected Fixed In
FortiOS 7.6.1–7.6.6 7.6.7+ / 8.0.0
FortiProxy 7.6.2–7.6.6 7.6.7+ / 8.0.0

7.2, 7.4, and 8.0 branches are confirmed unaffected.

Why this matters more than a typical 7.3

Zero Trust's entire value prop is "verify every connection before trusting it, every hop." This flaw sits in the exact validation step ZTNA can't afford to get wrong. It's a trust-boundary failure, not a peripheral feature bug — and ZTNA portals are, by design, often exposed to less-trusted or public network segments.

No evidence of active exploitation yet. That status is fragile for unauthenticated vulns once they hit public advisories.

Detection notes for SOC/infra teams

This is a passive weakness, not an active exploit with a distinct payload — so there's no clean log signature. Worth watching instead:

  • TLS certificate mismatches on ZTNA-brokered backend connections
  • Unusual latency/routing on ZTNA sessions
  • Session token reuse from unexpected source IPs

Full attack-scenario walkthrough, detection deep-dive, and hardening checklist here: https://www.xpert4cyber.com/2026/09/fortios-fortiproxy-ztna-vulnerability-cve-2026-84393.html