9 results (0.010 seconds)

CVSS: 7.4EPSS: 0%CPEs: 2EXPL: 0

While an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced. Two preconditions are needed to trigger the bug: 1. The administrator decides to remove an ACL 2. The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal. When those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct. The incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain). The full impact depends on the ACLs in use. If only ALLOW ACLs were configured during the migration, the impact would be limited to availability impact. if DENY ACLs were configured, the impact could include confidentiality and integrity impact depending on the ACLs configured, as the DENY ACLs might be ignored due to this vulnerability during the migration period. • http://www.openwall.com/lists/oss-security/2024/04/12/3 https://lists.apache.org/thread/6536rmzyg076lzzdw2xdktvnz163mjpy https://security.netapp.com/advisory/ntap-20240705-0002 • CWE-863: Incorrect Authorization •

CVSS: 8.8EPSS: 96%CPEs: 1EXPL: 2

A possible security vulnerability has been identified in Apache Kafka Connect API. This requires access to a 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 Connect clusters since Apache Kafka Connect 2.3.0. When configuring the connector via the 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.JndiLoginModule", 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.4.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" is disabled in Apache Kafka Connect 3.4.0. We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI 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. • https://github.com/ohnonoyesyes/CVE-2023-25194 https://github.com/YongYe-Security/CVE-2023-25194 http://packetstormsecurity.com/files/173151/Apache-Druid-JNDI-Injection-Remote-Code-Execution.html https://kafka.apache.org/cve-list https://lists.apache.org/thread/vy1c7fqcdqvq5grcqp6q5jyyb302khyz https://access.redhat.com/security/cve/CVE-2023-25194 https://bugzilla.redhat.com/show_bug.cgi?id=2216516 - • CWE-502: Deserialization of Untrusted Data •

CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0

A security vulnerability has been identified in Apache Kafka. It affects all releases since 2.8.0. The vulnerability allows malicious unauthenticated clients to allocate large amounts of memory on brokers. This can lead to brokers hitting OutOfMemoryException and causing denial of service. Example scenarios: - Kafka cluster without authentication: Any clients able to establish a network connection to a broker can trigger the issue. - Kafka cluster with SASL authentication: Any clients able to establish a network connection to a broker, without the need for valid SASL credentials, can trigger the issue. - Kafka cluster with TLS authentication: Only clients able to successfully authenticate via TLS can trigger the issue. • https://kafka.apache.org/cve-list https://access.redhat.com/security/cve/CVE-2022-34917 https://bugzilla.redhat.com/show_bug.cgi?id=2130018 • CWE-770: Allocation of Resources Without Limits or Throttling CWE-789: Memory Allocation with Excessive Size Value •

CVSS: 5.9EPSS: 0%CPEs: 23EXPL: 0

Some components in Apache Kafka use `Arrays.equals` to validate a password or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. Users should upgrade to 2.8.1 or higher, or 3.0.0 or higher where this vulnerability has been fixed. The affected versions include Apache Kafka 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 2.5.0, 2.5.1, 2.6.0, 2.6.1, 2.6.2, 2.7.0, 2.7.1, and 2.8.0. Algunos componentes de Apache Kafka usan "Arrays.equals" para comprender una contraseña o clave, lo cual es vulnerable a ataques de tiempo que hacen que los ataques de fuerza bruta para dichas credenciales tengan más probabilidades de éxito. Los usuarios deben actualizar a la versión 2.8.1 o superior, o a la 3.0.0 o superior, donde se ha corregido esta vulnerabilidad. • https://kafka.apache.org/cve-list https://lists.apache.org/thread.html/r26390c8b09ecfa356582d665b0c01f4cdcf16ac047c85f9f9f06a88c%40%3Cdev.kafka.apache.org%3E https://lists.apache.org/thread.html/r26390c8b09ecfa356582d665b0c01f4cdcf16ac047c85f9f9f06a88c%40%3Cusers.kafka.apache.org%3E https://lists.apache.org/thread.html/r35322aec467ddae34002690edaa4d9f16e7df9b5bf7164869b75b62c%40%3Cdev.kafka.apache.org%3E https://lists.apache.org/thread.html/r45cc0602d5f2cbb72e48896dfadf5e5b87ed85630449598b40e8f0be%40%3Cdev.kafka.apache.org%3E https://lists.apache.org/thread.html/r45c • CWE-203: Observable Discrepancy CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition •

CVSS: 5.8EPSS: 1%CPEs: 27EXPL: 0

In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. En Eclipse Jetty versión 9.4.0.RC0 hasta 9.4.34.v20201102, 10.0.0.alpha0 hasta 10.0.0.beta2 y 11.0.0.alpha0 hasta 11.0.0.beta2, si la inflación del cuerpo de la petición GZIP está habilitada y solicita de diferentes clientes se multiplexan en una sola conexión, y si un atacante puede enviar una petición con un cuerpo que es recibido por completo pero no consumido por la aplicación, entonces una petición posterior en la misma conexión verá ese cuerpo antepuesto a su cuerpo. El atacante no verá ningún dato, pero puede inyectar datos en el cuerpo de la petición posterior • https://bugs.eclipse.org/bugs/show_bug.cgi?id=568892 https://github.com/eclipse/jetty.project/security/advisories/GHSA-86wm-rrjm-8wh8 https://lists.apache.org/thread.html/r00858fe27ee35ac8fa0e1549d67e0efb789d63b791b5300390bd8480%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r01806ad8c9cb0590584baf5b1a60237ad92e4ad5bba082ca04d98179%40%3Creviews.spark.apache.org%3E https://lists.apache.org/thread.html/r05b7ffde2b8c180709e14bc9ca036407bea3ed9f09b32c4705d23a4a%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r078c120 • CWE-226: Sensitive Information in Resource Not Removed Before Reuse •