The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) before 6.2.0, does not properly enforce the method level restrictions for JAX-WS Service endpoints, which allows remote authenticated users to access otherwise restricted JAX-WS handlers by leveraging permissions to the EJB class.
Red Hat JBoss Enterprise Application Platform (EAP) before 6.1.0 and JBoss Portal before 6.1.0 does not load the implementation of a custom authorization module for a new application when an implementation is already loaded and the modules share class names, which allows local users to control certain applications' authorization decisions via a crafted application.
PicketBox, as used in Red Hat JBoss Enterprise Application Platform before 6.1.1, allows local users to obtain the admin encryption key by reading the Vault data file.
ResourceBuilderImpl.java in the RichFaces 3.x through 5.x implementation in Red Hat JBoss Web Framework Kit before 2.3.0, Red Hat JBoss Web Platform through 5.2.0, Red Hat JBoss Enterprise Application Platform through 4.3.0 CP10 and 5.x through 5.2.0, Red Hat JBoss BRMS through 5.3.1, Red Hat JBoss SOA Platform through 4.3.0 CP05 and 5.x through 5.3.1, Red Hat JBoss Portal through 4.3 CP07 and 5.x through 5.2.2, and Red Hat JBoss Operations Network through 2.4.2 and 3.x through 3.1.2 does not restrict the classes for which deserialization methods can be called, which allows remote attackers to execute arbitrary code via crafted serialized data.
The processInvocation function in org.jboss.as.ejb3.security.AuthorizationInterceptor in JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) before 6.0.1, authorizes all requests when no roles are allowed for an Enterprise Java Beans (EJB) method invocation, which allows attackers to bypass intended access restrictions for EJB methods.
The JBoss Server in JBoss Enterprise Application Platform 5.1.x before 5.1.2 and 5.2.x before 5.2.2, Web Platform before 5.1.2, BRMS Platform before 5.3.0, and SOA Platform before 5.3.0, when the server is configured to use the JaccAuthorizationRealm and the ignoreBaseDecision property is set to true on the JBossWebRealm, does not properly check the permissions created by the WebPermissionMapping class, which allows remote authenticated users to access arbitrary applications.
The servlets invoked by httpha-invoker in JBoss Enterprise Application Platform before 5.1.2, SOA Platform before 5.2.0, BRMS Platform before 5.3.0, and Portal Platform before 4.3 CP07 perform access control only for the GET and POST methods, which allow remote attackers to bypass authentication by sending a request with a different method. NOTE: this vulnerability exists because of a CVE-2010-0738 regression.
message/ax/AxMessage.java in OpenID4Java before 0.9.6 final, as used in JBoss Enterprise Application Platform 5.1 before 5.1.2, Step2, Kay Framework before 1.0.2, and possibly other products does not verify that Attribute Exchange (AX) information is signed, which allows remote attackers to modify potentially sensitive AX information without detection via a man-in-the-middle (MITM) attack.
jboss-seam.jar in the JBoss Seam 2 framework 2.2.x and earlier, as distributed in Red Hat JBoss Enterprise SOA Platform 4.3.0.CP04 and 5.1.0 and JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) 4.3.0.CP09 and 5.1.0, does not properly restrict use of Expression Language (EL) statements in FacesMessages during page exception handling, which allows remote attackers to execute arbitrary Java code via a crafted URL to an application.
The org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run method in JBoss Remoting 2.2.x before 2.2.3.SP4 and 2.5.x before 2.5.3.SP2 in Red Hat JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) 4.3 through 4.3.0.CP09 allows remote attackers to cause a denial of service (daemon outage) by establishing a bisocket control connection TCP session, and then not sending any application data, related to a missing CVE-2010-3862 patch. NOTE: this can be considered a duplicate of CVE-2010-3862 because a missing patch should not be assigned a separate CVE identifier.