| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The org.apache.catalina.connector.Response.encodeURL method in Red Hat JBoss Web 7.1.x and earlier, when the tracking mode is set to COOKIE, sends the jsessionid in the URL of the first response of a session, which allows remote attackers to obtain the session id (1) via a man-in-the-middle attack or (2) by reading a log. |
| Multiple cross-site scripting (XSS) vulnerabilities in the GateIn Portal in JBoss Enterprise Portal Platform 5.2.2 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. |
| Apache CXF 2.5.x before 2.5.10, 2.6.x before CXF 2.6.7, and 2.7.x before CXF 2.7.4 does not verify that a specified cryptographic algorithm is allowed by the WS-SecurityPolicy AlgorithmSuite definition before decrypting, which allows remote attackers to force CXF to use weaker cryptographic algorithms than intended and makes it easier to decrypt communications, aka "XML Encryption backwards compatibility attack." |
| The default configuration of the (1) LdapLoginModule and (2) LdapExtLoginModule modules in JBoss Enterprise Application Platform (EAP) 4.3.0 CP10, 5.2.0, and 6.0.1, and Enterprise Web Platform (EWP) 5.2.0 allow remote attackers to bypass authentication via an empty password. |
| Apache Santuario XML Security for Java before 1.5.6, when applying Transforms, allows remote attackers to cause a denial of service (memory consumption) via crafted Document Type Definitions (DTDs), related to signatures. |
| The GateIn Portal export/import gadget in JBoss Enterprise Portal Platform 5.2.2 does not properly check authentication when importing Zip files, which allows remote attackers to modify site contents, remove the site, or alter the access controls for portlets. |
| The GateIn Portal export/import gadget in JBoss Enterprise Portal Platform 5.2.2 allows remote attackers to read arbitrary files via a crafted external XML entity in an XML document, aka an XML Entity Expansion (XEE) attack. |
| The default configuration of Red Hat JBoss Portal before 6.1.0 enables the JGroups diagnostics service with no authentication when a JGroups channel is started, which allows remote attackers to obtain sensitive information (diagnostics) by accessing the service. |
| 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. |
| jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java in Apache Santuario XML Security for Java 1.4.x before 1.4.8 and 1.5.x before 1.5.5 allows context-dependent attackers to spoof an XML Signature by using the CanonicalizationMethod parameter to specify an arbitrary weak "canonicalization algorithm to apply to the SignedInfo part of the Signature." |
| The readObject method in the DiskFileItem class in Apache Tomcat and JBoss Web, as used in Red Hat JBoss Enterprise Application Platform 6.1.0 and Red Hat JBoss Portal 6.0.0, allows remote attackers to write to arbitrary files via a NULL byte in a file name in a serialized instance, a similar issue to CVE-2013-2186. NOTE: this issue is reportedly disputed by the Apache Tomcat team, although Red Hat considers it a vulnerability. The dispute appears to regard whether it is the responsibility of applications to avoid providing untrusted data to be deserialized, or whether this class should inherently protect against this issue |
| The DiagnosticsHandler in JGroup 3.0.x, 3.1.x, 3.2.x before 3.2.9, and 3.3.x before 3.3.3 allows remote attackers to obtain sensitive information (diagnostic information) and execute arbitrary code by reusing valid credentials. |
| Red Hat JBoss Enterprise Application Platform (EAP) 6.1.0 does not properly cache EJB invocations by remote-naming, which allows remote attackers to hijack sessions by using a remoting client. |
| Red Hat JBoss Enterprise Application Platform (EAP) 6.1.0 does not properly cache EJB invocations by the EJB client API, which allows remote attackers to hijack sessions by using an EJB client. |
| Multiple cross-site scripting (XSS) vulnerabilities in the GateIn Portal component in Red Hat JBoss Portal 6.1.0 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. |
| The (1) BasicParserPool, (2) StaticBasicParserPool, (3) XML Decrypter, and (4) SAML Decrypter in Shibboleth OpenSAML-Java before 2.6.1 set the expandEntityReferences property to true, which allows remote attackers to conduct XML external entity (XXE) attacks via a crafted XML DOCTYPE declaration. |
| Red Hat JBoss Enterprise Application Platform (JBEAP) 6.2.0 and JBoss WildFly Application Server, when run under a security manager, do not properly restrict access to the Modular Service Container (MSC) service registry, which allows local users to modify the server via a crafted deployment. |
| Apache Tomcat before 6.0.39, 7.x before 7.0.47, and 8.x before 8.0.0-RC3, when an HTTP connector or AJP connector is used, does not properly handle certain inconsistent HTTP request headers, which allows remote attackers to trigger incorrect identification of a request's length and conduct request-smuggling attacks via (1) multiple Content-Length headers or (2) a Content-Length header and a "Transfer-Encoding: chunked" header. NOTE: this vulnerability exists because of an incomplete fix for CVE-2005-2090. |
| 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. |
| org/apache/catalina/realm/RealmBase.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.30, when FORM authentication is used, allows remote attackers to bypass security-constraint checks by leveraging a previous setUserPrincipal call and then placing /j_security_check at the end of a URI. |
