Hostapd and wpa_supplicant vulnerabilities in embedded firmware: identify, prioritise and fix

Because on Linux-based Wi-Fi products they are the code that handles every authentication frame. hostapd is the access point side: the hostapd project page describes it as a "user space daemon for access point and authentication servers" that implements the WPA/WPA2/WPA3 and EAP authenticators, a RADIUS client and an EAP server. wpa_supplicant is the client side, and it runs on Wi-Fi cameras, smart plugs, gateways in client mode, Android devices and routers acting as repeaters. Both come from the same hostap source tree and share the SAE, EAP and key-management code.

That position makes their bugs reachable over the air. Many of the issues below need nothing more than an attacker "in radio range", the phrase the upstream advisories use repeatedly, and no password. On OpenWrt and the vendor SDKs derived from it, both programs often ship as one combined binary: the OpenWrt hostapd package builds wpad variants described as an "Authenticator and Supplicant" in one package, so a router image can carry the client-side CVEs too.

Upstream publishes its own advisories at w1.fi/security, each with the affected versions, the build option and runtime setting that make it reachable, and the fixing commits. The table maps the main CVEs to those conditions. "AP" means hostapd (or wpa_supplicant in AP mode), "STA" means a wpa_supplicant client.

KRACK (2017). The w1.fi 2017-1 advisory separates the two sides clearly. On hostapd, the TK reinstallation (CVE-2017-13082) applies only "where hostapd is used to operate an RSN/WPA2 network with FT (Fast BSS Transition from IEEE 802.11r) enabled", plus a related ANonce reuse during PTK rekeying that affects all hostapd versions. On wpa_supplicant, all versions were affected, and older ones worse: v2.4 and v2.5 "end up configuring an all-zero TK", which lets an attacker decrypt the client's frames. The researcher's KRACK site draws the same line for products: routers and access points "are only vulnerable to our attack if they support the Fast BSS Transition (FT) handshake, or if they support client (repeater) functionality." For IoT clients, every KRACK client CVE applies. CVE-2017-13084 (PeerKey) is the exception; upstream calls it "not applicable in practice."

Dragonblood (2019). Mathy Vanhoef and Eyal Ronen's Dragonblood research found side channels and implementation bugs in the Dragonfly handshake behind SAE (WPA3-Personal) and EAP-pwd. In hostapd and wpa_supplicant this produced several advisories: the SAE side-channel advisory states that the cache attack "requires the attacker to be able to run a program on the target device", which it notes "is not commonly the case on access points, so the most likely target for this would be a client device." The SAE confirm crash (CVE-2019-9496) is different: any attacker in radio range of a hostapd SAE network could terminate the process. The EAP-pwd commit-validation bugs depend on the crypto library; the 2019-4 advisory lists OpenSSL 1.0.2 or older, LibreSSL and wolfSSL as vulnerable to the invalid scalar/element attack, and OpenSSL 1.1.0 or newer as not vulnerable. The researchers later confirmed a Brainpool-curve timing leak (CVE-2019-13377) against the then-current hostapd release, and a further incomplete fix led to CVE-2022-23303 and -23304, fixed in 2.10.

WPS, P2P and EAP. Both WPS UPnP issues need UPnP compiled in and enabled: the 2020-1 advisory lists "CONFIG_WPS_UPNP=y" in the build and upnp_iface in the runtime configuration. The Wi-Fi Direct heap overflow in the 2020-2 advisory affects wpa_supplicant v1.0 to v2.9 with CONFIG_P2P and can lead to "potentially arbitrary code execution" from radio range. For enterprise clients, CVE-2023-52160 lets a rogue network skip PEAP Phase 2 when the client does not verify the server certificate; the wpa_supplicant 2.11 changelog answers it by making PEAP "require Phase 2 authentication by default (phase2_auth=1)".

The 2026 advisories. Five were published between June and August 2026. The 2026-1 advisory covers Wi-Fi 7 multi-link parsing in "hostapd v2.11 and newer snapshots ... before v2.12 with CONFIG_IEEE80211BE", reachable "without needing authentication or user action". The mesh AMPE advisory describes a write of "up to 239 bytes of attacker controlled data after the end of an allocated heap buffer", though only after a successful SAE mesh login. The RADIUS advisory 2026-5 applies to all hostapd versions with RADIUS configured. Advisories 2026-3, 2026-4 and 2026-5 list no CVE ID, so a scanner that matches by CVE alone will miss them.

