See how hostapd compares to other vendors in security performance
In hostapd 2.10 and earlier, the PKEX code remains active even after a successful PKEX association. An attacker that successfully bootstrapped public keys with another entity using PKEX in the past, will be able to subvert a future bootstrapping by passively observing public keys, re-using the encrypting element Qi and subtracting it from the captured message M (X = M - Qi). This will result in the public ephemeral key X; the only element required to subvert the PKEX association.
In hostapd before 2.12, a missing bounds check in AP-mode Wi-Fi 7 (IEEE 802.11be) Multi-Link Operation (MLO) association request processing allows an unauthenticated attacker within wireless range to send a crafted management frame containing a malformed Multi-Link Element or Per-STA Profile subelement. In hostapdprocessmlassocreq() in src/ap/ieee80211eht.c, the received linkid field can be parsed as value 15, but the corresponding links[] storage only has valid entries for lower link IDs (0 through 14). This causes an out-of-bounds write / small memory corruption during association processing before the 4-way handshake. The attack does not require network credentials, prior authentication, or user interaction. The confirmed practical impact is denial of service through hostapd process termination. This affects hostapd v2.11 and newer development snapshots before v2.12 when built with CONFIGIEEE80211BE enabled. The issue is fixed in hostapd v2.12 and the upstream 2026-1 fixes.
A Wi-Fi 7 / IEEE 802.11be MLD parsing issue in hostapd AP mode has been fixed upstream:
https://w1.fi/security/2026-1/missing-ml-parsing-validation.txt
Issue: Missing link ID validation in hostapdprocessmlassocreq() (src/ap/ieee80211eht.c). linkid is masked with 0x000f (values 0-15), but links[] only has valid entries 0..14 (MAXNUMMLDLINKS=15). A crafted Per-STA Profile with linkid=15 can write past the end of links[] during association processing.
This is reachable before the 4-way handshake; no credentials are required. An attacker within radio range can trigger it with a crafted association request.
Affected: hostapd v2.11 and newer repository snapshots before v2.12, built with CONFIGIEEE80211BE and running Wi-Fi 7 / MLD AP configuration.
Impact: hostapd process termination / denial of service, and small memory corruption, per the upstream advisory.
Fix: https://git.w1.fi/cgit/hostap/commit/?id=46dd5a4ffc9bcf44cf8fc45120b3e1e5ec922187
Additional related fixes are listed in the upstream advisory.
Mitigation: Update to hostapd v2.12 or newer once available, or apply the upstream fixes and rebuild.
CVE status: CVE assignment requested from MITRE under CAN-2026-2032030
Credit: The upstream advisory credits Sebastián Alba Vives, with independent discovery and report by Abhinav Agarwal.
Timeline: 2026-05-14 reported to upstream 2026-06-05 upstream published security advisory
-- Abhinav Agarwal
hostapd fails to process crafted RADIUS packets properly. When hostapd authenticates wi-fi devices with RADIUS authentication, an attacker in the position between the hostapd and the RADIUS server may inject crafted RADIUS packets and force RADIUS authentications to fail.
Hostapd 0.3.7-2 allows remote attackers to cause a denial of service (segmentation fault) via an unspecified value in the keydatalength field of an EAPoL frame.