Is CVE-2013-4810 (HP Multiple Products Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2013-4810 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. HP ProCurve Manager (PCM), PCM+, Identity Driven Manager (IDM), and Application Lifecycle Management allow remote attackers to execute arbitrary code via a marshalled object to (1) EJBInvokerServlet or (2) JMXInvokerServlet.

How to read KEV status for CVE-2013-4810

CISA KEV listing is the practical signal that matters most here: it means the issue has confirmed active exploitation, so the question is not whether exploitation is possible but whether your environment still exposes the vulnerable HP products. For this CVE, the response should start with inventory, exposure confirmation, and urgency, not with theoretical debate.

Because the direct answer already identifies the affected product family and attack result, the key operational question is whether any installation of HP ProCurve Manager, PCM+, Identity Driven Manager, or Application Lifecycle Management remains reachable and unremediated. If the product is present, treat it as a live exposure until the vendor’s advisory and the KEV catalogue confirm the exact remediation path.

For triage and prioritisation, use the Zero-Day and Exploited Vulnerabilities Guide to align KEV status with emergency response, and use the CISA Known Exploited Vulnerabilities Catalog as the authoritative source for exploitation-driven action timing.

Why this vulnerability was attractive to attackers

The vulnerability is an RCE condition in management software, which makes it especially valuable to attackers because successful exploitation can turn a trusted administrative platform into an entry point. The attack path described in the answer uses a marshalled object against servlet endpoints, which is the kind of server-side code path that can convert a single request into arbitrary execution.

That matters because management and lifecycle tools often sit close to privileged networks, credentials, and configuration data. When exploitation succeeds in that layer, the impact is rarely confined to the original application, and defenders should assume the compromise may enable follow-on access, staging, or lateral movement.

For a deeper treatment of exploit-driven risk prioritisation, the FIRST EPSS model is useful when you need to compare probability of exploitation across many vulnerabilities, while the NIST National Vulnerability Database remains the baseline reference for CVE records and related vulnerability metadata.

What to do if patching or removal is delayed

If immediate removal or patching is not possible, the safest short-term posture is to reduce exposure around the vulnerable service rather than assume partial trust is enough. That means limiting network reachability, removing unnecessary administrative paths, and treating any internet-facing or broadly reachable instance as a higher-priority emergency.

In practical terms, this is a case where containment should be judged by observable reachability, not by confidence in obscurity. If the product cannot be retired quickly, the next best action is to harden access boundaries and monitor for signs that the vulnerable servlet endpoints are being probed or exercised.

The Vulnerability Management Guide is the most relevant internal reference for prioritisation, exceptions, and verification, and it pairs naturally with the vendor advisory because the precise fixed version and supported mitigation steps must come from the original source documentation.

Risk and Threat Considerations

This CVE is high risk because remote code execution in a management product can collapse the normal boundary between administrative tooling and attacker control. If exploitation occurs, the attacker may gain execution on a system that was trusted to manage infrastructure, which can expose credentials, internal configuration, and privileged workflows.

Failure mechanism: A marshalled-object input reaches an unsafe server-side deserialisation path in exposed servlet endpoints, allowing attacker-supplied data to influence program flow and execute code remotely.

Impact: Successful exploitation can lead to full system compromise, persistence, and broader intrusion paths if the affected platform has access to sensitive management functions or adjacent systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritised vulnerability handling central to this CVE.
Recommendation — Prioritise and remediate the affected HP product as an actively exploited vulnerability.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question is about confirming exposure and responding to a known exploited flaw.
	SI-2 — Flaw Remediation	The exploit status makes remediation and exception handling the core control response.
Recommendation — Scan for the affected HP software and track remediation until exposure is removed. Apply flaw remediation procedures to remove or mitigate the vulnerable deployment quickly.
OWASP ASVS	V15 — Secure Coding and Architecture	The attack path involves unsafe server-side processing that reflects architecture and input-handling weaknesses.
Recommendation — Review server-side deserialisation and endpoint exposure patterns for unsafe trust boundaries.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The CVE is an actively exploited remote code execution issue against exposed application services.
Recommendation — Hunt for exploitation attempts against the exposed management interface and servlet endpoints.

Practitioner Guidance

What to prioritise: First confirm whether any HP ProCurve Manager, PCM+, Identity Driven Manager, or Application Lifecycle Management instance still exists in production, test, or forgotten infrastructure. If you cannot prove absence, treat the environment as exposed until verified otherwise.

What to verify: Validate whether the vulnerable service is reachable from untrusted networks, whether logging covers the relevant servlet paths, and whether there is evidence of unusual requests or post-exploitation activity around the KEV date window and afterwards.

Decision rule: If the system cannot be patched immediately, isolate it, remove unnecessary network exposure, and escalate for compromise assessment rather than waiting for a routine change window. For exploited vulnerabilities, delay increases the chance that remediation happens after attacker access has already been established.

Practitioner takeaway: KEV inclusion means you should manage this as an active exposure problem, not a purely historical CVE, and your first job is to prove whether the vulnerable product still exists, is reachable, and has already been touched.