deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-44f4-gvwj-6qg3
Package: org.springframework.ai:spring-ai-redis-store (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 1.1.0-M1, < 1.1.4
Patched in: 1.1.4

Summary: Spring AI Redis Store has TAG Field Query Injection Through Improper Neutralization of Special Characters

Details:
In RedisFilterExpressionConverter of spring-ai-redis-store, when a user-controlled string is passed as a filter value for a TAG field, stringValue() inserts the value directly into the @field:{VALUE} RediSearch TAG block without escaping characters. This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-44f4-gvwj-6qg3
Package: org.springframework.ai:spring-ai-redis-store (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 1.0.0-M5, < 1.0.5
Patched in: 1.0.5

Summary: Spring AI Redis Store has TAG Field Query Injection Through Improper Neutralization of Special Characters

Details:
In RedisFilterExpressionConverter of spring-ai-redis-store, when a user-controlled string is passed as a filter value for a TAG field, stringValue() inserts the value directly into the @field:{VALUE} RediSearch TAG block without escaping characters. This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-7cj7-rcw6-p68v
Package: org.springframework.ai:spring-ai-neo4j-store (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 1.1.0-M1, < 1.1.4
Patched in: 1.1.4

Summary: Spring AI has a Cypher Injection vulnerability in Neo4jVectorFilterExpressionConverter

Details:
Spring AI's spring-ai-neo4j-store contains a Cypher injection vulnerability in Neo4jVectorFilterExpressionConverter. When a user-controlled string is passed as a filter expression key in Neo4jVectorFilterExpressionConverter of spring-ai-neo4j-store, doKey() embeds the key into a backtick-delimited Cypher property accessor (node.`metadata.`) after stripping only double quotes, without escaping embedded backticks. This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-7cj7-rcw6-p68v
Package: org.springframework.ai:spring-ai-neo4j-store (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 1.0.0-M5, < 1.0.5
Patched in: 1.0.5

Summary: Spring AI has a Cypher Injection vulnerability in Neo4jVectorFilterExpressionConverter

Details:
Spring AI's spring-ai-neo4j-store contains a Cypher injection vulnerability in Neo4jVectorFilterExpressionConverter. When a user-controlled string is passed as a filter expression key in Neo4jVectorFilterExpressionConverter of spring-ai-neo4j-store, doKey() embeds the key into a backtick-delimited Cypher property accessor (node.`metadata.`) after stripping only double quotes, without escaping embedded backticks. This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-mhrg-94vw-45c5
Package: org.springframework.ai:spring-ai-bedrock-converse (MAVEN)
Severity: HIGH (CVSS 8.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 1.1.0-M1, < 1.1.4
Patched in: 1.1.4

Summary: Spring AI: Insufficient Validation causes SSRF when processing multimodal messages with user-supplied URLs

Details:
Spring AI's spring-ai-bedrock-converse contains a Server-Side Request Forgery (SSRF) vulnerability in BedrockProxyChatModel when processing multimodal messages that include user-supplied media URLs. Insufficient validation of those URLs allows an attacker to induce the server to issue HTTP requests to unintended internal or external destinations.

This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-mhrg-94vw-45c5
Package: org.springframework.ai:spring-ai-bedrock-converse (MAVEN)
Severity: HIGH (CVSS 8.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 1.0.0-M5, < 1.0.5
Patched in: 1.0.5

Summary: Spring AI: Insufficient Validation causes SSRF when processing multimodal messages with user-supplied URLs

Details:
Spring AI's spring-ai-bedrock-converse contains a Server-Side Request Forgery (SSRF) vulnerability in BedrockProxyChatModel when processing multimodal messages that include user-supplied media URLs. Insufficient validation of those URLs allows an attacker to induce the server to issue HTTP requests to unintended internal or external destinations.

This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-fvh3-672c-7p6c
Package: org.springframework.ai:spring-ai-vector-store (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
Vulnerable versions: >= 1.1.0-M1, < 1.1.4
Patched in: 1.1.4

Summary: Spring AI: SpEL injection is triggered when a user-supplied value is used as a filter expression key

Details:
In Spring AI, a SpEL injection vulnerability exists in SimpleVectorStore when a user-supplied value is used as a filter expression key. A malicious actor could exploit this to execute arbitrary code. Only applications that use SimpleVectorStore and pass user-supplied input as a filter expression key are affected.

This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-fvh3-672c-7p6c
Package: org.springframework.ai:spring-ai-vector-store (MAVEN)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
Vulnerable versions: >= 1.0.0, < 1.0.5
Patched in: 1.0.5

Summary: Spring AI: SpEL injection is triggered when a user-supplied value is used as a filter expression key

Details:
In Spring AI, a SpEL injection vulnerability exists in SimpleVectorStore when a user-supplied value is used as a filter expression key. A malicious actor could exploit this to execute arbitrary code. Only applications that use SimpleVectorStore and pass user-supplied input as a filter expression key are affected.

This issue affects Spring AI: from 1.0.0 before 1.0.5, from 1.1.0 before 1.1.4.
GitHub Security Advisory: GHSA-x27p-5f68-m644
Package: io.trino:trino-iceberg (MAVEN)
Severity: HIGH (CVSS 7.7)
CWE: CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: >= 439, < 480
Patched in: 480

Summary: Trino: Iceberg REST catalog static and vended credentials are accessible via query JSON

Details:
### Summary

Iceberg connector REST catalog static credentials (access key) or vended credentials (temporary access key) are accessible to users that have write privilege on SQL level.

### Details

Iceberg REST catalog typically needs access to object storage. This access can be configured in multiple different ways. When storage access is achieved by static credentials (e.g. AWS S3 access key) or vended credentials (temporary access key).

Query JSON is a query visualization and performance troubleshooting facility. It includes serialized query plan and handles for table writes or  execution of table procedures. A user that submitted a query has access to query JSON for their query. Query JSON is available from Trino UI or via `/ui/api/query/«query_id»` and `/v1/query/«query_id»` endpoints.

The storage credentials are stored in those handles when performing write operations, or table maintenance operations. They are serialized in query JSON. A user with write access to data in Iceberg connector configured to use REST Catalog with static or vended credentials can retrieve those credentials.

### Impact

Anyone using Iceberg REST catalog with static or vended credentials is impacted.
The credentials should be considered compromised. 
Vended credentials are temporary in nature so they do not need to be rotated. However, underlying data could have been exposed.
GitHub Security Advisory: GHSA-x4ff-q6h8-v7gw
Package: org.scala-sbt:sbt (MAVEN)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 0.9.5, < 1.12.7
Patched in: 1.12.8

Summary: sbt: Source dependency feature (via crafted VCS URL) leads to arbitrary code execution on Windows

Details:
### Summary
On Windows, sbt uses `Process("cmd", "/c", ...)` to run VCS commands (git, hg, svn). The URI fragment (branch, tag, revision) is user-controlled via the build definition and passed to these commands without validation. Because `cmd /c` interprets `&`, `|`, and `;` as command separators, a malicious fragment can execute arbitrary commands.

### Patched version

Technically, sbt 1.12.7 is patched, but it has a bug that makes source dependency non-functional, so update to **sbt 1.12.8** or later instead.

### Details
- [Resolvers.scala L84–95](https://github.com/sbt/sbt/blob/dc90f160dfb563f46fd1a7b97945c381d15e2a6c/main/src/main/scala/sbt/Resolvers.scala#L84-L95) — git resolver passes `uri.getFragment()` to `run()` without sanitization
- [Resolvers.scala L137–145](https://github.com/sbt/sbt/blob/dc90f160dfb563f46fd1a7b97945c381d15e2a6c/main/src/main/scala/sbt/Resolvers.scala#L137-L145) — `run()` uses `Process("cmd", "/c", ...)` on Windows, so `cmd` interprets `&&` as command separator

### PoC
```sh
# build.properties
# sbt.version=1.12.5  # Tested on those two versions of sbt
sbt.version=2.0.0-RC9
```

```scala
// build.sbt

ThisBuild / scalaVersion := "2.12.19"

lazy val root = project
  .in(file("."))
  .dependsOn(vulnerable)

lazy val vulnerable = RootProject(
  uri("https://github.com/sbt/io.git#develop%26%26calc.exe")
)
```

### Impact

Windows users are impacted. An attacker can execute arbitrary Windows commands if they control the dependency URI.
GitHub Security Advisory: GHSA-3x3v-w654-m28m
Package: io.undertow:undertow-core (MAVEN)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.4.0.Beta1
Patched in: 2.4.0.Beta1

Summary: Undertow: Denial of Service via Multipart/Form-Data Parsing on HTTP GET Requests

Details:
A flaw was found in Undertow. A remote attacker could exploit this vulnerability by sending an HTTP GET request containing multipart/form-data content. If the underlying application processes parameters using methods like `getParameterMap()`, the server prematurely parses and stores this content to disk. This could lead to resource exhaustion, potentially resulting in a Denial of Service (DoS).
GitHub Security Advisory: GHSA-443w-3rq3-5m5h
Package: software.amazon.awssdk:cloudfront (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 2.18.33, <= 2.41.29
Patched in: 2.41.30

Summary: AWS SDK for Java 2.0: Improper Handling of Special Characters in CloudFront Signing Utilities

Details:
### Summary
This notification is related to the [CloudFront signing utilities](https://github.com/aws/aws-sdk-java-v2/blob/master/services/cloudfront/src/main/java/software/amazon/awssdk/services/cloudfront/CloudFrontUtilities.java) in the AWS SDK for Java v2, which are used to generate Amazon CloudFront signed URLs and signed cookies. A defense-in-depth enhancement has been implemented to improve handling of special characters, such as double quotes and backslashes, in input values.
### Impact
The CloudFront signing utilities build policy documents that define access restrictions for signed URLs and cookies. If an application passes unsanitized input containing special characters to these utilities, the resulting policy document may not reflect the application's intended access restrictions. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations. Applications that already follow AWS security best practices for input validation are not impacted.
### Impacted versions: 
2.18.33 - 2.41.29
### Patches
On 2026.02.16, an enhancement was made to AWS SDK for Java v2 version 2.41.30. The enhancement ensures that special characters in input values are correctly handled. We recommend upgrading to the latest version.
### Workarounds
No workarounds are needed, but customers should ensure that your application is following security best practices:

* Implement proper input validation in your application code before passing values to CloudFront signing utilities
* Update to the latest AWS SDK release on a regular basis
* Follow [AWS security best practices for SDK configuration](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/security.html)

### Resources
If there are any questions or comments about this advisory, contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
### Acknowledgement
AWS SDK for Java 2.0 thanks the Amazon Inspector Security Research team for identifying this issue and working with us through the coordinated process.
GitHub Security Advisory: GHSA-5458-7hh9-v7p4
Package: org.pf4j:pf4j (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-23: Relative Path Traversal
Vulnerable versions: < 3.14.1
Patched in: 3.14.1

Summary: pf4j is vulnerable to Path Traversal or Zip Slip attack through improper handling of zip entry names 

Details:
pf4j before 20c2f80 has a path traversal vulnerability in the extract() function of Unzip.java, where improper handling of zip entry names can allow directory traversal or Zip Slip attacks, due to a lack of proper path normalization and validation.
GitHub Security Advisory: GHSA-2r4x-667f-mpfh
Package: org.apache.seata:seata-config-core (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.0.0, < 2.2.0
Patched in: 2.2.0

Summary: Apache Seata Vulnerable to Deserialization of Untrusted Data

Details:
Deserialization of Untrusted Data vulnerability in Apache Seata (incubating).

This issue affects Apache Seata (incubating): from 2.0.0 before 2.2.0.

Users are recommended to upgrade to version 2.2.0, which fixes the issue.
GitHub Security Advisory: GHSA-w9fj-cfpg-grvv
Package: io.netty:netty-codec-http2 (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.2.0.Alpha1, < 4.2.10.Final
Patched in: 4.2.11.Final

Summary: Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass

Details:
### Summary
A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.

### Details
The vulnerability exists in Netty's `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.

The key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.

Any user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 < currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.

`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`

**`verifyContinuationFrame()` (lines 381-393)** — No frame count check:
```java
private void verifyContinuationFrame() throws Http2Exception {
    verifyAssociatedWithAStream();
    if (headersContinuation == null) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    if (streamId != headersContinuation.getStreamId()) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    // NO frame count limit!
}
```

**`HeadersBlockBuilder.addFragment()` (lines 695-723)** — Byte limit bypassed by 0-byte frames:
```java
// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
        headerBlock.readableBytes()) {
    headerSizeExceeded();  // 10240 - 0 < 1 => FALSE always
}
```

When `len=0`: `maxGoAway - 0 < readableBytes` → `10240 < 1` → FALSE. The byte limit is never triggered.

### Impact
This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
GitHub Security Advisory: GHSA-w9fj-cfpg-grvv
Package: io.netty:netty-codec-http2 (MAVEN)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.1.132.Final
Patched in: 4.1.132.Final

Summary: Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass

Details:
### Summary
A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.

### Details
The vulnerability exists in Netty's `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.

The key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.

Any user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 < currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.

`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`

**`verifyContinuationFrame()` (lines 381-393)** — No frame count check:
```java
private void verifyContinuationFrame() throws Http2Exception {
    verifyAssociatedWithAStream();
    if (headersContinuation == null) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    if (streamId != headersContinuation.getStreamId()) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    // NO frame count limit!
}
```

**`HeadersBlockBuilder.addFragment()` (lines 695-723)** — Byte limit bypassed by 0-byte frames:
```java
// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
        headerBlock.readableBytes()) {
    headerSizeExceeded();  // 10240 - 0 < 1 => FALSE always
}
```

When `len=0`: `maxGoAway - 0 < readableBytes` → `10240 < 1` → FALSE. The byte limit is never triggered.

### Impact
This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
GitHub Security Advisory: GHSA-f4gc-mwrg-q36r
Package: org.apache.activemq:artemis-openwire-protocol (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.0.0, < 2.53.0
Patched in: 2.53.0

Summary: Apache Artemis: Unauthorized Temporary Address Creation via OpenWire Protocol

Details:
Incorrect Authorization (CWE-863) vulnerability in Apache Artemis, Apache ActiveMQ Artemis exists when an application using the OpenWire protocol attempts to create a non-durable JMS topic subscription on an address that doesn't exist with an authenticated user which has the "createDurableQueue" permission but does not have the "createAddress" permission and address auto-creation is disabled. In this circumstance, a temporary address will be created whereas the attempt to create the non-durable subscription should instead fail since the user is not authorized to create the corresponding address. When the OpenWire connection is closed the address is removed.

This issue affects Apache Artemis: from 2.50.0 through 2.52.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.

Users are recommended to upgrade to version 2.53.0, which fixes the issue.
GitHub Security Advisory: GHSA-f4gc-mwrg-q36r
Package: org.apache.artemis:artemis-openwire-protocol (MAVEN)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.50.0, < 2.53.0
Patched in: 2.53.0

Summary: Apache Artemis: Unauthorized Temporary Address Creation via OpenWire Protocol

Details:
Incorrect Authorization (CWE-863) vulnerability in Apache Artemis, Apache ActiveMQ Artemis exists when an application using the OpenWire protocol attempts to create a non-durable JMS topic subscription on an address that doesn't exist with an authenticated user which has the "createDurableQueue" permission but does not have the "createAddress" permission and address auto-creation is disabled. In this circumstance, a temporary address will be created whereas the attempt to create the non-durable subscription should instead fail since the user is not authorized to create the corresponding address. When the OpenWire connection is closed the address is removed.

This issue affects Apache Artemis: from 2.50.0 through 2.52.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.

Users are recommended to upgrade to version 2.53.0, which fixes the issue.