It was found that a flaw in commons-collection library allowed remote code execution wherever deserialization occurs. While JBoss doesnt expose the JMXInvokerServlet by default, other interfaces where deserialization occur might be vulnerable.

Note: classes directly referenced by this flaw: InvokerTransformer, InstantiateFactory, and InstantiateTransformer

External References:

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ https://access.redhat.com/solutions/2045023

In Jboss Application Server as shipped with Red Hat Enterprise Application Platform 5.2, it was found that the doFilter method in the ReadOnlyAccessFilter of the HTTP Invoker does not restrict classes for which it performs deserialization and thus allowing an attacker to execute arbitrary code via crafted serialized data.

It was discovered that the jboss init script performed unsafe file handling which could result in local privilege escalation.

A flaw was found in JBoss Enterprise Application Platform. The processInvocation function within the org.jboss.as.ejb3.security.AuthorizationInterceptor component incorrectly authorizes all requests when no roles are defined for an Enterprise Java Beans (EJB) method invocation. This allows attackers to bypass intended access restrictions for EJB methods, leading to unauthorized access to sensitive functionalities.

A flaw was found in xnio. A file descriptor leak caused by growing amounts of NIO Selector file, handled between garbage collection cycles, may allow the attacker to cause a denial of service. The highest threat from this vulnerability is to system availability.