Rank by reachability first: is the feature compiled in, is it enabled, and is the product an access point, a client or both? Then look at exploitation data, and use the CVSS base score only to break ties. Data as of 2026-11-10 (CISA KEV catalog version 2026.11.10, FIRST EPSS scores dated 2026-11-10):

None of the CVEs above was in CISA's KEV catalog in its 2026.11.10 release. Two lessons stand out. First, EPSS does not know your build: CVE-2020-12695 scores highest, yet hostapd's defconfig leaves WPS UPnP off. Second, CVSS base scores can mislead in the other direction. NVD scores CVE-2022-23303 at 9.8, while the 2022-1 advisory says it needs an attacker "able to run unprivileged code on the same processor", which a locked-down access point rarely allows. Our KEV and EPSS prioritisation guide covers how the two signals combine, and CVSS v4 vs v3.1 explains why base scores need environmental context.

Device role changes the ranking. A home router without FT, WPS UPnP or repeater mode is outside most of the KRACK set, while a battery-powered sensor running wpa_supplicant 2.6 is exposed to all of it and may never get the update that closes it.

Upgrade or patch, switch off features the product does not use, harden the configuration, then rebuild and re-scan.

Upgrade or patch. Version 2.12, released on 2026-08-07 according to the w1.fi release directory, contains the fixes for every advisory up to 2026-4; the wpa_supplicant ChangeLog lists the PMKSA caching, SAE and mesh AMPE fixes under v2.12. Advisory 2026-5 was published on 2026-08-17, after that release, and the newest release in the w1.fi directory on 2026-11-11 is still 2.12, so hostapd builds that use RADIUS also need commit aa02cfa569477f67f3915c8b9a83d1a7ca93693d. When a full upgrade is too large for one release cycle, each w1.fi advisory lists its fixing commits, and many ship patches rebased onto the release in use (2017-1 has a set for v2.6, 2026-1 a set for v2.11).

Disable unused features. Each row removes whole CVE groups from reach:

Unlike the rows above, SAE is a security feature to keep. Where it stays on, patch it, leave the weak MODP groups (1, 2, 5, 22, 23, 24) and the Brainpool groups (28-30) out of sae_groups, as the 2019-1 and 2019-6 advisories recommend, and require strong passwords; Dragonblood's transition-mode downgrade is a protocol design issue that a code patch does not remove.

Harden the configuration. On enterprise clients, set ca_cert and a server domain match so PEAP and TTLS verify the network, and keep phase2_auth=1. On access points, enable PMF (ieee80211w) where clients allow it. For EAP-pwd on an older base, link against OpenSSL 1.1.0 or newer, which the 2019-4 advisory lists as not vulnerable to the invalid-point attack; our OpenSSL vulnerabilities guide covers keeping that library current.

Rebuild, re-scan, release. Regenerate the firmware SBOM, compare it with the previous release, and confirm the new version, snapshot or patch level is what actually shipped; our firmware diffing and patch analysis guide covers the binary-level comparison. Then publish the result with affected versions, fixed version and the CVE and w1.fi advisory IDs. Where a build option rules a CVE out, record that in a VEX statement; our CSAF and VEX for device makers guide shows the format. The same router image usually ships dnsmasq and BusyBox too; see our guides on dnsmasq vulnerabilities and BusyBox vulnerabilities.

SoftWSP's automated scan unpacks a firmware image, catalogs the software components in the extracted file system, and identifies hostapd and wpa_supplicant by name and version. It then matches those versions against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which hostapd and wpa_supplicant CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: whether WPS UPnP, SAE, EAP-pwd, P2P or mesh are compiled in and switched on, whether the device acts as an access point, a client or both, and whether a vendor backport already closes a version-matched CVE. Advisories without a CVE ID, such as w1.fi 2026-3 to 2026-5, are also checked in that review, because version-to-CVE matching does not see them.

For where Wi-Fi stack review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the w1.fi hostapd and wpa_supplicant security advisories, ChangeLogs, defconfig files and source, the KRACK and Dragonblood research sites, the Debian Security Tracker, OpenWrt's hostapd package Makefile, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-10, all read directly on 2026-11-11.