FortiOS CAPWAP server two vulnerabilities

Impact Detail

CAPWAP stands for Control And Provisioning of Wireless Access Points; it is a standard protocol that enables an Access Controller (AC) to manage a collection of wireless Access Points (AP).
Fortinet FortiOS embeds a CAPWAP server, which allows FortiGates to act as an Access Controller. This CAPWAP server is subject to two vulnerabilities, mitigated by various factors.
1. A DoS condition: The server only accepts to control a limited number of concurrent APs. Sending enough fake "ClientHello" new AP requests to the serverwill prevent the addition of new legitimate APs.
2. An XSS vulnerability: Sending a CAPWAP join message to the server, with javascript embedded in the AP name, results in this javascript being executedwhen a user attempts to manage the access points from the FortiGate's administration GUI.
Mitigation factors:
CAPWAP is not enabled by default on FortiOS, hence the vulnerabilities only concern users who actively use it to manage a collection of Access Points.
For the latter, the mitigation factors then apply:
Regarding the DoS condition: The attacker must have network access to the CAPWAP server. This usually implies having access to the physical, wirednetwork linking APs to the server (as the FortiGate is meant to serve as a gateway between the isolated APs network and other networks). Beyond this, asuccessful DoS attack would prevent addition of new APs, but would not disrupt the CAPWAP service for APs that have already been configured.
Regarding the XSS vulnerability: The attacker must have network access to the CAPWAP server (see DoS condition above), and authenticate as a legitimate APduring the DTLS handshake (CAPWAP join requests happen after the DTLS channel is established), which requires being in possession of an X.509 Certificate (and its associated private key) from an actual FortiAP.
According to, there would be a DTLS Man-in-the-Middle vulnerability, between the CAPWAP server and the APs, due to the fact "TheCAPWAP DTLS protocol was found to use a universal Fortinet_Factory certificate and private key, the certificate authority for which is static across all Fortinet devices".
This is untrue: The Fortinet_Factory certificate is unique to each device, and signed by Fortinet's root CA (Fortinet_ca). An attacker cannot therefore stagea MitM attack using the certificate and private key published by (except if the attack targets the FortiGate they used for their test).

Affected Products

FortiOS with CAPWAP enabled:
5.2.2 and below
5.0.11 and below


Upgrade FortiOS to the following versions:
Make sure CAPWAP is disabled if not needed:
show system interface
Must not display "capwap" in the "allowaccess" entry. If it is present, the interface must be re-configured without capwap. For instance:
config system interface
    edit "port1"
        set allowaccess ssh https
If CAPWAP is needed, the XSS vulnerability have been fixed starting with FortiOS 5.2.3.
Otherwise the following workarounds apply:
Regarding the DoS condition and the XSS vulnerability: Use a local-in policy to restrict access to the CAPWAP server to IP addresses of legitimate APs. Forinstance, to authorize only the subnet:
config firewall address
    edit "lan_subnet"
    set subnet
config firewall service custom
    edit "capwap_udp"
        set udp-portrange 5246
config firewall local-in-policy
    edit 0
        set intf "any"
        set srcaddr "lan_subnet"
        set dstaddr "all"
        set service "capwap_udp"
        set schedule "always"
Regarding the XSS vulnerability, to prevent a successful attacker from hijacking your user session in the GUI, make sure to restrict your Trusted Hosts to your IP address only:
Single-vdom configuration: System->Admin->Administrators
Multi-vdoms configuration: Global->Admin->Administrators