deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.0.0-M1, <= 1.0.0-M30
Patched in: unpatched

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.12 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.23.0, < 0.23.17
Patched in: 0.23.17

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.12 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.22.0, < 0.22.15
Patched in: 0.22.15

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.12 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.1.0, < 0.21.34
Patched in: 0.21.34

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.11 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.1.0, <= 0.21.0-M1
Patched in: unpatched

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.10 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.1.0, <= 0.9.3
Patched in: unpatched

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.13 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.0.0-M1, < 1.0.0-M38
Patched in: 1.0.0-M38

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.13 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.23.0, < 0.23.17
Patched in: 0.23.17

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.13 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.22.0, < 0.22.15
Patched in: 0.22.15

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-54w6-vxfh-fw7f
Package: org.http4s:http4s-core_2.13 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 0.1.0, < 0.21.34
Patched in: 0.21.34

Summary: Http4s improperly parses User-Agent and Server headers

Details:
### Impact

The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs.  In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. 

#### v0.21.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`)
```

#### v0.22.x, v0.23.x, v1.x

```scala
val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`]
val alsoUnsafe: Option[`Server`] = req.headers.get[Server]
```

### Patches

Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38.

### Workarounds

#### Use the weakly typed header interface

##### v0.21.x

```scala
val safe: Option[Header] = req.headers.get("User-Agent".ci)
// but don't do this
val unsafe = header.map(_.parsed) 
```

##### v0.22.x, v0.23.x, v1.x

```scala
val safe: Option[Header] = req.headers.get(ci"User-Agent")
```
GitHub Security Advisory: GHSA-62g2-m955-v383
Package: org.apache.spark:spark-core_2.10 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.3.0, <= 2.1.3
Patched in: unpatched

Summary: Improper Input Validation in Apache Spark

Details:
Spark's Apache Maven-based build includes a convenience script, 'build/mvn', that downloads and runs a zinc server to speed up compilation. It has been included in release branches since 1.3.x, up to and including master. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. **Note that this issue does not affect end users of Spark, only developers building Spark from source code.**
GitHub Security Advisory: GHSA-62g2-m955-v383
Package: org.apache.spark:spark-core_2.11 (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.3.0, <= 2.1.3
Patched in: unpatched

Summary: Improper Input Validation in Apache Spark

Details:
Spark's Apache Maven-based build includes a convenience script, 'build/mvn', that downloads and runs a zinc server to speed up compilation. It has been included in release branches since 1.3.x, up to and including master. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. **Note that this issue does not affect end users of Spark, only developers building Spark from source code.**
GitHub Security Advisory: GHSA-76qp-h5mr-frr4
Package: org.apache.kafka:kafka_2.13 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.4.0, < 3.9.1
Patched in: 3.9.1

Summary: Apache Kafka Deserialization of Untrusted Data vulnerability

Details:
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.
GitHub Security Advisory: GHSA-76qp-h5mr-frr4
Package: org.apache.kafka:kafka_2.12 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.3.0, < 3.9.1
Patched in: 3.9.1

Summary: Apache Kafka Deserialization of Untrusted Data vulnerability

Details:
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.
GitHub Security Advisory: GHSA-76qp-h5mr-frr4
Package: org.apache.kafka:kafka_2.11 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.3.0, <= 2.4.1
Patched in: unpatched

Summary: Apache Kafka Deserialization of Untrusted Data vulnerability

Details:
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.
GitHub Security Advisory: GHSA-mcwh-c9pg-xw43
Package: org.apache.kafka:kafka_2.9.2 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.4.0
Patched in: unpatched

Summary: Apache Kafka Deserialization of Untrusted Data vulnerability

Details:
In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource.


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 3.4.0, and "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" is disabled by default in in Apache Kafka 3.9.1/4.0.0
GitHub Security Advisory: GHSA-mcwh-c9pg-xw43
Package: org.apache.kafka:kafka_2.9.1 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.4.0
Patched in: unpatched

Summary: Apache Kafka Deserialization of Untrusted Data vulnerability

Details:
In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource.


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 3.4.0, and "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" is disabled by default in in Apache Kafka 3.9.1/4.0.0