Eclipse GlassFish CVE-2026-2587: Brief Summary of a Critical EL Injection Leading to Remote Code Execution

Introduction

A critical Expression Language injection in Eclipse GlassFish's gadget handler allows remote attackers to achieve full code execution on the underlying server, scoring a 9.6 on the CVSS scale. For any organization running GlassFish with an exposed administration console, this vulnerability provides a direct path from a crafted URL to a reverse shell on the host.

Eclipse GlassFish is the open source reference implementation of the Jakarta EE platform, maintained by the Eclipse Foundation. It serves as both a production application server and the baseline against which Jakarta EE compliance is measured, making it widely deployed across enterprise Java environments. Its role as the canonical Jakarta EE implementation means that vulnerabilities in GlassFish often signal broader patterns worth watching across the Java application server ecosystem.

Technical Information

The root cause of CVE-2026-2587 falls under CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement. The GlassFish gadget handler processes .xml files and evaluates user supplied values using the Jakarta Expression Language interpreter at runtime. The critical flaw is that these values are evaluated without any sanitization or escaping, meaning attacker controlled input is treated as executable EL code.

The vulnerability resides specifically in the server side template rendering mechanism used by the gadget handler component. When the endpoint at /common/gadgets/gadget.jsf receives a request with a URL parameter pointing to an external XML file, it fetches that file and processes its contents. Any EL expressions embedded in the XML are evaluated by the server. A simple proof that this evaluation occurs: injecting #{7*7} into the XML causes the server to return 49 in its response.

Attack Flow

The exploitation chain proceeds as follows:

1. Reconnaissance: The attacker identifies a GlassFish instance with the Administration Console accessible, typically on port 4848.

2. Payload preparation: The attacker crafts a malicious XML file containing an EL injection payload. The publicly documented approach uses Java reflection to access java.lang.Runtime and invoke arbitrary system commands.

3. Delivery: The attacker hosts the malicious XML on a server they control.

4. Triggering evaluation: The attacker sends a request (or tricks an authenticated administrator into sending one via CSRF) to the endpoint /common/gadgets/gadget.jsf, passing the URL of the malicious XML as a parameter.

5. Execution: The GlassFish server fetches the XML, evaluates the embedded EL expressions, and executes the attacker's payload. The documented result is a reverse shell providing full interactive access to the host.

The CSRF component of this attack is significant. Even if the administration console is not directly accessible to an external attacker, an authenticated administrator who visits a malicious page could unknowingly trigger the exploit. This broadens the attack surface beyond direct network access to the console.

The fix was implemented in the glassfish-jsftemplating component, where access to vulnerable EL expressions within the templating engine was restricted.

Affected Systems and Versions

The vulnerability impacts multiple branches of Eclipse GlassFish:

The vulnerable component is the gadget handler within the GlassFish Administration Console. Deployments using the embedded mode without the administration console may not be directly affected, though this should be verified on a per deployment basis. Any instance where port 4848 (or the configured administration port) is reachable, whether directly or through a proxy, should be considered at risk.

Vendor Security History

The Eclipse Foundation has a documented track record of addressing security issues in GlassFish. Prior vulnerabilities include:

• CVE-2024-8646: A URL redirection flaw in GlassFish.
• CVE-2024-10029: A reflected cross site scripting vulnerability in the Administration Console.

For CVE-2026-2587, the Foundation demonstrated a coordinated response. The fix was merged into the templating component on February 23, 2026, and the GlassFish 8.0.2 release incorporating the fix shipped on May 5, 2026. This timeline shows roughly a two and a half month window between the code fix and the release, which is a reasonable cadence for an open source project coordinating across multiple component repositories.

References

• NVD Entry for CVE-2026-2587
• CVE Record: CVE-2026-2587
• Eclipse Security CVE Assignment Issue #86
• Eclipse Security Vulnerability Report Issue #329
• Restrict access to vulnerable EL expressions: Pull Request #105
• Eclipse GlassFish 8.0.2 Release
• Eclipse GlassFish 7.1.0 Release
• Eclipse GlassFish Project
• CVE-2024-8646 Detail
• CVE-2024-10029 Detail