Open-source RADIUS used for 802.1X on the transit-authority WLAN has a published CVE. How should vulnerability tracking treat that system?
Select an answer to reveal the explanation.
Short Explanation
802.1X lives or dies on RADIUS. A hole in the city's AAA stack is a WLAN hole even if the box has no antennas—keep RADIUS in the vulnerability watch list.
Full Explanation
Open-source RADIUS used for 802.1X on the transit-authority WLAN with a published CVE must be included in WLAN vulnerability monitoring scope. AAA/RADIUS and related support systems are integral to WLAN security: compromise can yield credentials, bypass authentication, disrupt accounting, or take down transit operations tablets and staff access across yards and stations. Ignoring AAA CVEs because they are not radios incorrectly equates WLAN security solely with RF hardware and misses the control plane that decides who joins. Tracking the CVE only if the RADIUS server sits in the same rack as an AP invents an irrelevant physical colocation rule that has no bearing on exploitability. Replacing vulnerability tracking with a larger guest splash-page image confuses UX branding with security monitoring and leaves the authentication path unpatched. Transit authorities should treat RADIUS hosts, identity stores, and certificate services as in-scope WLAN security dependencies alongside APs and controllers, with the same intake, triage, and patch discipline. Exam caveat: CWSP vulnerability scope for WLAN includes authentication infrastructure, not only access points and controllers. Operational check: add RADIUS hosts and versions to the WLAN vulnerability inventory, apply the fixed release or compensating network controls, verify 802.1X still succeeds for transit operations SSIDs after patching, confirm accounting and certificate checks remain healthy, and ensure RADIUS logs continue to reach central monitoring.