EAP's Artemis deserialization configuration permits deserialization by default. ObjectMessage.getObject() uses ObjectInputStreamWithClassLoader, which implements allow-list/block-list filtering via its checkSecurity()/isTrustedType() method. However, by default both allow-list and block-list are empty. When the allow-list is empty (size == 0), isTrustedType() returns true for ALL classes. This means all classes are deserializable by default.
original reported in: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit
Remote Class Loading — openjdk-orb JDKBridge honours CDR codebase URL under -secmgr (pre-auth :3528) (JBoss EAP)
Pre-auth remote class loading via IIOP: when EAP runs with -secmgr, the openjdk-orb's JDKBridge honours attacker-supplied CDR codebase URLs during object unmarshalling on :3528, allowing an unauthenticated attacker to load and instantiate arbitrary classes from a remote URL in the server JVM before EJB security interceptors run. findings/jboss-eap44.md
A flaw was found in Wildfly. A remote attacker can bypass authentication on IIOP EJB invocations as the CSIv2 security interceptor accepts ITTPrincipalName identity assertions in the service context without verifying transport-level authentication, allowing a pre-auth attacker on the port 3528 to impersonate any principal on every IIOP-exposed @Remote EJB.
initial report: RCE — pre-auth IIOP/GIOP CDR deserialization in EjbCorbaServant.readParams (:3528) (JBoss EAP)
Pre-auth remote code execution via IIOP: the EjbCorbaServant.readParams() method on the :3528 IIOP listener deserializes CDR-marshalled Java objects using an unfiltered ObjectInputStream before any authentication check, allowing an unauthenticated attacker to achieve OS command execution as the EAP process uid with a single GIOP request.
findings/jboss-eap18.md
----- secarx findings: This is better suited as a Moderate impact CVE (New CVE required) for JBoss EAP 7.4 and Low impact for JBoss EAP 8.
Reasons : The finding correctly identifies a real architectural weakness: deserialization of method parameters occurs before authentication in the IIOP invocation path. However, The claim that this uses "an unfiltered ObjectInputStream" is factually wrong — it uses CDR stream readers that are type-constrained to declared EJB parameter types.
The claim of guaranteed "OS command execution with a single GIOP request" overstates exploitability. Actual exploitation requires: (a) network access to port 3528 (loopback by default) (b) an EJB with an untyped method parameter exposed via IIOP (c) a suitable gadget chain on the classpath.
EAP 8.1.0 adds the further mitigation that IIOP exposure is disabled by default per-bean.
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks via CLI.
Network access to any of WildFly or JBoss EAP’s exposed ports which require either HTTP or SASL authentication.
JBoss EAP's IIOP (Internet Inter-ORB Protocol) subsystem processes security tokens from CORBA clients as part of the CSIv2 (Common Secure Interoperability version 2) handshake. This processing happens before any authentication — triggered by a portable interceptor (SASTargetInterceptor) that fires on every single incoming IIOP request. Two methods in CSIv2Util.java read a length field directly from the attacker-controlled network packet and immediately allocate a Java byte array of that size — with zero bounds checking:
A single unauthenticated GIOP packet with a crafted length field can cause: - OutOfMemoryError — the JVM attempts a ~2 GB heap allocation and crashes - NegativeArraySizeException — integer overflow in the length field kills the worker thread - Both outcomes are repeatable — the attacker can sustain the DoS by sending packets in a loop
original reporting:
Missing Authentication — pre-auth CosNaming write ops on iiop-openjdk :3528 (JBoss EAP)
Missing authentication on the IIOP CosNaming service: the :3528 IIOP listener's NameService accepts bind/rebind/unbind operations without any authentication, allowing an unauthenticated attacker to hijack EJB JNDI lookups by rebinding stub references to an attacker-controlled ORB (MITM for all subsequent client invocations) or to unbind critical services for denial of service. findings/jboss-eap96.md
original reporting: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit
DoS — ChunkReader TrailerParser unbounded HeaderMap accumulation (chunked trailer OOM) (JBoss EAP)
JBoss EAP's Undertow HTTP/1.1 chunked-transfer decoder places no size or count limits on the trailer section that follows the terminal 0\r\n chunk, and trailer bytes are not counted against the configured max-entity-size limit; a single unauthenticated TCP connection streaming an arbitrarily large trailer value drives the JVM to OutOfMemoryError, taking down all deployments on the listener — this is fully mitigated when a re-framing L7 reverse proxy (nginx, HAProxy in http-mode, ALB) sits in front, but applies to direct-edge and L4/TCP load-balanced deployments. findings/jboss-eap68.md
initial report: Auth Bypass — Artemis cluster-password leaked to JGroups-spoofed peer → broker MANAGE takeover (JBoss EAP)
Composite authentication bypass: an attacker on the JGroups cluster backplane spoofs a discovery response to join the cluster, and the legitimate Artemis broker transmits its cluster-password in plaintext during the handshake; with this password the attacker authenticates to the CORE cluster channel via :8080 from any network position, gaining full MANAGE-level broker authority including message injection, journal access, and topology manipulation. findings/jboss-eap35.md
----- secarx findings: Prerequisites for exploitation:
1. JGroups network access: The attacker must be on the same multicast-reachable network segment as the JGroups private interface. In default configurations, the private interface binds to 127.0.0.1, so the attacker would need the administrator to have changed jboss.bind.address.private to a routable address (which is required for actual multi-node clustering to work). In any real HA deployment, this address is set to a routable interface. 2. Cluster password capture: If the administrator has not set an explicit cluster-password (left as "CHANGE ME!!"), each node generates a different random UUID and clustering is broken. In any functioning HA deployment, the administrator has set a shared password. When the legitimate broker initiates a ClusterConnectionBridge to the attacker's spoofed node, the CreateSessionMessage containing this shared password is sent in plaintext. The attacker captures it passively. 3. Port 8080 reachability: The attacker must have TCP access to port 8080 on any cluster member. This port is the standard application HTTP port and is typically accessible from client networks.
Attack flow:
Step 1 — The attacker responds to JGroups PING/MPING discovery on the cluster backplane, advertising a spoofed broker endpoint. No AUTH is checked.
Step 2 — A legitimate broker node establishes a ClusterConnectionBridge to the attacker's spoofed endpoint, sending a CreateSessionMessage containing the cluster user and password in plaintext. The attacker captures the password.
Step 3 — From any network position that can reach port 8080, the attacker performs an HTTP upgrade to the CORE protocol (no authentication required for the upgrade itself).
Step 4 — The attacker sends a CreateSessionMessage with username=ACTIVEMQ.CLUSTER.ADMIN.USER and password=the captured value. Artemis SecurityStoreImpl authenticates this internally, bypassing Elytron and all RBAC checks.
Step 5 — The attacker has full MANAGE-level authority: message injection and consumption on all addresses, queue creation and deletion, journal access through management operations, and topology manipulation.
There are some major network level pre-requisites and because of that it should be considered as Important but not Critical. Should be filed as a new CVE and trackers should be created as EAP 8.0 and 8.1 are in full support and should fix this CVE.
submitted through leadership channels
Missing Authentication — Artemis CORE CREATEQUEUE(34) on ch1 creates durable queue pre-auth (JBoss EAP)
Missing authentication on the Artemis CORE protocol channel: an unauthenticated attacker can send CREATEQUEUE packets on channel 1 via the :8080 HTTP-upgrade path to create arbitrary durable JMS queues on the embedded broker, enabling resource exhaustion and persistent broker-state manipulation without any credentials.
findings/jboss-eap17.md
original reported in: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit
Remote Class Loading — openjdk-orb JDKBridge honours CDR codebase URL under -secmgr (pre-auth :3528) (JBoss EAP)
Pre-auth remote class loading via IIOP: when EAP runs with -secmgr, the openjdk-orb's JDKBridge honours attacker-supplied CDR codebase URLs during object unmarshalling on :3528, allowing an unauthenticated attacker to load and instantiate arbitrary classes from a remote URL in the server JVM before EJB security interceptors run. findings/jboss-eap44.md
A flaw was found in the platform-mbean component of JBoss EAP, which provides management access to JVM-level metrics and configurations. The issue occurs because the handler for the read-resource operation on the runtime management resource fails to perform required Role-Based Access Control (RBAC) checks. This allows an authenticated user with low-privileged access, such as the Monitor role, to view sensitive system properties and JVM configuration details that should be restricted.
A flaw was found in the ChunkReader component of the Undertow HTTP server, which is used by WildFly and JBoss EAP to handle chunked transfer encoding. The issue occurs because the parser uses a single internal variable to store both the remaining chunk size and state flags. By sending a specially crafted request with an extremely large chunk size, an attacker can cause these values to overlap, tricking the parser into thinking a request has finished prematurely. This can allow a second, "smuggled" request to be processed out of sync, potentially bypassing security controls.
A potential directory traversal vulnerability in JBoss EAP was discovered. Initial tests determined that appending "/..;/" to a request will return the JBoss EAP welcome page from the / directory.
The identified Stored XSS vulnerabilities in the JBoss EAP Management Console allow authenticated users with appropriate permissions to inject malicious scripts. These scripts can be stored and executed within the context of the application, potentially compromising other users who access the affected components.
Escalation of priveleges can occur when a Domain Controller process is managing slave Host Controllers running EAP 6.2, 6.3 or 6.4.
The domain controller will not propagate its administrative RBAC configuration to those slaves, resulting in the slaves (and the servers they manage) granting administrators full administrative privileges.
A Role-Based Access Control (RBAC) bypass vulnerability was discovered in JBoss EAP within the /core-service=platform-mbean/type=runtime management resource. The flaw is caused by a custom implementation of the read-resource operation handler in the wildfly-platform-mbean component that omits necessary RBAC sensitivity checks. While the read-attribute operation correctly enforces restrictions on security-sensitive attributes, the read-resource(include-runtime) operation bypasses these checks. An authenticated attacker with a low-privilege role (such as Monitor) can exploit this to read sensitive information, including system properties (which may contain resolved secrets or credentials), JVM input arguments, and boot classpath or library path information. This information exposure can be used to facilitate further attacks by revealing environment configuration and sensitive application metadata.
initial report: RCE — pre-auth IIOP/GIOP CDR deserialization in EjbCorbaServant.readParams (:3528) (JBoss EAP)
Pre-auth remote code execution via IIOP: the EjbCorbaServant.readParams() method on the :3528 IIOP listener deserializes CDR-marshalled Java objects using an unfiltered ObjectInputStream before any authentication check, allowing an unauthenticated attacker to achieve OS command execution as the EAP process uid with a single GIOP request.
findings/jboss-eap18.md
----- secarx findings: This is better suited as a Moderate impact CVE (New CVE required) for JBoss EAP 7.4 and Low impact for JBoss EAP 8.
Reasons : The finding correctly identifies a real architectural weakness: deserialization of method parameters occurs before authentication in the IIOP invocation path. However, The claim that this uses "an unfiltered ObjectInputStream" is factually wrong — it uses CDR stream readers that are type-constrained to declared EJB parameter types.
The claim of guaranteed "OS command execution with a single GIOP request" overstates exploitability. Actual exploitation requires: (a) network access to port 3528 (loopback by default) (b) an EJB with an untyped method parameter exposed via IIOP (c) a suitable gadget chain on the classpath.
EAP 8.1.0 adds the further mitigation that IIOP exposure is disabled by default per-bean.
JBoss EAP's CORBA/IIOP subsystem allows external applications to communicate using a protocol called IIOP. Part of this protocol includes a security layer (CSIv2) that lets a connecting client declare "I am this user" by sending a so-called identity token containing a principal name. The server is supposed to only trust this claim if the client was already authenticated at the network level — for example, via a mutual TLS certificate. However, JBoss EAP's implementation skips this transport-level verification entirely: a completely unauthenticated attacker on port 3528 can send a cleartext IIOP message claiming to be "admin" (or any other user), and the server will establish a security context for that EJB invocation using the asserted identity — no password, no certificate, no proof required. The code itself contains a TODO comment explicitly acknowledging the missing TLS binding: // TODO use the TLS identity when that becomes available to us.
The Precise Condition That Enables the Attack The vulnerability activates only when all three of these conditions hold simultaneously:
1. server-requires-ssl="false" ← DEFAULT — no SSL required (or integrity/establish-trust-in-client = "none"|"supported")
2. caller-propagation="supported" ← MUST BE EXPLICITLY SET by Application developer (default is "none" — not set in default configs)
3. as-context required="false" ← DEFAULT (no mandatory GSSUP authentication)
Condition #2 is what makes this non-trivially reachable by default. The server admin or application developer must explicitly opt into caller propagation — either in the subsystem config or in jboss-ejb3.xml.
JBoss EAP has a vulnerability that allows local users who are able to execute init.d script to terminate arbitrary process on the system. An attacker could exploit this by modifying the PID file in /var/run/jboss-eap/ allowing the init.d script to terminate any process as root.
The JMX console as shipped with JBoss EAP 5.1.1 is vulnerable to cross-site request forgery (CSRF) attacks. This vulnerability allows an attacker to invoke operations on mbeans via the JMX console.
When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked as an error state by modcluster in httpd. The problem is that requests exceeding the max-header-size cause JBoss EAP to close the TCP connection without returning an AJP response.
A malicious user could exploit this behavior by repeatedly sending requests that exceed the max-header-size, it causes a denial-of-service attack. This is because modproxycluster marks JBoss instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding.
original reporting: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit
Auth Bypass — Elytron OAuth2 introspection bearer param-injection enables cross-audience token swap (JBoss EAP)
Authentication bypass on any EAP application whose security domain is backed by an Elytron token-realm with <oauth2-introspection>. findings/jboss-eap111.md
End of life: 6/30/2025, End of support: 12/31/2023, Latest version: 7.4.25
End of life: 6/30/2025, End of support: 12/31/2023, Latest version: 7.4.25
End of life: 2/5/2031, End of support: 2/5/2028, Latest version: 8.1.9
End of life: 2/5/2031, End of support: 2/5/2028, Latest version: 8.1.9
This asynchronous patch is a security update zip for the JBoss EAP XP 4.0.2 runtime distribution for use with EAP 7.4.17.Security Fix(es): jose4j: denial of service via specially crafted JWE (CVE-2023-51775) A Red Hat Security Bulletin which addresses further details about the Rapid Reset flaw is available in the References section.For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
This is an asynchronous patch for Red Hat Fuse 7.6.0 on EAP, and includes the following security fix: commons-beanutils: apache-commons-beanutils: does not suppresses the class property in PropertyUtilsBean by default (CVE-2019-10086) To completely fix this CVE, EAP 7.2.7 or later must be applied to the system in addition to this Fuse on EAP patch. For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.
These are CVE issues filed against XP1 releases that have been fixed in the underlying EAP 7.3.x base, so no changes to the EAP XP1 code base.Security Fix(es): velocity: arbitrary code execution when attacker is able to modify templates (CVE-2020-13936) bouncycastle: password bypass in OpenBSDBCrypt.checkPassword utility possible (CVE-2020-28052) jboss-remoting: Threads hold up forever in the EJB server by suppressing the ack from an EJB client (CVE-2020-35510) undertow: Possible regression in fix for CVE-2020-10687 (CVE-2021-20220) wildfly: Information disclosure due to publicly accessible privileged actions in JBoss EJB Client (CVE-2021-20250) netty: Information disclosure via the local system temporary directory (CVE-2021-21290) guava: local information disclosure via temporary directory created with unsafe permissions (CVE-2020-8908) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.