The default configuration of the deployment descriptor (aka web.xml) in picketlink-sts.war in (1) the securitysaml quickstart, (2) the webserviceproxysecurity quickstart, (3) the web-console application, (4) the http-invoker application, (5) the gpd-deployer application, (6) the jbpm-console application, (7) the contract application, and (8) the uddi-console application in JBoss Enterprise SOA Platform before 5.0.2 contains GET and POST http-method elements, which allows remote attackers to bypass intended access restrictions via a crafted HTTP request.

A low impact privilege escalation flaw in the JBoss ESB component was found whereby the execution of a service with a different domain could, potentially, have resulted in the pipeline being run with different sets of credentials, (one set from the first domain if the request were still valid and a second set from the other domain if it had expired).

By using a specially crafted HTTP request, the first layer of authentication for the invoker servlets deployed by httpha-invoker can be bypassed, as the access restrictions only apply for GET and POST. Due to the second layer of authentication provided by the security interceptor, there is no way to directly exploit this flaw. If a user misconfigured the security interceptor or inadvertently disabled it, this flaw would be exploitable.

The fix is to remove the verb-specific <http-method> elements from web.xml. This issue is a regression of CVE-2010-0738.

A flaw was found in JBoss web services where the services used a weak symmetric encryption protocol, PKCS#1 v1.5. An attacker could use this weakness in chosen-ciphertext attacks to recover the symmetric key and conduct further attacks.

JGroups diagnostics service in JBoss Enterprise Portal Platform before 5.2.2, SOA Platform before 5.3.0, and BRMS Platform before 5.3.0, is enabled without authentication when started by the JGroups channel, which allows remote attackers in adjacent networks to read diagnostics information via a crafted IP multicast.

A flaw was found in the way JBoss RichFaces handled deserialization. A remote attacker could use this flaw to trigger the execution of the deserialization methods in any serializable class deployed on the server. This could lead to a variety of security impacts depending on the deserialization logic of these classes.