deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-445c-vh5m-36rj
Package: org.apache.logging.log4j:log4j-core (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-117: Improper Output Neutralization for Logs, CWE-684: Incorrect Provision of Specified Functionality
Vulnerable versions: >= 2.21.0, < 2.25.4
Patched in: 2.25.4

Summary: Apache Log4j Core: log injection in `Rfc5424Layout` due to silent configuration incompatibility

Details:
Apache Log4j Core's [`Rfc5424Layout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout), in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF sequences due to undocumented renames of security-relevant configuration attributes.

Two distinct issues affect users of stream-based syslog services who configure Rfc5424Layout directly:

  *  The `newLineEscape` attribute was silently renamed, causing newline escaping to stop working for users of TCP framing (RFC 6587), exposing them to CRLF injection in log output.
  *  The `useTlsMessageFormat` attribute was silently renamed, causing users of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), without newline escaping.

Users of the `SyslogAppender` are not affected, as its configuration attributes were not modified.

Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
GitHub Security Advisory: GHSA-6hg6-v5c8-fphq
Package: org.apache.logging.log4j:log4j-core (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-297: Improper Validation of Certificate with Host Mismatch
Vulnerable versions: >= 3.0.0-alpha1, <= 3.0.0-beta3
Patched in: unpatched

Summary: Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration

Details:
The fix for  CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `<Ssl>` element.

Although the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.

A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:

  *  An SMTP, Socket, or Syslog appender is in use.
  *  TLS is configured via a nested <Ssl> element.
  *  The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured.

This issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.

Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
GitHub Security Advisory: GHSA-6hg6-v5c8-fphq
Package: org.apache.logging.log4j:log4j-core (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-297: Improper Validation of Certificate with Host Mismatch
Vulnerable versions: >= 2.12.0, < 2.25.4
Patched in: 2.25.4

Summary: Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration

Details:
The fix for  CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `<Ssl>` element.

Although the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.

A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:

  *  An SMTP, Socket, or Syslog appender is in use.
  *  TLS is configured via a nested <Ssl> element.
  *  The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured.

This issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.

Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
GitHub Security Advisory: GHSA-h383-gmxw-35v2
Package: org.apache.logging.log4j:log4j-1.2-api (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 3.0.0-beta1, <= 3.0.0-beta2
Patched in: unpatched

Summary: Apache Log4j 1 to Log4j 2 bridge: silent log event loss in Log4j1XmlLayout due to unescaped XML 1.0 forbidden characters

Details:
The `Log4j1XmlLayout` from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.

Two groups of users are affected:

* Those using `Log4j1XmlLayout` directly in a Log4j Core 2 configuration file.
* Those using the Log4j 1 configuration compatibility layer with `org.apache.log4j.xml.XMLLayout` specified as the layout class.

Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version `2.25.4`, which corrects this issue.

> [!NOTE]
> The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the
> [Log4j 1 to Log4j 2 migration guide](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html), and specifically the section on eliminating reliance on the bridge.
GitHub Security Advisory: GHSA-h383-gmxw-35v2
Package: org.apache.logging.log4j:log4j-1.2-api (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 2.7, < 2.25.4
Patched in: 2.25.4

Summary: Apache Log4j 1 to Log4j 2 bridge: silent log event loss in Log4j1XmlLayout due to unescaped XML 1.0 forbidden characters

Details:
The `Log4j1XmlLayout` from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.

Two groups of users are affected:

* Those using `Log4j1XmlLayout` directly in a Log4j Core 2 configuration file.
* Those using the Log4j 1 configuration compatibility layer with `org.apache.log4j.xml.XMLLayout` specified as the layout class.

Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version `2.25.4`, which corrects this issue.

> [!NOTE]
> The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the
> [Log4j 1 to Log4j 2 migration guide](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html), and specifically the section on eliminating reliance on the bridge.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty:jetty-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 9.4.0, <= 9.4.60
Patched in: 9.4.61

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty:jetty-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 10.0.0, <= 10.0.28
Patched in: 10.0.29

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty:jetty-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 11.0.0, <= 11.0.28
Patched in: 11.0.29

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee8:jetty-ee8-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.0.0, <= 12.0.33
Patched in: 12.0.34

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee9:jetty-ee9-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.0.0, <= 12.0.33
Patched in: 12.0.34

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee10:jetty-ee10-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.0.0, <= 12.0.33
Patched in: 12.0.34

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee11:jetty-ee11-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.0.0, <= 12.0.33
Patched in: 12.0.34

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee8:jetty-ee8-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.1.0, <= 12.1.7
Patched in: 12.1.8

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee9:jetty-ee9-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.1.0, <= 12.1.7
Patched in: 12.1.8

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee10:jetty-ee10-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.1.0, <= 12.1.7
Patched in: 12.1.8

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-r7p8-xq5m-436c
Package: org.eclipse.jetty.ee11:jetty-ee11-jaspi (MAVEN)
Severity: HIGH (CVSS 7.4)
CWE: CWE-226: Sensitive Information in Resource Not Removed Before Reuse, CWE-287: Improper Authentication
Vulnerable versions: >= 12.1.0, <= 12.1.7
Patched in: 12.1.8

Summary: Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables

Details:
### Description (as reported)

A security vulnerability has been identified in Jetty's  `JaspiAuthenticator.java`. 

The root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. 
Specifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely — before the  `ThreadLocal`  storage is cleared — if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. 
This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

### Impact
An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

### Patches
No patches yet.

### Workarounds
Do not use Jetty's JASPI.
GitHub Security Advisory: GHSA-w35j-pv5h-q9q9
Package: org.apache.logging.log4j:log4j-layout-template-json (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 3.0.0-alpha1, <= 3.0.0-beta3
Patched in: unpatched

Summary: Apache Log4j JSON Template Layout: Improper serialization of non-finite floating-point values in JsonTemplateLayout

Details:
Apache Log4j's [`JsonTemplateLayout`](https://logging.apache.org/log4j/2.x/manual/json-template-layout.html), in versions up to and including 2.25.3, produces invalid JSON output when log events contain non-finite floating-point values (`NaN`, `Infinity`, or `-Infinity`), which are prohibited by RFC 8259. This may cause downstream log processing systems to reject or fail to index affected records.

An attacker can exploit this issue only if both of the following conditions are met:

  *  The application uses `JsonTemplateLayout`.
  *  The application logs a `MapMessage` containing an attacker-controlled floating-point value.

Users are advised to upgrade to Apache Log4j JSON Template Layout 2.25.4, which corrects this issue.