Is CVE-2020-7961 (Liferay Portal Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2020-7961 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Liferay Portal contains a deserialization of untrusted data vulnerability that allows remote attackers to execute code via JSON web services.

What it means when a vulnerability is already in CISA KEV

When CISA places a CVE in its Known Exploited Vulnerabilities catalogue, the practical question changes from “is exploitation possible?” to “is exploitation already happening, and are we exposed?” That shifts the work from theoretical severity scoring to asset confirmation, exposure reduction, and evidence-led response. The relevant source material here is the exploit status, not a score.

For practitioners, that means treating the issue as an active operational concern until you can prove otherwise. If the vulnerable product is internet-facing, broadly reachable, or embedded in a business-critical workflow, the likelihood of attempted exploitation is high enough to justify immediate triage. Use the vendor advisory and the CISA KEV record for authoritative patch and mitigation details rather than relying on secondary summaries.

Why deserialization flaws are attractive to attackers

deserialization of untrusted data is dangerous because the application can be tricked into reconstructing objects it never intended to accept. In practice, that can lead to remote code execution if an attacker can influence the serialized payload and the application processes it with unsafe trust assumptions. The attack path is especially attractive when the vulnerable interface is exposed through web services or other remote entry points.

This is why deserialization bugs often become rapid exploitation candidates once public awareness rises. Attackers do not need to “break” the application logic in a complicated way if the application will faithfully deserialize attacker-controlled data and then act on it. In a portal environment, that can move quickly from initial request handling to server-side execution, making containment and compromise assessment part of the response, not optional extras.

How to verify exposure and respond without guessing

Start by confirming whether the exact product and vulnerable component are present in your environment, then determine whether any reachable service exposes the affected functionality. If the application is externally accessible, assume it is a priority until proven otherwise. If patching must wait, reduce exposure by removing public reachability, restricting administrative access, and disabling or isolating the vulnerable service path where that is operationally possible.

After remediation, check for evidence of pre-patch abuse. For a deserialization flaw that can lead to code execution, that means looking for suspicious requests, unexpected process execution, webshell-like behaviour, new accounts, altered configuration, or outbound connections that do not fit normal portal activity. If you find signs of compromise, rotate any credentials, session material, or service secrets that the application or its surrounding infrastructure may have exposed.

Risk and Threat Considerations

An actively exploited deserialization flaw creates both exposure risk and attacker opportunity: the control failure is not just the presence of a bug, but the possibility that hostile input is already being turned into execution. Because the vulnerable interface sits in application traffic, exploitation may blend into ordinary request noise until you look for post-exploitation behaviour.

Failure mechanism: The application accepts untrusted serialized content, reconstructs it into runtime objects, and allows attacker-influenced processing to reach code-execution conditions.

Impact: Attackers may gain remote code execution, persistence, or a foothold for follow-on movement, so response should include both patching and compromise checks.

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 and OWASP ASVS 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	Deserialization flaws stem from unsafe handling of untrusted input.
	SI-2 — Flaw Remediation	KEV-listed exploited vulnerabilities require rapid remediation tracking.
Recommendation — Validate all untrusted input before deserialization or object reconstruction. Prioritise and track remediation for exploited vulnerabilities on an emergency timeline.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs belong in continuous vulnerability prioritisation and remediation.
Recommendation — Prioritise KEV-listed flaws for immediate remediation and verify closure.
OWASP ASVS	V15 — Secure Coding and Architecture	Unsafe deserialization is a secure coding and architecture failure in the application layer.
Recommendation — Review deserialization paths and remove unsafe object handling from the design.
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	Deserialization RCE commonly results in interpreter or command execution on the target host.
Recommendation — Hunt for post-exploitation command execution after suspected deserialization abuse.

Practitioner Guidance

What to verify: Confirm the vulnerable Liferay Portal instance, the exposed service path, and whether any compensating control actually blocks untrusted deserialization rather than merely reducing traffic.

Decision rule: If the system is internet-facing or business-critical, treat it as an active-response item, not a routine patch ticket. If patching is delayed, prioritise isolation and detection over debate about exploit certainty.

What good looks like: You can show the vulnerable component is removed or mitigated, evidence of compromise has been checked, and the application is no longer accepting the risky input path from untrusted sources.

Practitioner takeaway: For a KEV-listed deserialization flaw, the decisive question is not whether exploitation is theoretically possible, but whether you have reduced exposure quickly enough to rule out active abuse and before-hand compromise.