How do you patch or mitigate CVE-2020-7961 (Liferay Portal Deserialization of Untrusted Data)?

CISA’s required action for CVE-2020-7961 is to apply updates per vendor instructions. In practice, find every instance of Liferay Liferay Portal in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What patching CVE-2020-7961 should look like in practice

The safest response is to treat this as an exploited deserialization flaw, not just a routine upgrade. That means locating every Liferay Portal instance, applying the vendor security update or documented mitigation, and verifying that the change really removed the vulnerable exposure. For guidance on urgent vulnerability handling, use Zero-Day and Exploited Vulnerabilities Guide and the CISA Known Exploited Vulnerabilities Catalog.

If patching is delayed, reduction of exposure matters immediately. Taking the product out of internet-facing service, or isolating it behind tighter access paths, is a practical compensating control because deserialization bugs are valuable to attackers precisely when the service is reachable from untrusted networks. Use the vendor advisory for version-specific remediation details rather than trying to infer a safe configuration from the CVE name alone.

After mitigation, confirm that the vulnerable component is no longer reachable in the way it was before. For deserialization issues, the question is not only whether the patch installed cleanly, but whether the application still exposes the same request paths, components, or integrations that could be exercised by an attacker. A clean remediation also needs a post-change check that the update did not break the portal in a way that forces teams to roll back.

How to check for compromise before and after remediation

Because the flaw was used in the wild, patching should be paired with compromise review. Search application, web, and host logs for unusual requests, unexpected errors around deserialization handling, new admin activity, and any behavior that appeared shortly before the update window. If you find signs of exploitation, treat the instance as potentially compromised until you have reviewed persistence, changed credentials where needed, and confirmed the scope of access.

For a practical hunting workflow, pair log review with the same kind of urgency used for actively exploited vulnerabilities. The goal is to establish whether the vulnerable service was merely exposed or actually exercised. That distinction affects whether you need only containment and patch verification, or a fuller incident response with evidence preservation and deeper forensics.

When the vulnerable system handled sensitive sessions or administrative access, re-check whether an attacker could have used the flaw to pivot beyond the portal itself. Even when the direct fix is straightforward, the surrounding access paths, saved sessions, service integrations, and administrative workflows may also need review if exploitation is suspected.

Why exposure control and verification matter as much as the patch

Deserialization flaws often become high-impact because they combine remote reachability with execution potential, which makes them attractive for opportunistic exploitation. If you cannot patch immediately, reducing exposure is not a lesser option, it is the control that limits attacker reach while you schedule the fix. The practical standard is to remove the easiest path to the vulnerable code first, then restore service only after you have evidence that the update or mitigation is in place.

Verification should include both asset discovery and post-change confirmation. A patch plan that only updates the known production server can miss cloned environments, forgotten test systems, or alternate deployment slots that still expose the same vulnerable product. For this kind of issue, incomplete inventory is often the real failure mode, not the patch itself.

Standards & Framework Alignment

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

CIS Controls v8 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-7 — Continuous Vulnerability Management	CVE patching and exposure checks are core vulnerability management work.
Recommendation — Prioritise, patch, and verify the vulnerable Liferay instances before returning them to service.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The answer is about applying vendor fixes and validating remediation for a known flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Finding all exposed Liferay instances and checking for residual exposure is vulnerability monitoring work.
	AU-6 — Audit Record Review, Analysis, and Reporting	Log review for signs of exploitation is directly relevant after patching.
Recommendation — Apply the vendor remediation and verify affected systems are updated everywhere. Scan for every instance and confirm no vulnerable exposure remains. Review logs for exploit indicators and escalate if compromise is suspected.

Practitioner Guidance

What to prioritise: Identify every Liferay Portal instance, then decide whether each one can be patched, mitigated, or taken offline. Do not leave internet exposure in place while waiting for maintenance windows if the instance is known to be vulnerable.

What to verify: Confirm the vendor update or mitigation was applied everywhere the product runs, including non-production copies and any externally reachable deployment path. Then validate logs for exploitation indicators before declaring the issue closed.

Decision rule: If patching is not immediately possible, remove public exposure first, because containment is the only durable short-term control when a flaw has already been exploited in the wild.

Practitioner takeaway: For actively exploited deserialization bugs, the correct sequence is exposure reduction, remediation, and compromise review, not patching alone.