deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3gmf-p6r4-q8m6
Package: org.apache.wicket:wicket-core (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 10.0.0-M1, <= 10.8.0
Patched in: 10.9.0

Summary: Apache Wicket has a Path Traversal issue

Details:
FolderUploadsFileManager in Apache Wicket does not validate or sanitize the uploadFieldId parameter or the clientFileName
 before constructing file paths, allowing an unauthenticated attacker to
 write arbitrary files outside the intended upload directory or read 
files from arbitrary locations on the server.

This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0.

Users are recommended to upgrade to version 10.9.0, which fixes the issue.
GitHub Security Advisory: GHSA-3gmf-p6r4-q8m6
Package: org.apache.wicket:wicket-core (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 9.0.0-M1, <= 9.22.0
Patched in: unpatched

Summary: Apache Wicket has a Path Traversal issue

Details:
FolderUploadsFileManager in Apache Wicket does not validate or sanitize the uploadFieldId parameter or the clientFileName
 before constructing file paths, allowing an unauthenticated attacker to
 write arbitrary files outside the intended upload directory or read 
files from arbitrary locations on the server.

This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0.

Users are recommended to upgrade to version 10.9.0, which fixes the issue.
GitHub Security Advisory: GHSA-3gmf-p6r4-q8m6
Package: org.apache.wicket:wicket-core (MAVEN)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 8.0.0-M1, <= 8.17.0
Patched in: unpatched

Summary: Apache Wicket has a Path Traversal issue

Details:
FolderUploadsFileManager in Apache Wicket does not validate or sanitize the uploadFieldId parameter or the clientFileName
 before constructing file paths, allowing an unauthenticated attacker to
 write arbitrary files outside the intended upload directory or read 
files from arbitrary locations on the server.

This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0.

Users are recommended to upgrade to version 10.9.0, which fixes the issue.
GitHub Security Advisory: GHSA-3g76-f9xq-8vp6
Package: io.vertx:vertx-core (MAVEN)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: >= 5.0.0, <= 5.0.8
Patched in: unpatched

Summary: Vert.x has a DoS via unbounded server-side SNI SslContext cache growth

Details:
Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with possible resource-exhaustion / DoS impact.

On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache, and I could not find any bound, TTL, or eviction for that cache.

The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.8`:
- `4.3.x`: `SSLHelper`
- `4.4.x` / `4.5.x`: `SslChannelProvider`
- `5.0.x` and current `master`: `SslContextProvider`

It appears that when server-side SNI is enabled, and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions.

A check was performed on the related TCP SNI path across affected versions, the QUIC SNI path on `5.x`, and the wildcard hostname resolution helpers used during certificate selection.

## Steps to reproduce

1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`.
2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule.
3. Send repeated connections with distinct matching SNI values.
4. Observe that the SNI cache size grows with the number of unique matching names.

Local observations:
- initial `sniEntrySize()` = `0`
- after 20 unique matching names: `20`
- after 40 unique matching names: `40`
- repeating previously seen matching names did not grow the cache further
- non-matching SNI names did not create new cache entries

## What are the affected versions?

Affected released versions confirmed on `origin`:
- `4.3.4` through `4.3.8`
- `4.4.0` through `4.4.9`
- `4.5.0` through `4.5.25`
- `5.0.0` through `5.0.8`

Not affected by the same sink:
- `4.0.x` through `4.2.x`
- `4.3.0` through `4.3.3`

## Are there any ways to mitigate this issue?

- Disable server-side SNI if it is not needed.
- Avoid wildcard or otherwise high-cardinality hostname mappings where feasible.
- Apply connection or rate limiting in front of the service.
GitHub Security Advisory: GHSA-3g76-f9xq-8vp6
Package: io.vertx:vertx-core (MAVEN)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: >= 4.5.0, <= 4.5.25
Patched in: unpatched

Summary: Vert.x has a DoS via unbounded server-side SNI SslContext cache growth

Details:
Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with possible resource-exhaustion / DoS impact.

On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache, and I could not find any bound, TTL, or eviction for that cache.

The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.8`:
- `4.3.x`: `SSLHelper`
- `4.4.x` / `4.5.x`: `SslChannelProvider`
- `5.0.x` and current `master`: `SslContextProvider`

It appears that when server-side SNI is enabled, and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions.

A check was performed on the related TCP SNI path across affected versions, the QUIC SNI path on `5.x`, and the wildcard hostname resolution helpers used during certificate selection.

## Steps to reproduce

1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`.
2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule.
3. Send repeated connections with distinct matching SNI values.
4. Observe that the SNI cache size grows with the number of unique matching names.

Local observations:
- initial `sniEntrySize()` = `0`
- after 20 unique matching names: `20`
- after 40 unique matching names: `40`
- repeating previously seen matching names did not grow the cache further
- non-matching SNI names did not create new cache entries

## What are the affected versions?

Affected released versions confirmed on `origin`:
- `4.3.4` through `4.3.8`
- `4.4.0` through `4.4.9`
- `4.5.0` through `4.5.25`
- `5.0.0` through `5.0.8`

Not affected by the same sink:
- `4.0.x` through `4.2.x`
- `4.3.0` through `4.3.3`

## Are there any ways to mitigate this issue?

- Disable server-side SNI if it is not needed.
- Avoid wildcard or otherwise high-cardinality hostname mappings where feasible.
- Apply connection or rate limiting in front of the service.
GitHub Security Advisory: GHSA-3g76-f9xq-8vp6
Package: io.vertx:vertx-core (MAVEN)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: >= 4.4.0, <= 4.4.9
Patched in: unpatched

Summary: Vert.x has a DoS via unbounded server-side SNI SslContext cache growth

Details:
Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with possible resource-exhaustion / DoS impact.

On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache, and I could not find any bound, TTL, or eviction for that cache.

The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.8`:
- `4.3.x`: `SSLHelper`
- `4.4.x` / `4.5.x`: `SslChannelProvider`
- `5.0.x` and current `master`: `SslContextProvider`

It appears that when server-side SNI is enabled, and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions.

A check was performed on the related TCP SNI path across affected versions, the QUIC SNI path on `5.x`, and the wildcard hostname resolution helpers used during certificate selection.

## Steps to reproduce

1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`.
2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule.
3. Send repeated connections with distinct matching SNI values.
4. Observe that the SNI cache size grows with the number of unique matching names.

Local observations:
- initial `sniEntrySize()` = `0`
- after 20 unique matching names: `20`
- after 40 unique matching names: `40`
- repeating previously seen matching names did not grow the cache further
- non-matching SNI names did not create new cache entries

## What are the affected versions?

Affected released versions confirmed on `origin`:
- `4.3.4` through `4.3.8`
- `4.4.0` through `4.4.9`
- `4.5.0` through `4.5.25`
- `5.0.0` through `5.0.8`

Not affected by the same sink:
- `4.0.x` through `4.2.x`
- `4.3.0` through `4.3.3`

## Are there any ways to mitigate this issue?

- Disable server-side SNI if it is not needed.
- Avoid wildcard or otherwise high-cardinality hostname mappings where feasible.
- Apply connection or rate limiting in front of the service.
GitHub Security Advisory: GHSA-3g76-f9xq-8vp6
Package: io.vertx:vertx-core (MAVEN)
Severity: MODERATE (CVSS 5.3)
Vulnerable versions: >= 4.3.4, <= 4.3.8
Patched in: unpatched

Summary: Vert.x has a DoS via unbounded server-side SNI SslContext cache growth

Details:
Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with possible resource-exhaustion / DoS impact.

On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache, and I could not find any bound, TTL, or eviction for that cache.

The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.8`:
- `4.3.x`: `SSLHelper`
- `4.4.x` / `4.5.x`: `SslChannelProvider`
- `5.0.x` and current `master`: `SslContextProvider`

It appears that when server-side SNI is enabled, and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions.

A check was performed on the related TCP SNI path across affected versions, the QUIC SNI path on `5.x`, and the wildcard hostname resolution helpers used during certificate selection.

## Steps to reproduce

1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`.
2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule.
3. Send repeated connections with distinct matching SNI values.
4. Observe that the SNI cache size grows with the number of unique matching names.

Local observations:
- initial `sniEntrySize()` = `0`
- after 20 unique matching names: `20`
- after 40 unique matching names: `40`
- repeating previously seen matching names did not grow the cache further
- non-matching SNI names did not create new cache entries

## What are the affected versions?

Affected released versions confirmed on `origin`:
- `4.3.4` through `4.3.8`
- `4.4.0` through `4.4.9`
- `4.5.0` through `4.5.25`
- `5.0.0` through `5.0.8`

Not affected by the same sink:
- `4.0.x` through `4.2.x`
- `4.3.0` through `4.3.3`

## Are there any ways to mitigate this issue?

- Disable server-side SNI if it is not needed.
- Avoid wildcard or otherwise high-cardinality hostname mappings where feasible.
- Apply connection or rate limiting in front of the service.
GitHub Security Advisory: GHSA-g8r3-5hwf-qp96
Package: com.oviva.telematik:epa4all-client (MAVEN)
Severity: HIGH (CVSS 8.1)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 1.2.0
Patched in: 1.2.1

Summary: epa4all-client has a VAU Signature bypass

Details:
### Impact
In SignedPublicKeysTrustValidatorImpl.isTrusted(), the ECDSA signature verification at line 45 discards the boolean return value of Signature.verify(). The method performs certificate chain validation, OCSP check, and signature algorithm setup, but never checks whether the signature actually matches. For any structurally valid signature, it returns true.

### Patches
Patched in [#34](https://github.com/oviva-ag/epa4all-client/pull/34).

### Workarounds
None.

### Resources
- [MS-OVIVA-EPA4ALL-d76aec](https://www.machinespirits.com/advisory/d76aec/)

### Credits

[Machine Spirits](https://machinespirits.com) (contact@machinespirits.de)
- Dr. rer. nat. Simon Weber
- Dipl.-Inf. Volker Schönefeld
- Chiara Fliegner
GitHub Security Advisory: GHSA-7pwc-h2j2-rjgj
Package: org.apache.thrift:libthrift (MAVEN)
Severity: HIGH (CVSS 7.3)
CWE: CWE-297: Improper Validation of Certificate with Host Mismatch
Vulnerable versions: <= 0.22.0
Patched in: unpatched

Summary: Apache Thrift has an Improper Validation of Certificate with Host Mismatch Vulnerability

Details:
Improper Validation of Certificate with Host Mismatch vulnerability in Apache Thrift.

This issue affects Apache Thrift: before 0.23.0.

Users are recommended to upgrade to version [0.23.0](https://github.com/apache/thrift/releases/tag/v0.23.0), which fixes the issue.
GitHub Security Advisory: GHSA-fc3h-c6h7-r83j
Package: org.apache.polaris:polaris-core (MAVEN)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.4.1
Patched in: 1.4.1

Summary: Apache Polaris has an Improper Input Validation issue

Details:
In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials that only work for one table's files, but a crafted namespace or table name can cause those credentials to work across the configured bucket instead.

Apache Polaris builds Google Cloud Storage downscoped credentials by creating a Credential Access Boundary (CAB) with CEL conditions that are intended to restrict access to the requested table's storage path.

The relevant CEL string is built from the bucket name and the table path. That table path is derived from namespace and table identifiers. In current code, that path appears to be inserted into the CEL expression without escaping.

As a result, a namespace or table identifier containing a single quote and other URI-safe CEL fragments can break out of the intended quoted string and change the meaning of the CEL condition.

In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated GCS credentials whose CEL path restriction had effectively collapsed.

Those delegated credentials could then:
- list another table's object prefix
- read another table's metadata control file (Iceberg metadata JSON);
- create and delete an object under another table's object prefix;
- and also list, read, create, and delete objects under an unrelated external prefix in the same bucket that was not part of any table path.

That last point is important. The issue is not limited to "another table". In the confirmed setup, once Apache Polaris returned credentials for the crafted table, the path restriction inside the configured bucket was effectively gone.

The practical effect is that temporary credentials for one crafted table can be broader than the table Polaris was asked to authorize, and can become effectively bucket-wide within the configured bucket.

The current GCS testing used a Polaris principal with broad catalog privileges for setup. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage-credential broadening behavior itself has been confirmed on GCS.
GitHub Security Advisory: GHSA-vxgg-mqx2-3w59
Package: org.apache.polaris:polaris-core (MAVEN)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.4.1
Patched in: 1.4.1

Summary: Apache Polaris has an Improper Input Validation Issue

Details:
Apache Polaris accepts literal `*` characters in namespace and table names. When it later builds temporary S3 access policies for delegated table access, those same characters appear to be reused unescaped in S3 IAM resource patterns and `s3:prefix` conditions.

In S3 IAM policy matching, `*` is treated as a wildcard rather than as ordinary text. That means temporary credentials issued for one crafted table can match the storage path of a different table.

In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-credential path on both MinIO and real AWS S3, credentials returned for crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other tables' S3 locations.


The confirmed behavior includes:
- reading another table's metadata control file ([Iceberg metadata JSON]);
- listing another table's exact S3 table prefix ([table prefix]);
- and, when write delegation was returned for the crafted table, creating and deleting an object under another table's exact S3 table prefix.

A control case using ordinary different names did not allow the same cross-table access.

A least-privilege AWS S3 variant was also confirmed in which the attacker principal had no Polaris permissions on the victim table and only the minimal permissions required to create and use a crafted wildcard table (namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that setup, direct Polaris access to `foo.t1` remained forbidden, but the attacker could still create and load `*.*`, receive delegated S3 credentials, and use those credentials to list, read, create, and delete objects under `foo.t1`.

In Iceberg, the metadata JSON file is a control file: it tells readers which data files belong to the table, which snapshots exist, and which table version to read. So unauthorized access to it is already a meaningful confidentiality problem. The confirmed write-capable variant means the issue is not limited to disclosure.
GitHub Security Advisory: GHSA-8ggj-j522-h5qf
Package: org.apache.polaris:polaris-runtime-service (MAVEN)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.4.1
Patched in: 1.4.1

Summary: Apache Polaris has an Improper Input Validation Issue

Details:
Apache Polaris can issue broad temporary ("vended") storage credentials during staged table creation before the effective table location has been validated or durably reserved. Those temporary credentials are meant to limit the scope of accessible table data and metadata, but this scope limitation becomes attacker-directed because the attacker can choose a reachable target location.

In the confirmed variant, if the caller supplies a custom `location` during stage create and requests credential vending, Apache Polaris uses that location to construct delegated storage credentials immediately. The stage-create path itself neither runs the normal location validation nor the overlap checks before those credentials are issued.

Closely related to that, the staged-create flow also accepts `write.data.path` / `write.metadata.path` in the request properties and
feeds those location overrides into the same effective table location set used for credential vending. Those fields are secondary to the main custom-`location` exploit, but they are still attacker-influenced location inputs that should be validated before any credentials are issued.
GitHub Security Advisory: GHSA-659w-93r5-9j6m
Package: org.apache.opennlp:opennlp-tools (MAVEN)
Severity: HIGH (CVSS 7.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 3.0.0-M1, < 3.0.0-M3
Patched in: 3.0.0-M3

Summary: Apache OpenNLP AbstractModelReader has an OOM Denial of Service via Unbounded Array Allocation

Details:
OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader 

Versions Affected: 

Before 2.5.9

Before 3.0.0-M3 

Description:


The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUM_PREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source.


A crafted .bin model file in which any of these count fields is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load.


The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.  


Mitigation:



  *  2.x users should upgrade to 2.5.9.

  *  3.x users should upgrade to 3.0.0-M3.




Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default.


Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.