| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| It is possible to crash (panic) an application by providing a corrupted data to be read. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue. |
| No description is available for this CVE. |
| Apache ActiveMQ does not properly validate the remaining length field which may lead to an overflow during the decoding of malformed packets. When this integer overflow occurs, ActiveMQ may incorrectly compute the total Remaining Length and subsequently misinterpret the payload as multiple MQTT control packets which makes the broker susceptible to unexpected behavior when interacting with non-compliant clients. This behavior violates the MQTT v3.1.1 specification, which restricts Remaining Length to a maximum of 4 bytes. The scenario occurs on established connections after the authentication process. Brokers that are not enabling mqtt transport connectors are not impacted.
This issue affects Apache ActiveMQ: before 5.19.2, 6.0.0 to 6.1.8, and 6.2.0
Users are recommended to upgrade to version 5.19.2, 6.1.9, or 6.2.1, which fixes the issue. |
| Remote Code Execution Vulnerability in NashornScriptEngineCreator is reported in Apache Ranger versions <= 2.7.0.
Users are recommended to upgrade to version 2.8.0, which fixes this issue. |
| Hostname verification bypass issue in Apache Ranger NiFiRegistryClient/NiFiClient is reported in Apache Ranger versions <= 2.7.0.
Users are recommended to upgrade to version 2.8.0, which fixes this issue. |
| Missing Authentication for Critical Function (CWE-306) vulnerability in Apache Artemis, Apache ActiveMQ Artemis. An unauthenticated remote attacker can use the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. This could potentially result in message injection into any queue and/or message exfiltration from any queue via the rogue broker. This impacts environments that allow both:
- incoming Core protocol connections from untrusted sources to the broker
- outgoing Core protocol connections from the broker to untrusted targets
This issue affects:
- Apache Artemis from 2.50.0 through 2.51.0
- Apache ActiveMQ Artemis from 2.11.0 through 2.44.0.
Users are recommended to upgrade to Apache Artemis version 2.52.0, which fixes the issue.
The issue can be mitigated by either of the following:
- Remove Core protocol support from any acceptor receiving connections from untrusted sources. Incoming Core protocol connections are supported by default via the "artemis" acceptor listening on port 61616. See the "protocols" URL parameter configured for the acceptor. An acceptor URL without this parameter supports all protocols by default, including Core.
- Use two-way SSL (i.e. certificate-based authentication) in order to force every client to present the proper SSL certificate when establishing a connection before any message protocol handshake is attempted. This will prevent unauthenticated exploitation of this vulnerability. |
| Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component.
The Camel-LevelDB DefaultLevelDBSerializer class deserializes data read from the LevelDB aggregation repository using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. An attacker who can write to the LevelDB database files used by a Camel application can inject a crafted serialized Java object that, when deserialized during normal aggregation repository operations, results in arbitrary code execution in the context of the application.
This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. For the 4.10.x LTS releases, users are recommended to upgrade to 4.10.9, while for 4.14.x LTS releases, users are recommended to upgrade to 4.14.5 |
| Bypass/Injection vulnerability in Apache Camel components under particular conditions.
This issue affects Apache Camel: from 4.10.0 through <= 4.10.1, from 4.8.0 through <= 4.8.4, from 3.10.0 through <= 3.22.3.
Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases.
This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific
headers that for some Camel components can alter the behaviours such as the camel-bean component, to call another method
on the bean, than was coded in the application. In the camel-jms component, then a malicious header can be used to send
the message to another queue (on the same broker) than was coded in the application. This could also be seen by using the camel-exec component
The attacker would need to inject custom headers, such as HTTP protocols. So if you have Camel applications that are
directly connected to the internet via HTTP, then an attacker could include malicious HTTP headers in the HTTP requests
that are send to the Camel application.
All the known Camel HTTP component such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http would be vulnerable out of the box.
In these conditions an attacker could be able to forge a Camel header name and make the bean component invoking other methods in the same bean.
In terms of usage of the default header filter strategy the list of components using that is:
* camel-activemq
* camel-activemq6
* camel-amqp
* camel-aws2-sqs
* camel-azure-servicebus
* camel-cxf-rest
* camel-cxf-soap
* camel-http
* camel-jetty
* camel-jms
* camel-kafka
* camel-knative
* camel-mail
* camel-nats
* camel-netty-http
* camel-platform-http
* camel-rest
* camel-sjms
* camel-spring-rabbitmq
* camel-stomp
* camel-tahu
* camel-undertow
* camel-xmpp
The vulnerability arises due to a bug in the default filtering mechanism that only blocks headers starting with "Camel", "camel", or "org.apache.camel.".
Mitigation: You can easily work around this in your Camel applications by removing the headers in your Camel routes. There are many ways of doing this, also globally or per route. This means you could use the removeHeaders EIP, to filter out anything like "cAmel, cAMEL" etc, or in general everything not starting with "Camel", "camel" or "org.apache.camel.". |
| Schema parsing in the parquet-avro module of Apache Parquet 1.15.0 and previous versions allows bad actors to execute arbitrary code
Users are recommended to upgrade to version 1.15.1, which fixes the issue. |
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Airflow Common SQL Provider.
When using the partition clause in SQLTableCheckOperator as parameter (which was a recommended pattern), Authenticated UI User could inject arbitrary SQL command when triggering DAG exposing partition_clause to the user.
This allowed the DAG Triggering user to escalate privileges to execute those arbitrary commands which they normally would not have.
This issue affects Apache Airflow Common SQL Provider: before 1.24.1.
Users are recommended to upgrade to version 1.24.1, which fixes the issue. |
| Schema parsing in the parquet-avro module of Apache Parquet 1.15.0 and previous versions allows bad actors to execute arbitrary code.
While 1.15.1 introduced a fix to restrict untrusted packages, the default setting of trusted packages still allows malicious classes from these packages to be executed.
The exploit is only applicable if the client code of parquet-avro uses the "specific" or the "reflect" models deliberately for reading Parquet files. ("generic" model is not impacted)
Users are recommended to upgrade to 1.15.2 or set the system property "org.apache.parquet.avro.SERIALIZABLE_PACKAGES" to an empty string on 1.15.1. Both are sufficient to fix the issue. |
| A session management vulnerability exists in Apache Roller before version 6.1.5 where active user sessions are not properly invalidated after password changes. When a user's password is changed, either by the user themselves or by an administrator, existing sessions remain active and usable. This allows continued access to the application through old sessions even after password changes, potentially enabling unauthorized access if credentials were compromised.
This issue affects Apache Roller versions up to and including 6.1.4.
The vulnerability is fixed in Apache Roller 6.1.5 by implementing centralized session management that properly invalidates all active sessions when passwords are changed or users are disabled. |
| Remote Code Execution with untrusted URI of UDF vulnerability in Apache IoTDB. The attacker who has privilege to create UDF can register malicious function from untrusted URI.
This issue affects Apache IoTDB: from 1.0.0 before 1.3.4.
Users are recommended to upgrade to version 1.3.4, which fixes the issue. |
| The terminal emulator of Apache Guacamole 1.5.5 and older does not properly validate console codes received from servers via text-based protocols like SSH. If a malicious user has access to a text-based connection, a specially-crafted sequence of console codes could allow arbitrary code to be executed
with the privileges of the running guacd process.
Users are recommended to upgrade to version 1.6.0, which fixes this issue. |
| Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat. For a subset of unlikely rewrite rule configurations, it was possible
for a specially crafted request to bypass some rewrite rules. If those
rewrite rules effectively enforced security constraints, those
constraints could be bypassed.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions
may also be affected.
Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue. |
| Improper Restriction of Operations within the Bounds of a Memory Buffer and Stack-based Buffer Overflow vulnerabilities were discovered in Apache NuttX RTOS Bluetooth Stack (HCI and UART components) that may result in system crash, denial of service, or arbitrary code execution, after receiving maliciously crafted packets.
NuttX's Bluetooth HCI/UART stack users are advised to upgrade to version 12.9.0, which fixes the identified implementation issues.
This issue affects Apache NuttX: from 7.25 before 12.9.0. |
| Incorrect Permission Assignment for Critical Resource vulnerability in Apache APISIX(java-plugin-runner).
Local listening file permissions in APISIX plugin runner allow a local attacker to elevate privileges.
This issue affects Apache APISIX(java-plugin-runner): from 0.2.0 through 0.5.0.
Users are recommended to upgrade to version 0.6.0 or higher, which fixes the issue. |
| Improper Access Control vulnerability in Apache Commons.
A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default.
Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty().
Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests.
This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils
1.x are recommended to upgrade to version 1.11.0, which fixes the issue.
Users of the artifact org.apache.commons:commons-beanutils2
2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. |
| A possible security vulnerability has been identified in Apache Kafka.
This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config
and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0).
When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config`
property for any of the connector's Kafka clients to "com.sun.security.auth.module.LdapLoginModule", which can be done via the
`producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties.
This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.
Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box
configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector
client override policy that permits them.
Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage
in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" are disabled in Apache Kafka Connect 3.9.1/4.0.0.
We advise the Kafka users to validate connector configurations and only allow trusted LDAP configurations. Also examine connector dependencies for
vulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation. Finally,
in addition to leveraging the "org.apache.kafka.disallowed.login.modules" system property, Kafka Connect users can also implement their own connector
client config override policy, which can be used to control which Kafka client properties can be overridden directly in a connector config and which cannot. |
| In some mod_ssl configurations on Apache HTTP Server 2.4.35 through to 2.4.63, an access control bypass by trusted clients is possible using TLS 1.3 session resumption.
Configurations are affected when mod_ssl is configured for multiple virtual hosts, with each restricted to a different set of trusted client certificates (for example with a different SSLCACertificateFile/Path setting). In such a case, a client trusted to access one virtual host may be able to access another virtual host, if SSLStrictSNIVHostCheck is not enabled in either virtual host. |
