CVE-2020-7961 is a deserialization of untrusted data vulnerability in Liferay Liferay Portal. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Liferay Portal contains a deserialization of untrusted data vulnerability that allows remote attackers to execute code via JSON web services.
What deserialization of untrusted data means in a web application
Deserialization becomes dangerous when an application accepts structured data from an untrusted source and reconstructs objects or executable state from it. In this case, the issue sits in Liferay Portal’s JSON web services, where attacker-controlled input can cross a trust boundary and influence application behaviour.
The core security problem is not the format itself, but the assumption that incoming data is safe enough to turn back into runtime objects. Once that assumption fails, the parser can become an execution path rather than a data-handling feature, which is why deserialization flaws often sit near the top of exploitation chains.
Why this vulnerability can lead to remote code execution
When an attacker can control the payload that is deserialized, they may be able to steer the application into invoking unsafe classes, methods, or object behaviours. For this CVE, that matters because the vulnerability is described as allowing remote code execution, which means the flaw can move from input handling into full system compromise.
That escalation is especially severe in portal software because portals often sit in front of authenticated workflows, business data, and administrative interfaces. If the deserialization path is reachable over the network, an attacker does not need prior foothold inside the server to begin exploitation.
For authoritative record details, use the CVE Program entry and the NIST National Vulnerability Database rather than relying on informal summaries.
How organisations assess exposure and scope
Exposure review starts with knowing where Liferay Portal is deployed, which environments expose its web services, and whether any instances are internet-facing or reachable from untrusted networks. Inventory matters because deserialization flaws are only actionable if the vulnerable component is actually present and reachable.
Teams should also check vendor advisories, deployment notes, and any reverse proxies or gateways that may hide the application from simple scanning. A service may appear segmented while still being reachable through another route, especially when API endpoints or management functions are published separately from the main portal.
Vulnerability Management Guide is useful here because this class of issue is best handled through asset scoping, KEV prioritisation, and verification after remediation.
Remediation, detection, and post-exploitation review
The preferred fix is to apply the vendor’s patched release and confirm that the vulnerable JSON web service path is no longer reachable in a dangerous form. Where patching is delayed, compensating controls should reduce exposure by restricting network access, limiting who can call the affected service, and blocking suspicious request patterns at the edge.
Detection should focus on signs that the portal accepted malformed or unexpected serialization payloads, followed by unusual server-side execution, process creation, or outbound activity. After patching, organisations should still review for compromise because exploitation of deserialization flaws often occurs before defenders know a system was vulnerable.
If the portal was successfully exploited, review service credentials, application secrets, and any sessions or privileged accounts that could have been accessed during the intrusion. Even when the vulnerability is application-level, the impact can extend to identity material, configuration secrets, and adjacent systems that the portal can reach.
Risk and Threat Considerations
This vulnerability is high risk because deserialization bugs often provide a direct bridge from crafted network input to code execution on the server. In a portal product, that can turn a routine web request into a platform-wide compromise path, especially if the application runs with broad privileges or can reach sensitive internal resources.
Failure mechanism: An attacker sends a payload that the application trusts enough to deserialize, then abuses object construction or method invocation to execute code or stage follow-on actions.
Impact: The result can be full server compromise, data theft, credential exposure, lateral movement, or persistence through the application stack.
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 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 are input-handling failures that validate untrusted data paths. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure must be found and tracked across deployed instances and internet-facing services. | |
| SC-18 — Mobile Code | Unsafe code execution from untrusted input overlaps controls for restricting executable content. | |
| Recommendation — Apply SI-10 to reject or strictly validate untrusted serialized input before processing. Use RA-5 to inventory exposed Liferay instances and prioritise the vulnerable service for remediation. Restrict executable or code-like content paths that can be triggered from untrusted inputs. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | The vulnerability originates in unsafe handling of attacker-controlled serialized input. |
| V15 — Secure Coding and Architecture | The issue reflects an architectural trust-boundary failure in how the portal processes input. | |
| Recommendation — Treat serialized request content as untrusted and enforce strict validation and sanitization. Design deserialization paths so untrusted data cannot influence runtime object creation or execution. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Successful exploitation can culminate in execution of attacker-controlled commands or code. |
| Recommendation — Map any resulting server-side execution to T1059 and hunt for spawned processes and follow-on activity. | ||
Practitioner Guidance
Why practitioners should care: This is the kind of flaw that should be treated as a rapid-response item, not a routine backlog ticket, because exploitation can be remote, low-friction, and difficult to spot after the fact. The practical question is whether the vulnerable path is still reachable and whether the system can be safely isolated until remediation is complete.
Practitioner takeaway: Prioritise exposure removal, verify the remediation path against the vendor advisory, and assume post-exploitation review is needed if the service was reachable from untrusted networks.
Related resources from NHI Mgmt Group
- CVE-2020-28949 (PEAR Archive_Tar Deserialization of Untrusted Data)
- CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data)
- CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)
- CVE-2023-21529 (Microsoft Exchange Server Deserialization of Untrusted Data)