A utility billing API in the city’s cloud is breached after scanners find a known flaw in an outdated third-party library that patching tickets had delayed for months. Which attack path does this describe?
Select an answer to reveal the explanation.
Short Explanation
Old libraries with published holes are candy for attackers—especially when the change ticket sat in someone’s queue for months. The breach here is classic vulnerability exploitation tied to human delay, not sci-fi crypto or stolen racks. Patch cadence matters as much as fancy firewalls.
Full Explanation
A utility billing API breached after scanners find a known flaw in an outdated third-party library that patching tickets delayed for months describes exploitation of a vulnerability caused by outdated software and delayed human remediation. Once CVE details and public exploits circulate, unpatched municipal dependencies become a predictable attacker path tied to process lag as much as to technology. Exclusive quantum cryptanalysis against TLS certificates on the load balancer is not the scenario described and is not how routine cloud application breaches present on exams. Physical theft of a hypervisor host from a provider cage is outside the customer's typical visible attack path and does not match a library CVE finding. DNS cache poisoning that only affects on-premises print servers is unrelated to the cloud API's third-party dependency. Exam caveat: vulnerability management includes discovery (SCA/image scan) and time-bound remediation SLAs—finding without fixing still fails the control objective for Internet-facing civic services. Operational check: map the CVE to the billing image or package, patch or rebuild and redeploy, confirm scanners clear the finding, review why the change ticket aged for months, and tighten patch SLAs and ownership for public municipal APIs in the vulnerability playbook.