Yes. CISA added CVE-2020-28949 to its Known Exploited Vulnerabilities catalogue on 25 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. PEAR Archive_Tar allows an unserialization attack because phar: is blocked but PHAR: is not blocked. Any organisation running the affected product should treat remediation as urgent.
What “being exploited in the wild” means for this CVE
For a KEV-listed CVE, “exploited in the wild” means you should assume real attack activity, not just theoretical risk. That changes the response posture immediately: confirm exposure, remove or contain the vulnerable component, and treat the issue as time-sensitive even if you have not yet seen alerts in your own environment.
The practical question is not whether exploitation is possible, but whether your environment still contains the vulnerable code path. If it does, the attacker value is already there, because KEV inclusion is a strong signal that active exploitation has been observed and that delay increases the chance of compromise.
How to confirm exposure and reduce blast radius
Start by identifying every system, application, image, or package that includes the affected PEAR Archive_Tar component, then trace where that component is reachable from user-controlled input. For internet-facing services, assume the risk is higher until you can prove the vulnerable path is not reachable.
For this kind of deserialisation issue, the important operational question is whether an attacker can influence the code path that handles archive content or serialized data. Review deployment inventories, application dependencies, and any embedded libraries, then isolate or disable the vulnerable function if patching cannot happen immediately. The Insecure Deserialisation Guide is useful background for understanding why unsafe object handling is so often exploit-driven.
If you need a broader response playbook for actively exploited flaws, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both support the same core discipline: scope first, prioritise by exposure, then validate remediation rather than assuming a patch has removed the risk.
What to do before and after remediation
When patching must wait, reduce exposure rather than hoping the vulnerability stays unexploited. That usually means constraining access to the affected service, removing unnecessary ingress, increasing monitoring around the vulnerable endpoint, and preparing to rebuild from a known-good image if compromise evidence appears.
Because exploitation of deserialisation bugs can be followed by code execution, data access, or secondary payload delivery, post-remediation checks should include compromise hunting as well as version verification. Review authentication logs, application logs, file changes, scheduled tasks, webshell indicators, and any unexpected outbound connections from the affected host.
For this specific question, the key decision is whether the host can still process attacker-controlled archive content. If yes, treat the system as exposed until the vulnerable component is removed or the vulnerable workflow is no longer reachable. If you find signs of abuse, rotate credentials or tokens that the application could have accessed, and verify that adjacent systems were not used for lateral movement.
Risk and Threat Considerations
Active exploitation shifts the issue from software hygiene to adversary opportunity. A deserialisation flaw is especially dangerous when the vulnerable component sits in a service that accepts external input, because the attacker may need only one successful request to trigger compromise.
Failure mechanism: The vulnerable library processes untrusted archive content in a way that permits unsafe unserialization, so the attacker can move from crafted input to code execution or equivalent abuse of the application trust boundary.
Impact: The likely outcomes are application compromise, data exposure, follow-on malware delivery, and persistence on the affected system, with higher urgency if the service is internet-facing or handles sensitive data.
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 NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted archive input must be validated before processing. |
| SI-2 — Flaw Remediation | KEV-listed exploited flaws require rapid remediation and verification. | |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation depends on identifying where the vulnerable package is deployed. | |
| Recommendation — Validate and constrain archive input before the application processes it. Prioritise and verify remediation for the vulnerable component immediately. Scan inventories and deployments to confirm where the CVE is present. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV status makes rapid triage and remediation central to the response. |
| CIS-2 — Inventory and Control of Software Assets | You must identify every deployment containing the affected library. | |
| Recommendation — Prioritise this CVE for immediate remediation and exposure tracking. Inventory software assets to locate affected instances and remove them. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Unsafe deserialisation is a secure coding and design failure in application code. |
| V1 — Encoding and Sanitization | The issue is triggered by attacker-controlled input reaching unsafe parsing logic. | |
| Recommendation — Remove unsafe deserialisation paths and redesign the input handling flow. Sanitize and strictly constrain untrusted archive inputs before parsing. | ||
| MITRE ATT&CK | T1210 — Exploitation of Remote Services | Internet-facing services that process untrusted data are common exploitation paths. |
| Recommendation — Hunt for exploitation attempts against exposed services and their logs. | ||
| NIST CSF 2.0 | DE.CM-09 — Malicious Code Detected | Active exploitation justifies heightened detection for malicious payload activity. |
| RS.MA-01 — Incidents Are Managed | A KEV-listed actively exploited flaw may warrant incident handling when exposure exists. | |
| Recommendation — Monitor for malware-like behaviour and suspicious execution after exposure. Handle confirmed exposure or abuse as an incident and coordinate response. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed exposure as an incident-response input, not just a patching ticket. The first task is proving whether any reachable instance still contains the vulnerable component, because that determines whether you are in prevention mode or containment mode.
What to verify: Confirm the vulnerable package is actually absent or no longer reachable in production, then validate from live service paths rather than relying only on inventory records. If the system was exposed during the exploitation window, review whether the application had enough privilege to access secrets, files, or downstream services.
Decision rule: If patching or replacement cannot happen immediately, reduce the attack surface first, then monitor for signs of exploitation, and escalate to compromise assessment when the service is externally reachable or handles untrusted input.
Practitioner takeaway: For a KEV-listed deserialisation flaw, the safe assumption is that exploitation pressure is real until you have verified otherwise, so exposure validation and compromise hunting matter as much as the fix itself.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2020-28949 (PEAR Archive_Tar Deserialization of Untrusted Data)?
- CVE-2020-28949 (PEAR Archive_Tar Deserialization of Untrusted Data)
- Is CVE-2020-7961 (Liferay Portal Deserialization of Untrusted Data) being exploited in the wild?
- 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?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org