A CVE for a city hall AP requires physical console access to exploit. After recording the CVE, how should impact judgment differ from a remote wireless exploit?
Select an answer to reveal the explanation.
Short Explanation
Still log the CVE—but a bug that needs someone at the serial port is not the same fire drill as a remote wireless exploit. Preconditions change how hard you stomp on the city's risk pedal.
Full Explanation
When a CVE for a city hall AP requires physical console access to exploit, impact judgment after recording the CVE should weigh those physical-access preconditions differently from a remote wireless exploit. Both belong in the tracker, but operational urgency, blast radius, and required compensating controls differ when an attacker must already reach a console versus attacking over the air or from a routable management network. Treating every CVE as identical in operational impact regardless of exploit preconditions flattens risk analysis. Deleting the CVE from tracking because physical access supposedly means zero risk forever ignores insider and physical-security failures common in civic buildings. Immediately shutting down all outdoor APs citywide based solely on a console-access CVE is disproportionate if outdoor units are not equivalently exposed. Record the issue, then rate it with preconditions in mind. Exam caveat: CVSS and similar scores may already reflect attack vector; local risk rating should still incorporate civic physical-security context and management-plane reachability. Operational check: tag the CVE with "physical console precondition," verify console and local admin controls on city hall APs, prioritize remote/wireless RCEs ahead of it unless physical access controls are weak, and schedule the firmware fix within a risk-based window.