===== bug-0408be00e14215af19589143 =====
bug_id: bug-0408be00e14215af19589143
status: candidate
kind: knowledge
technology: Liferay Portal
entry_id: cve-2019-16891-jabsorb-portlet-url
title: CVE-2019-16891: unsafe jabsorb class-hint deserialization through Portlet URL parameterMap
severity: critical
updated_at: 2026-10-11 01:33:13
--- detail
Liferay Portal versions before 7.1.1 can deserialize attacker-selected classes from jabsorb JSON class hints (CVE-2019-16891 / GHSA-372h-p48h-xw8q). In legacy releases, JSONFactoryUtil.deserialize() delegates to LiferayJSONSerializer.fromJSON(), and LiferayJSONSerializer.getClassFromHint() accepts the JSON javaClass value without checking a class allow-list. LPS-84521 fixes the root cause by checking a deserialization whitelist and rewriting unapproved hints to a HashMap. Direct impact is remote code execution when a reachable deserialize() call and suitable bundled bean/gadget classes are present.

Reusable Portlet URL surface: GET <context>/c/portal/portlet_url reads parameterMap and calls JSONFactoryUtil.deserialize() before iterating the result as Map<String,String>. A public layout can provide the Guest p_auth token. To check the primitive without command execution, start a fresh session at <context>/c/portal/layout?p_l_id=<public-plid>, extract Liferay.authToken, and send parameterMap with an unapproved but side-effect-free class such as java.util.TreeMap and a random nested map marker. A generated portlet URL containing the namespaced random marker means the class hint was honored. A patched serializer should reject or rewrite the unapproved class and should not return the nested marker. Some legacy org.json parsers accept the nonstandard key spelling java\u+043lass as javaClass; this can matter when an edge filter blocks the literal key, but only use it after the ordinary spelling is blocked and the product fingerprint matches.

The command-execution chain depends on available runtime classes. One confirmed legacy combination uses SQLErrorCodeSQLExceptionTranslator -> Tomcat DBCP BasicDataSource -> HSQLDB connectionInitSqls -> an HSQLDB Java function mapped to groovy.util.Eval.me. Prove impact with one unique command-result callback and do not infer execution from an HTTP 400 alone, because the endpoint casts the completed map values to String after deserialization.

Affected/fixed versions and primary references:
- GHSA-372h-p48h-xw8q / CVE-2019-16891: affected Liferay Portal < 7.1.1; fixed in 7.1.1: https://github.com/advisories/GHSA-372h-p48h-xw8q
- Liferay LPS-84521 jabsorb class-whitelist fix: https://github.com/liferay/liferay-portal/commit/0ddba9a0bb0cfc5516b3ba36d43b215e03c94475
- Liferay CST-7111 advisory: https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/cst-7111

Remediation: upgrade to a currently supported Liferay DXP release containing the jabsorb deserialization whitelist. For a retained legacy Enterprise branch, obtain the applicable vendor patch and verify that unregistered javaClass values are rejected on every JSONFactoryUtil.deserialize() surface.

===== bug-272b0aad9771b4fb8253f2ba =====
bug_id: bug-272b0aad9771b4fb8253f2ba
status: candidate
kind: knowledge
technology: Liferay Portal
entry_id: lps-64441
title: LPS-64441: unsafe Java deserialization in Liferay tunnel and serialization paths
severity: critical
updated_at: 2026-10-10 18:08:26
--- detail
Liferay Portal unsafe Java deserialization in legacy Java-serialization surfaces (vendor advisory LPS-64441). Affected releases include Liferay Portal 6.2 CE GA5 and earlier and 7.0 CE GA2 and earlier; the vendor fix is present in 6.2 CE GA6 and 7.0 CE GA3. The LPS-64441 patch changes com.liferay.portal.service.http.TunnelUtil from raw ObjectInputStream to ProtectedObjectInputStream and blocks known gadget classes including org.apache.commons.collections.functors.InvokerTransformer.

