MediaTek WLAN Driver CVE-2025-20724

Exploitation requires the attacker to already have local, low-privileged access to a device running the affected MediaTek wlan AP (access point) driver - as shipped in the MediaTek Software Development Kit and OpenWrt 19.07.0/21.02.0 builds - and to reach the specific driver code path containing the faulty bounds check. Limiting factors: the attack vector is local only (AV:L, no remote/network reach), it requires existing privileges (PR:L), and impact is confined to information disclosure (read-only) - there is no integrity or availability effect and no code execution. No special non-default configuration is named in the description, but the device must be running the vulnerable Wi-Fi AP driver.

This is a genuine but low-urgency issue. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5 MEDIUM) describes a locally-exploitable out-of-bounds read requiring low-level privileges (PR:L) and no user interaction, yielding high confidentiality impact but zero integrity or availability impact - consistent with the description's 'local information disclosure with User execution privileges needed.' All exploitation signals point away from priority status: EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, and no public exploit code was identified. No SSVC decision data was supplied. The signals are internally consistent - a local-only, authenticated, read-only memory disclosure in a Wi-Fi driver is exactly the kind of high-CVSS-component-but-low-real-world-risk finding that should be patched in routine maintenance rather than escalated. The one caveat: it was reported by MediaTek itself (security@mediatek.com) and the only reference is a vendor bulletin, so independent corroboration of affected versions and patch details is limited.

A local attacker who already has low-privileged code execution on an affected MediaTek/OpenWrt-based access point invokes the vulnerable wlan AP driver path with crafted input that defeats an incorrect bounds check, causing an out-of-bounds read. The leaked adjacent kernel/driver memory could disclose sensitive data such as pointers or credentials useful for further escalation. No public proof-of-concept exists, and the local attack vector plus required privileges make this a post-compromise aid rather than an initial access vector.