Yes. CISA added CVE-2018-0147 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A vulnerability in Java deserialization used by Cisco Secure Access Control System (ACS) could allow an unauthenticated, remote attacker to execute arbitrary commands on an affected device.
What makes CVE-2018-0147 a real exploitation concern?
The question is not whether the flaw exists, but whether defenders should treat it as active exposure. For a KEV-listed issue like this, the practical answer is to assume internet-facing or otherwise reachable Cisco ACS systems may already be targeted, and that exposure persists until the vulnerable service is removed, isolated, mitigated, or fixed.
That matters because Java deserialization flaws are not just “theoretical RCE” bugs. They are often exploitable before organisations notice abnormal traffic, and they can support unauthenticated remote command execution when the service is exposed. In other words, the risk is not only compromise, but silent compromise followed by follow-on access.
For confirmed exploitation context, use CISA Known Exploited Vulnerabilities Catalog as the operational signal and CVE Program records for the vulnerability identity itself.
How should teams confirm exposure and judge urgency?
Start by proving whether Cisco secure access control System is still deployed anywhere, including forgotten appliances, lab systems, and HA or standby nodes. Then determine whether the service is reachable from untrusted networks or from internal segments that are broadly accessible. If the asset cannot be confidently inventoried, treat that as unresolved exposure rather than absence of risk.
Urgency should be driven by exposure, not by comfort with the product age. KEV inclusion means the vulnerability has moved beyond generic patch tracking and into active exploitation territory, so the operational question becomes whether the system can still be reached, exploited, or used as an entry point for deeper access.
Validate current exposure against the vendor advisory, then compare that status with the KEV listing and any compensating controls already in place. If the system is externally exposed, assume higher priority than a similar flaw on an isolated management subnet.
What to do if patching or removal must wait?
If immediate remediation is blocked, reduce reachable attack surface first. That usually means taking the service off the public internet, restricting administrative paths, segmenting it from sensitive zones, and disabling any exposure that is not required for business operation. For legacy access systems, compensating controls are only useful if they actually narrow who can reach the vulnerable endpoint.
Use NIST Cybersecurity Framework 2.0 to frame the response as identify, protect, detect, respond, and recover, and consult CIS Controls v8 for practical hardening, inventory, and monitoring priorities. Where protocol or remote-management exposure is involved, VPN Security Guide is a useful reminder that edge devices should never be left as broad trust chokepoints.
When patching must wait, document the exception, shorten the exception window, and assign an owner who can prove the exposure is still controlled. A delay is acceptable only if the business impact is understood and the containment measures are real, testable, and monitored.
Risk and Threat Considerations
Active exploitation changes the problem from “can this be abused?” to “has this already been abused on our estate or through our perimeter?” Deserialization flaws are especially dangerous because they can be weaponised without valid credentials when the service is reachable, which makes them attractive for opportunistic scanning and rapid follow-on compromise.
Failure mechanism: The vulnerable endpoint accepts crafted serialized data, the deserialization process instantiates attacker-controlled objects or gadget chains, and the attacker converts that execution path into arbitrary command execution on the device.
Impact: Compromise can lead to device takeover, credential theft, pivoting into adjacent systems, and persistent footholds if the appliance is used as a trust anchor or management gateway.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Asset visibility is essential to find lingering Cisco ACS exposure. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Containment and hardening reduce exploitability while patching is pending. | |
| Recommendation — Inventory every ACS instance and remove or isolate any unknown or unmanaged deployment. Harden and segment the service to reduce reachable attack surface before remediation. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | The answer depends on proving where vulnerable ACS systems still exist. |
| PR.PS-01 — Configurations are managed and hardened to reduce cybersecurity risk | Compensating controls and hardening are the main stopgap when patching waits. | |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | KEV-listed exploitation requires monitoring for signs of abuse or pivoting. | |
| Recommendation — Inventory all Cisco ACS systems and confirm their current exposure state. Apply restrictive configuration and segmentation until the vulnerability is remediated. Monitor the affected service and surrounding network for exploitation indicators. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is an actively exploited software flaw requiring remediation discipline. |
| SI-4 — System Monitoring | Post-exploitation detection is needed because exploitation may precede obvious failure. | |
| Recommendation — Remediate the vulnerable ACS software as soon as operationally possible. Monitor for suspicious activity that indicates compromise of the ACS service. | ||
Practitioner Guidance
What to verify: Confirm whether Cisco ACS is still in inventory, whether it is reachable from untrusted networks, and whether any compensating control truly blocks exposure rather than merely reducing noise. If you cannot verify those points quickly, treat the system as high-risk until proven otherwise.
Decision rule: If the instance is exposed and cannot be patched immediately, prioritise isolation, service restriction, and compromise assessment before debating whether exploitation has occurred. If it is already isolated but still present, verify that no stale administrative access paths, credentials, or backup exposures remain.
Common mistake: Teams often focus on the CVE identifier and forget the appliance lifecycle problem. Legacy access systems frequently survive because they are “not in the current project,” which is exactly how exposed infrastructure stays exploitable long after disclosure.
Practitioner takeaway: KEV listing should be treated as an operational trigger, not a reporting note, so the right sequence is exposure check, containment, remediation, and compromise review.
Related resources from NHI Mgmt Group
- CVE-2018-0147 (Cisco Secure Access Control System Java Deserialization)
- Is CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data) being exploited in the wild?
- Is CVE-2021-25337 (Samsung Mobile Devices Improper Access Control) being exploited in the wild?
- Is CVE-2021-25369 (Samsung Mobile Devices Improper Access Control) being exploited in the wild?