Remote-staging response variant: when an attacker can invoke a publish_to_remote flow and control remoteAddress, remotePort, and remotePathContext, GroupServiceHttp.getGroup() POSTs Java serialization to <remote>/api/liferay/do and TunnelUtil.invoke() deserializes the HTTP response. A gadget-bearing response can execute code in the portal process. Prerequisites depend on route authorization and layout/group permissions; do not assume the remote-staging action is anonymously reachable. A deterministic check needs a permitted group/layout ID, a fresh portal auth token/session, and an attacker-controlled response server. A unique command-result callback after the serialized response is read is the expected positive result; an outbound Java POST alone establishes only SSRF/remote publication.

Primary references:
- https://liferay.dev/vulnerabilities/-/asset_publisher/yX1PCnD5l9zt/content/id/121605728
- https://github.com/community-security-team/liferay-portal/compare/6.2.5-ga6...6.2.5-LPS-64441.patch

Remediation: upgrade to a currently supported Liferay DXP release containing the LPS-64441 protections. If a legacy branch must be retained temporarily, apply the vendor patch to every unsafe ObjectInputStream sink and remove untrusted access to remote-staging controls; class deny-lists alone are not a durable substitute for eliminating untrusted native Java deserialization.

===== bug-93efac87a44b5ea0936c21c5 =====
bug_id: bug-93efac87a44b5ea0936c21c5
status: candidate
kind: knowledge
technology: Liferay Portal
entry_id: cve-2017-5601
title: Liferay Portal unsafe Java deserialization in remote service endpoints (CVE-2017-5601)
severity: critical
updated_at: 2026-09-24 14:43:52
--- detail
Liferay Portal unsafe Java deserialization (CVE-2017-5601 / LPS-64441).

Root cause and vectors: affected Liferay releases expose multiple native-Java deserialization sinks, including TunnelServlet under /api/liferay/* and Spring HTTP Invoker exporters under /api/spring/* and /api/secure/spring/*. TunnelServlet constructs ObjectInputStream directly from the HTTP request body. Spring's HttpInvokerServiceExporter creates an ObjectInputStream and calls readObject() before checking that the result is a RemoteInvocation. A compatible gadget chain from libraries on the portal classpath can run code before Liferay authentication, service-method checks, or post-deserialization type checks.

Affected and fixed versions: the vendor advisory covers Liferay DXP 7.0 before Fix Pack 20 / 7.0.4 and Liferay Portal 7.0 CE GA3, fixed in 7.0 CE GA4. Liferay also published an LPS-64441 security patch for Portal 6.2 CE GA6. Older unsupported releases such as Portal 6.1.1 GA2 predate these protections. Upgrade to a supported fixed Liferay release. If an immediate upgrade is impossible, apply the vendor-supported patch for the deployed branch and remove or network-restrict both the TunnelServlet and Spring remoting servlet mappings.

Validation guidance: fingerprint Liferay and the release with product-specific static assets or headers. Test each handler separately; /api/liferay/* and /api/spring/* use distinct servlet mappings and deserializers. A benign serialized RemoteInvocation can identify a reachable Spring exporter when it returns a serialized RemoteInvocationResult, but reachability alone is not exploitability. Confirm with one minimal command-controlled callback gadget and correlate its exact triggering request. Edge URL normalization and request-body inspection can hide canonical routes or block small gadget bodies; encoded path segments and serialized padding are deployment-specific transport bypasses, not the underlying product flaw. Do not read files, enumerate internal services, or use cloud credentials.

Primary references:
- https://liferay.dev/vulnerabilities/-/asset_publisher/yDz4rj2P2iYu/content/id/121605728
- https://github.com/community-security-team/liferay-portal/compare/6.2.5-ga6...6.2.5-LPS-64441.patch
- https://nvd.nist.gov/vuln/detail/CVE-2017-5601