deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7wwv-79xw-rvvg
Package: com.vaadin:vaadin (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 24.0.0, < 24.8.14
Patched in: 24.8.14

Summary: Vaadin vulnerable to Cross-site Scripting

Details:
Action captions in Vaadin accept HTML by default but were not sanitized, potentially allowing Cross-site Scripting (XSS) if caption content is derived from user input.

In Vaadin Framework 7 and 8, the Action class is a general-purpose class that may be used by multiple components. The fixed versions sanitize captions by default and provide an API to explicitly enable HTML content mode for backwards compatibility.

In Vaadin 23 and newer, the Action class is only used by the Spreadsheet component. The fixed versions sanitize HTML using Jsoup with a relaxed safelist.

Vaadin 14 is not affected as Spreadsheet component was not supported.

Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:

Product version
Vaadin 7.0.0 - 7.7.49
Vaadin 8.0.0 - 8.29.1
Vaadin 23.1.0 - 23.6.5
Vaadin 24.0.0 - 24.8.13
Vaadin 24.9.0 - 24.9.6

Mitigation
Upgrade to 7.7.50
Upgrade to 8.30.0
Upgrade to 23.6.6
Upgrade to 24.8.14 or 24.9.7
Upgrade to 25.0.0 or newer

Artifacts     Maven coordinatesVulnerable versionsFixed versioncom.vaadin:vaadin-server
7.0.0 - 7.7.49
≥7.7.50
com.vaadin:vaadin-server
8.0.0 - 8.29.1
≥8.30.0
com.vaadin:vaadin
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin24.9.0 - 24.9.6
≥24.9.7
com.vaadin:vaadin-spreadsheet-flow
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin-spreadsheet-flow
24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin-spreadsheet-flow
24.9.0 - 24.9.6
≥24.9.7
GitHub Security Advisory: GHSA-7wwv-79xw-rvvg
Package: com.vaadin:vaadin (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 23.1.0, < 23.6.6
Patched in: 23.6.6

Summary: Vaadin vulnerable to Cross-site Scripting

Details:
Action captions in Vaadin accept HTML by default but were not sanitized, potentially allowing Cross-site Scripting (XSS) if caption content is derived from user input.

In Vaadin Framework 7 and 8, the Action class is a general-purpose class that may be used by multiple components. The fixed versions sanitize captions by default and provide an API to explicitly enable HTML content mode for backwards compatibility.

In Vaadin 23 and newer, the Action class is only used by the Spreadsheet component. The fixed versions sanitize HTML using Jsoup with a relaxed safelist.

Vaadin 14 is not affected as Spreadsheet component was not supported.

Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:

Product version
Vaadin 7.0.0 - 7.7.49
Vaadin 8.0.0 - 8.29.1
Vaadin 23.1.0 - 23.6.5
Vaadin 24.0.0 - 24.8.13
Vaadin 24.9.0 - 24.9.6

Mitigation
Upgrade to 7.7.50
Upgrade to 8.30.0
Upgrade to 23.6.6
Upgrade to 24.8.14 or 24.9.7
Upgrade to 25.0.0 or newer

Artifacts     Maven coordinatesVulnerable versionsFixed versioncom.vaadin:vaadin-server
7.0.0 - 7.7.49
≥7.7.50
com.vaadin:vaadin-server
8.0.0 - 8.29.1
≥8.30.0
com.vaadin:vaadin
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin24.9.0 - 24.9.6
≥24.9.7
com.vaadin:vaadin-spreadsheet-flow
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin-spreadsheet-flow
24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin-spreadsheet-flow
24.9.0 - 24.9.6
≥24.9.7
GitHub Security Advisory: GHSA-7wwv-79xw-rvvg
Package: com.vaadin:vaadin-server (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 8.0.0, < 8.30.0
Patched in: 8.30.0

Summary: Vaadin vulnerable to Cross-site Scripting

Details:
Action captions in Vaadin accept HTML by default but were not sanitized, potentially allowing Cross-site Scripting (XSS) if caption content is derived from user input.

In Vaadin Framework 7 and 8, the Action class is a general-purpose class that may be used by multiple components. The fixed versions sanitize captions by default and provide an API to explicitly enable HTML content mode for backwards compatibility.

In Vaadin 23 and newer, the Action class is only used by the Spreadsheet component. The fixed versions sanitize HTML using Jsoup with a relaxed safelist.

Vaadin 14 is not affected as Spreadsheet component was not supported.

Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:

Product version
Vaadin 7.0.0 - 7.7.49
Vaadin 8.0.0 - 8.29.1
Vaadin 23.1.0 - 23.6.5
Vaadin 24.0.0 - 24.8.13
Vaadin 24.9.0 - 24.9.6

Mitigation
Upgrade to 7.7.50
Upgrade to 8.30.0
Upgrade to 23.6.6
Upgrade to 24.8.14 or 24.9.7
Upgrade to 25.0.0 or newer

Artifacts     Maven coordinatesVulnerable versionsFixed versioncom.vaadin:vaadin-server
7.0.0 - 7.7.49
≥7.7.50
com.vaadin:vaadin-server
8.0.0 - 8.29.1
≥8.30.0
com.vaadin:vaadin
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin24.9.0 - 24.9.6
≥24.9.7
com.vaadin:vaadin-spreadsheet-flow
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin-spreadsheet-flow
24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin-spreadsheet-flow
24.9.0 - 24.9.6
≥24.9.7
GitHub Security Advisory: GHSA-7wwv-79xw-rvvg
Package: com.vaadin:vaadin-server (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 7.0.0, < 7.7.50
Patched in: 7.7.50

Summary: Vaadin vulnerable to Cross-site Scripting

Details:
Action captions in Vaadin accept HTML by default but were not sanitized, potentially allowing Cross-site Scripting (XSS) if caption content is derived from user input.

In Vaadin Framework 7 and 8, the Action class is a general-purpose class that may be used by multiple components. The fixed versions sanitize captions by default and provide an API to explicitly enable HTML content mode for backwards compatibility.

In Vaadin 23 and newer, the Action class is only used by the Spreadsheet component. The fixed versions sanitize HTML using Jsoup with a relaxed safelist.

Vaadin 14 is not affected as Spreadsheet component was not supported.

Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:

Product version
Vaadin 7.0.0 - 7.7.49
Vaadin 8.0.0 - 8.29.1
Vaadin 23.1.0 - 23.6.5
Vaadin 24.0.0 - 24.8.13
Vaadin 24.9.0 - 24.9.6

Mitigation
Upgrade to 7.7.50
Upgrade to 8.30.0
Upgrade to 23.6.6
Upgrade to 24.8.14 or 24.9.7
Upgrade to 25.0.0 or newer

Artifacts     Maven coordinatesVulnerable versionsFixed versioncom.vaadin:vaadin-server
7.0.0 - 7.7.49
≥7.7.50
com.vaadin:vaadin-server
8.0.0 - 8.29.1
≥8.30.0
com.vaadin:vaadin
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin24.9.0 - 24.9.6
≥24.9.7
com.vaadin:vaadin-spreadsheet-flow
23.1.0 - 23.6.5
≥23.6.6
com.vaadin:vaadin-spreadsheet-flow
24.0.0 - 24.8.13
≥24.8.14
com.vaadin:vaadin-spreadsheet-flow
24.9.0 - 24.9.6
≥24.9.7
GitHub Security Advisory: GHSA-5r2g-vphf-m5xc
Package: org.apache.streampipes:streampipes-parent (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: >= 0.69.0, < 0.98.0
Patched in: 0.98.0

Summary: Apache StreamPipes has Improper Privilege Management issue

Details:
A user with a legitimate non-administrator account can exploit a vulnerability in the user ID creation mechanism in Apache StreamPipes that allows them to swap the username of an existing user with that of an administrator. 

This vulnerability allows an attacker to gain administrative control over the application by manipulating JWT tokens, which can lead to data tampering, unauthorized access and other security issues.

This issue affects Apache StreamPipes: through 0.97.0.

Users are recommended to upgrade to version 0.98.0, which fixes the issue.
GitHub Security Advisory: GHSA-9623-mj7j-p9v4
Package: io.quarkus:quarkus-vertx (MAVEN)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: >= 3.21.0.CR1, <= 3.24.0
Patched in: 3.24.1

Summary: Quarkus potentially leaks data when duplicating a duplicated context

Details:
### Impact

Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.

Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.

Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.

In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data. 

This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. 

A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:

- Quarkus REST Client when using OTel (but it's the same transaction, so no leak)
- Quarkus Messaging connectors
- Quarkus SmallRye Health (same transaction, so no leak)



### Patches

After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.

### Workarounds

When duplicating a duplicated context, the following code can be done to avoid the potential leak:

```java
((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()
```

This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work. 


### References

This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.
GitHub Security Advisory: GHSA-9623-mj7j-p9v4
Package: io.quarkus:quarkus-vertx (MAVEN)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: >= 3.16.0.CR1, <= 3.20.1
Patched in: 3.20.2

Summary: Quarkus potentially leaks data when duplicating a duplicated context

Details:
### Impact

Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.

Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.

Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.

In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data. 

This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. 

A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:

- Quarkus REST Client when using OTel (but it's the same transaction, so no leak)
- Quarkus Messaging connectors
- Quarkus SmallRye Health (same transaction, so no leak)



### Patches

After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.

### Workarounds

When duplicating a duplicated context, the following code can be done to avoid the potential leak:

```java
((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()
```

This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work. 


### References

This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.
GitHub Security Advisory: GHSA-9623-mj7j-p9v4
Package: io.quarkus:quarkus-vertx (MAVEN)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: <= 3.15.5
Patched in: 3.15.6

Summary: Quarkus potentially leaks data when duplicating a duplicated context

Details:
### Impact

Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.

Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.

Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.

In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data. 

This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. 

A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:

- Quarkus REST Client when using OTel (but it's the same transaction, so no leak)
- Quarkus Messaging connectors
- Quarkus SmallRye Health (same transaction, so no leak)



### Patches

After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.

### Workarounds

When duplicating a duplicated context, the following code can be done to avoid the potential leak:

```java
((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()
```

This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work. 


### References

This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.
GitHub Security Advisory: GHSA-vc5p-v9hr-52mj
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.0-beta9, < 2.25.3
Patched in: 2.25.3

Summary: Apache Log4j does not verify the TLS hostname in its Socket Appender

Details:
The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the  [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName)  configuration attribute or the  [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true.

This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:

  *  The attacker is able to intercept or redirect network traffic between the client and the log receiver.
  *  The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured).


Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.

As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.
GitHub Security Advisory: GHSA-v4p2-2w39-mhrj
Package: org.apache.nifi:nifi-asana-processors (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 1.20.0, < 2.7.0
Patched in: 2.7.0

Summary: Apache NiFi GetAsanaObject Processor has Remote Code Execution via Unsafe Deserialization

Details:
Apache NiFi 1.20.0 through 2.6.0 include the GetAsanaObject Processor, which requires integration with a configurable Distribute Map Cache Client Service for storing and retrieving state information. The GetAsanaObject Processor used generic Java Object serialization and deserialization without filtering. Unfiltered Java object deserialization does not provide protection against crafted state information stored in the cache server configured for GetAsanaObject. Exploitation requires an Apache NiFi system running with the GetAsanaObject Processor, and direct access to the configured cache server. Upgrading to Apache NiFi 2.7.0 is the recommended mitigation, which replaces Java Object serialization with JSON serialization. Removing the GetAsanaObject Processor located in the nifi-asana-processors-nar bundle also prevents exploitation.
GitHub Security Advisory: GHSA-gphj-4h6p-37xq
Package: org.elasticsearch.plugin:x-pack-core (MAVEN)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 9.2.0, < 9.2.2
Patched in: 9.2.2

Summary: Elasticsearch privileged authenticated users can cause DoS through Excessive Resource Allocation 

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.
GitHub Security Advisory: GHSA-gphj-4h6p-37xq
Package: org.elasticsearch.plugin:x-pack-core (MAVEN)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 9.0.0, < 9.1.8
Patched in: 9.1.8

Summary: Elasticsearch privileged authenticated users can cause DoS through Excessive Resource Allocation 

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.
GitHub Security Advisory: GHSA-gphj-4h6p-37xq
Package: org.elasticsearch.plugin:x-pack-core (MAVEN)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 8.19.8
Patched in: 8.19.8

Summary: Elasticsearch privileged authenticated users can cause DoS through Excessive Resource Allocation 

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.
GitHub Security Advisory: GHSA-qf7c-7r9h-mm92
Package: org.elasticsearch.plugin:x-pack-security (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 9.2.0, < 9.2.3
Patched in: 9.2.3

Summary: Elasticsearch has Excessive Allocation of Resources via Submission of Oversized User Settings Data

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.
GitHub Security Advisory: GHSA-qf7c-7r9h-mm92
Package: org.elasticsearch.plugin:x-pack-security (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 9.0.0, < 9.1.9
Patched in: 9.1.9

Summary: Elasticsearch has Excessive Allocation of Resources via Submission of Oversized User Settings Data

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.
GitHub Security Advisory: GHSA-qf7c-7r9h-mm92
Package: org.elasticsearch.plugin:x-pack-security (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 8.19.9
Patched in: 8.19.9

Summary: Elasticsearch has Excessive Allocation of Resources via Submission of Oversized User Settings Data

Details:
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.
GitHub Security Advisory: GHSA-43xg-8wmj-cw8h
Package: org.apache.spark:spark-core_2.10 (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 3.2.2
Patched in: unpatched

Summary: Apache Spark vulnerable to Log Injection

Details:
A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.
GitHub Security Advisory: GHSA-43xg-8wmj-cw8h
Package: org.apache.spark:spark-core_2.11 (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 3.2.2
Patched in: unpatched

Summary: Apache Spark vulnerable to Log Injection

Details:
A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.
GitHub Security Advisory: GHSA-43xg-8wmj-cw8h
Package: org.apache.spark:spark-core_2.12 (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: = 3.3.0
Patched in: 3.3.1

Summary: Apache Spark vulnerable to Log Injection

Details:
A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.
GitHub Security Advisory: GHSA-43xg-8wmj-cw8h
Package: org.apache.spark:spark-core_2.12 (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 3.2.2
Patched in: 3.2.2

Summary: Apache Spark vulnerable to Log Injection

Details:
A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.
GitHub Security Advisory: GHSA-43xg-8wmj-cw8h
Package: org.apache.spark:spark-core_2.13 (MAVEN)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: = 3.3.0
Patched in: 3.3.1

Summary: Apache Spark vulnerable to Log Injection

Details:
A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.