deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6xvm-j4wr-6v98
Package: quinn-proto (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 0.11.14
Patched in: 0.11.14

Summary: Quinn affected by unauthenticated remote DoS via panic in QUIC transport parameter parsing

Details:
### Summary
A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable `quinn` versions by sending a crafted QUIC Initial packet containing malformed `quic_transport_parameters`. `In quinn-proto` parsing logic, attacker-controlled varints are decoded with `unwrap()`, so truncated encodings cause `Err(UnexpectedEnd)` and `panic`. This is reachable over the network with a single packet and no prior trust or authentication.

### Details
The issue is panic-on-untrusted-input in QUIC transport parameter parsing.
In `quinn-proto` (observed in `quinn-proto 0.11.13`), parsing of some transport parameters uses a fallible varint decode followed by `unwrap()`. For malformed/truncated parameter values, decode returns `UnexpectedEnd`, and `unwrap()` panics.

#### Observed output:
```
thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd
```

### PoC
#### Reproduces against the upstream Quinn server example.
1. Start server:
```
cargo run --example server -- ./
```
2. Prepare PoC client environment:
```
python3 -m venv .venv
source .venv/bin/activate
pip install aioquic
```
3. Run PoC script [attack.py](https://github.com/user-attachments/files/25741713/attack.py) against server QUIC listener (default example target shown):
```
python attack.py
```
#### Observed output
```
thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd
```



### Impact
Vulnerability type: Remote Denial of Service (panic/crash)
Attack requirements:  Network reachability to UDP QUIC listener
Authentication/privileges: None
Who is impacted: Any server/application using affected `quinn/quinn-proto` versions where this parse path is reachable; process-level impact depends on integration panic handling policy


This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program
GitHub Security Advisory: GHSA-9c4h-pwmf-m6fj
Package: rssn (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-15: External Control of System or Configuration Setting, CWE-20: Improper Input Validation, CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-269: Improper Privilege Management, CWE-695: Use of Low-Level Functionality
Vulnerable versions: < 0.2.9
Patched in: 0.2.9

Summary: RSSN has Arbitrary Code Execution via Unvalidated JIT Instruction Generation in C-FFI Interface

Details:
## Impact

**Vulnerability Type**: 
Improper Control of Generation of Code ('Code Injection') (CWE-94) / Improper Check for Unusual or Exceptional Conditions (CWE-754) / Improper Input Validation (CWE-20) / Use of Low-Level Functionality (CWE-695) / Improper Privilege Management (CWE-269) / External Control of System or Configuration Setting (CWE-15).

**Technical Details**:
The vulnerability exists in the JIT (Just-In-Time) compilation engine, which is fully exposed via the CFFI (Foreign Function Interface). Due to Improper Input Validation and External Control of Code Generation, an attacker can supply malicious parameters or instruction sequences through the CFFI layer. Since the library often operates with elevated privileges or within high-performance computing contexts, this allows for Arbitrary Code Execution (ACE) at the privilege level of the host process.

## Who is Impacted?

 * Developers using the library as a dynamic linked library (.so, .dll, .dylib) in multi-language environments (e.g., Python, Node.js, C++).
 * Cloud Service Providers running the library in multi-tenant environments or automated model-training pipelines.
 * Users processing untrusted or third-party datasets/models that may trigger malicious JIT instruction generation.
Patches
 * Affected versions: < 0.2.8
 * Patched version: 0.2.9

## Workarounds

If you cannot upgrade immediately, please consider the following mitigations:
 * Strict Sandboxing: Run the library within a restricted sandbox (e.g., WebAssembly, Docker with non-root user, or seccomp profiles) to limit system call access.
 * Principle of Least Privilege: Ensure the process calling the library does not have administrative or root privileges.
 * Input Filtering: If possible, implement an application-level validation layer to sanitize any data passed to the CFFI interfaces.
 * Disable JIT (if applicable): If your workload allows, use the interpreter-only mode (if provided by the library) to bypass the JIT engine entirely.
CVSS Score
 * Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
 * Base Score: 9.4 (Critical)

## References

[Apich Organization Security Team Homepage](https://security.apich.org/)
GitHub Security Advisory: GHSA-pm4j-7r4q-ccg8
Package: soroban-env-host (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-681: Incorrect Conversion between Numeric Types
Vulnerable versions: < 26.0.0
Patched in: 26.0.0

Summary: Soroban: Muxed address<->ScVal conversions may break after a conversion failure

Details:
### Summary

Soroban host ensures that `MuxedAddress` objects can't be used as storage keys in order to proactively prevent the contract logic bugs. However, due to a bug in Soroban host implementation, a failure in `Val`->`ScVal` conversion during the storage key computation will have the flag indicating that storage conversion is happening stuck in the `true` state until the next storage access. While the flag is stuck in `true` state, any `MuxedAddress` object conversions to `ScVal` will fail, i.e. a failure will occur if a `MuxedAddress` is emitted in the event or is serialized to XDR via a host function.

### Impact

The bug may cause unexpected contract failures in the rare edge case scenarios. In the worst case scenario the whole transaction will fail and the changes will be rolled back. Because the contract call is simply rolled back, there is no risk of the state corruption.

An example scenario that would be affected by the bug is as follows:

- Contract A calls contract B via `try_call`
- Contract B calls a storage function (e.g. `put_contract_data`) with a non-convertible `Val` as a key (e.g. a `MuxedAddress` object, or a deeply nested vector)
- Contract B fails
- Contract A handles the failure gracefully and proceeds without accessing any storage methods
- Contract A tries to emit an event with a `MuxedAddress` argument. That should be allowed, but instead of succeeding, contract A fails.

### Patches

The bug will be fixed in protocol 26.

### Workarounds

We believe that the bug is highly unlikely to occur in practice, as it involves three rare events happening simultaneously: `Val` conversion failure (these should normally not occur for the audited protocols), graceful handling of a cross-contract call failure (most protocols need cross-contract calls to succeed, or fail with a contract error), and `MuxedAddress` write (most of the contracts don't support `MuxedAddress` at all).

In the case if the bug does occur, the mitigation depends on the reason of the value conversion failure:

- If the conversion failure has been caused by a malicious contract, then either no action is necessary (because the whole interaction is malicious and has been correctly rolled back), or the contract invocation should be replaced by a non-malicious contract
- If the conversion failure has been caused by a bad user input for a non-malicious contract (e.g. a bad user input passed to a legitimate protocol), then the user input has to be fixed

In both scenarios the mitigation is to basically retry the transaction with proper arguments.
GitHub Security Advisory: GHSA-mh23-rw7f-v5pq
Package: time-sync (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `time-sync` was removed from crates.io due to malicious code

Details:
The `time-sync` crate attempted to exfiltrate `.env` files to a server that was in turn impersonating the legitimate `timeapi.io` service. This the same attack that we've seen three times in the last few days.

The malicious crate had 1 version published on 2026-03-04 approximately 50 minutes before removal and had no evidence of actual downloads. There were no crates depending on this crate on crates.io.
GitHub Security Advisory: GHSA-f93w-pcj3-rggc
Package: pingora-cache (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 0.7.0
Patched in: 0.8.0

Summary: Pingora vulnerable to cache poisoning via insecure-by-default cache key

Details:
### Impact
Pingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.

This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for cross-tenant data leakage in multi-tenant deployments, or serve malicious content to legitimate users by poisoning shared cache entries.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.

### Patches
We strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation.

### Workarounds
Do not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method. 

### References
See [CVE-2026-2836](https://cve.org/CVERecord?id=CVE-2026-2836) and the [Cloudflare blog post](https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/) for more details.

### Credits
Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare [Bug Bounty Program](https://www.cloudflare.com/disclosure/).
GitHub Security Advisory: GHSA-2m8c-2374-465f
Package: pingora-cache (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Duplicate Advisory: Cache poisoning via insecure-by-default cache key

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-f93w-pcj3-rggc. This link is maintained to preserve external references.

### Original Description
A cache poisoning vulnerability has been found in the Pingora HTTP proxy framework’s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.


Impact

This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for:

  *  Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant


  *  Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries




Cloudflare's CDN infrastructure was not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.


Mitigation:

We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.


Pingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer’s HTTP scheme.
GitHub Security Advisory: GHSA-hj7x-879w-vrp7
Package: pingora-core (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 0.7.0
Patched in: 0.8.0

Summary: Pingora has HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing

Details:
### Impact
Pingora versions prior to 0.8.0 improperly allowed HTTP/1.0 request bodies to be close-delimited and incorrectly handled multiple Transfer-Encoding values. This allows an attacker to desync Pingora's request framing from backend servers and smuggle requests to the backend.

This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as its ingress proxy layers rejected ambiguous framing such as invalid Content-Length values and internally forwarded non-ambiguous message length framing headers.

### Patches
Pingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited (commits 7f7166d62fa916b9f11b2eb8f9e3c4999e8b9023, 40c3c1e9a43a86b38adeab8da7a2f6eba68b83ad, and 87e2e2fb37edf9be33e3b1d04726293ae6bf2052).

### Workarounds
As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact “chunked” string match.

### References
See [CVE-2026-2835](https://www.cve.org/CVERecord?id=CVE-2026-2835) and the [Cloudflare blog post](https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/) for more details.

### Credits
Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare [Bug Bounty Program](https://www.cloudflare.com/disclosure/).
GitHub Security Advisory: GHSA-262p-vjx5-45xh
Package: pingora-core (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Duplicate Advisory: HTTP Request Smuggling via HTTP/1.0 and Transfer-Encoding Misparsing

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-hj7x-879w-vrp7. This link is maintained to preserve external references.

### Original Description
An HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora's parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora’s request framing from backend servers’.

Impact

This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:

  *  Bypass proxy-level ACL controls and WAF logic




  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests




  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP




Cloudflare's CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.


Mitigation:

Pingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.

As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact “chunked” string match.
GitHub Security Advisory: GHSA-xq2h-p299-vjwv
Package: pingora-core (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 0.7.0
Patched in: 0.8.0

Summary: Pingora vulnerable to HTTP Request Smuggling via Premature Upgrade

Details:
### Impact
Pingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.

### Patches
Pingora users should upgrade to Pingora v0.8.0 or higher, which fixes this issue by only switching connection modes after receiving a 101 Switching Protocols response from the backend (hash 824bdeefc61e121cc8861de1b35e8e8f39026ecd). Without a 101 response, subsequent bytes continue to be parsed as HTTP requests.

### Workarounds
As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.

### References
See [CVE-2026-2833](https://www.cve.org/cverecord?id=CVE-2026-2833) and the [Cloudflare blog post](https://blog.cloudflare.com/pingora-oss-smuggling-vulnerabilities/) for more details.

### Credits
Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare [Bug Bounty Program](https://www.cloudflare.com/disclosure/).
GitHub Security Advisory: GHSA-f9v3-j2m7-4hpg
Package: pingora-core (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Duplicate Advisory: HTTP Request Smuggling via Premature Upgrade

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-xq2h-p299-vjwv. This link is maintained to preserve external references.

### Original Description
An HTTP request smuggling vulnerability (CWE-444) was found in Pingora's handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.

Impact

This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:

  *  Bypass proxy-level ACL controls and WAF logic




  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests




  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP




Cloudflare's CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.


Mitigation:

Pingora users should upgrade to Pingora v0.8.0 or higher


As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.
GitHub Security Advisory: GHSA-x57h-xx53-v53w
Package: stellar-xdr (RUST)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 25.0.0
Patched in: 25.0.1

Summary: stellar-xdr's StringM::from_str bypasses max length validation

Details:
### Impact

`StringM::from_str` does not validate that the input length is within the declared maximum (`MAX`). Calling `StringM::<N>::from_str(s)` where `s` is longer than `N` bytes succeeds and returns an `Ok` value instead of `Err(Error::LengthExceedsMax)`, producing a `StringM` that violates its length invariant.

This affects any code that constructs `StringM` values from string input using `FromStr` (including `str::parse`), and relies on the type's maximum length constraint being enforced. An oversized `StringM` could propagate through serialization, validation, or other logic that assumes the invariant holds.

All published versions of the `stellar-xdr` crate up to and including `v25.0.0` are affected.

### Patches

The fix is merged in [#500](https://github.com/stellar/rs-stellar-xdr/pull/500). It replaces the direct `Ok(Self(b))` construction with `b.try_into()`, which routes through `TryFrom<Vec<u8>>` and properly validates the length — matching the pattern already used by `BytesM::from_str`.

Users should upgrade to the first release containing this fix once published (the next release after `v25.0.0`).

### Workarounds

Validate the byte length of string input before calling `StringM::from_str`, or construct `StringM` values via `StringM::try_from(s.as_bytes().to_vec())` which correctly enforces the length constraint.

### References

- Issue: https://github.com/stellar/rs-stellar-xdr/issues/499
- Fix: https://github.com/stellar/rs-stellar-xdr/pull/500
GitHub Security Advisory: GHSA-xhw7-jhmp-j62j
Package: dnp3times (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: `dnp3times` was removed from crates.io due to malicious code

Details:
The `dnp3times` crate attempted to exfiltrate `.env` files to a server that was in turn impersonating the legitimate `timeapi.io` service. It was loosely trying to typosquat the `dnp3time` crate, but otherwise was the same attack as the recent `time_calibrator` and `time_calibrators` malware.

The malicious crate had 1 version published on 2026-03-04 approximately 6 hours before removal and had no evidence of actual downloads. There were no crates depending on this crate on crates.io.