deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qqj3-g7mx-5p4w
Package: github.com/neuvector/neuvector (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-295: Improper Certificate Validation, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.4.0, <= 5.4.6
Patched in: 5.4.7

Summary: NeuVector telemetry sender is vulnerable to MITM and DoS

Details:
### Impact
This vulnerability affects NeuVector deployments only when the `Report anonymous cluster data option` is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server at `https://upgrades.neuvector-upgrade-responder.livestock.rancher.io`.

In affected versions, NeuVector does not enforce TLS certificate verification when transmitting anonymous cluster data to the telemetry server. As a result, the communication channel is susceptible to man-in-the-middle (MITM) attacks, where an attacker could intercept or modify the transmitted data. Additionally, NeuVector loads the response of the telemetry server is loaded into memory without size limitation, which makes  it vulnerable to a Denial of Service(DoS) attack. 

The patched version includes the following security improvements:
- NeuVector now verifies the telemetry server’s `TLS certificate chain` and `hostname` during the handshake process. This ensures that all telemetry communications occur over a trusted and verified channel.
- NeuVector limits the telemetry server’s response to `256 bytes`, mitigating the risk of memory exhaustion and DoS attacks.

These security enhancements are enabled by default and require no user action.


### Patches
Patched versions include release **v5.4.7** and above.

### Workarounds
If you cannot update to a patched version, you can temporarily disable the Report anonymous cluster data, which is enabled by default in NeuVector.
To change this setting, go to **Settings** → **Configuration** → **Report anonymous cluster data** in the NeuVector UI.

Disabling this option prevents NeuVector from sending telemetry data to the telemetry server, which helps mitigate this vulnerability.


### References
If you have any questions or comments about this advisory:
- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).
GitHub Security Advisory: GHSA-qqj3-g7mx-5p4w
Package: github.com/neuvector/neuvector (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-295: Improper Certificate Validation, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.3.0, < 5.3.5
Patched in: 5.3.5

Summary: NeuVector telemetry sender is vulnerable to MITM and DoS

Details:
### Impact
This vulnerability affects NeuVector deployments only when the `Report anonymous cluster data option` is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server at `https://upgrades.neuvector-upgrade-responder.livestock.rancher.io`.

In affected versions, NeuVector does not enforce TLS certificate verification when transmitting anonymous cluster data to the telemetry server. As a result, the communication channel is susceptible to man-in-the-middle (MITM) attacks, where an attacker could intercept or modify the transmitted data. Additionally, NeuVector loads the response of the telemetry server is loaded into memory without size limitation, which makes  it vulnerable to a Denial of Service(DoS) attack. 

The patched version includes the following security improvements:
- NeuVector now verifies the telemetry server’s `TLS certificate chain` and `hostname` during the handshake process. This ensures that all telemetry communications occur over a trusted and verified channel.
- NeuVector limits the telemetry server’s response to `256 bytes`, mitigating the risk of memory exhaustion and DoS attacks.

These security enhancements are enabled by default and require no user action.


### Patches
Patched versions include release **v5.4.7** and above.

### Workarounds
If you cannot update to a patched version, you can temporarily disable the Report anonymous cluster data, which is enabled by default in NeuVector.
To change this setting, go to **Settings** → **Configuration** → **Report anonymous cluster data** in the NeuVector UI.

Disabling this option prevents NeuVector from sending telemetry data to the telemetry server, which helps mitigate this vulnerability.


### References
If you have any questions or comments about this advisory:
- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).
GitHub Security Advisory: GHSA-fj2x-735w-74vq
Package: github.com/consensys/gnark-crypto (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: = 0.19.0
Patched in: 0.19.2

Summary: gnark-crypto allows unchecked memory allocation during vector deserialization

Details:
The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report:
> A critical vulnerability exists in the gnark-crypto library's `Vector.ReadFrom()` function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service.
> ### **Root Cause**
> 
> 
> The vulnerability stems from **unchecked deserialization** of attacker-controlled length fields in the gnark-crypto library's `Vector.ReadFrom()` function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking.
> 
> ### **Vulnerable Code Path**
> 
> ```
> User Input (Malicious Proof/Data)
>          ↓
> gnark Proof/Data Deserialization
>          ↓
> Vector.ReadFrom() (ecc/bn254/fr/vector.go:136-144)
>   → sliceLen := binary.BigEndian.Uint32(buf[:4])   // ← ATTACKER-CONTROLLED
>   → (*vector) = make(Vector, sliceLen)             // ← UNCHECKED ALLOCATION
>          ↓
> runtime.makeslice attempts 100+ GB allocation
>          ↓
> fatal error: runtime: out of memory → SIGABRT
> 
> ```
>
> ### **Vulnerable Code**
> 
> **File**: [`gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144`](https://github.com/Consensys/gnark-crypto/blob/8310aae2de6104d3fe3610e3370b2bed10c63111/ecc/bn254/fr/vector.go#L136)
> 
> The code reads a 4-byte big-endian unsigned integer (`sliceLen`) directly from the input stream and uses it to allocate a slice without any bounds checking or validation. Each element is 32 bytes (fr.Element for BN254 curve), so an attacker can request up to:
> 
> **Maximum Allocation**: `2^32 elements × 32 bytes = 137,438,953,472 bytes ≈ 128 GB`
> 
> ## **Root Cause Analysis**
> 
> The gnark-crypto library implements a generic serialization format for field element vectors. The format is:
> 
> ```
> [4 bytes: length (n)] [n × 32 bytes: elements]
> ```
> 
> The deserialization code **trusts** the length field implicitly without any validation. This is a classic **integer-to-allocation vulnerability** pattern, similar to issues that have affected many serialization libraries over the years.

### Impact

The issue impacts users deserializing vectors directly from untrusted sources. In case of malicious input it would lead to OOM in case the server doesn't have sufficient memory (depending on the field, but could allocate from 32GB to 196GB).

### Patches

The issue is patched in https://github.com/Consensys/gnark-crypto/pull/759. It will be backported to gnark-crypto v0.18 and v0.19.

### Workarounds

The user could manually peek into the first 4 bytes of the serialized data to estimate if the header would allocate large amounts of memory.
GitHub Security Advisory: GHSA-fj2x-735w-74vq
Package: github.com/consensys/gnark-crypto (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.9.1, < 0.18.1
Patched in: 0.18.1

Summary: gnark-crypto allows unchecked memory allocation during vector deserialization

Details:
The issue has been reported by @raefko from @fuzzinglabs. Excerpts from the report:
> A critical vulnerability exists in the gnark-crypto library's `Vector.ReadFrom()` function that allows an attacker to trigger arbitrary memory allocation by crafting malicious input data. An attacker can cause the verifier to attempt allocating up to 128 GB of memory with a minimal malicious input, leading to out-of-memory crashes and denial of service.
> ### **Root Cause**
> 
> 
> The vulnerability stems from **unchecked deserialization** of attacker-controlled length fields in the gnark-crypto library's `Vector.ReadFrom()` function. The function reads a 4-byte unsigned integer from untrusted input and directly uses it to allocate memory without any validation or bounds checking.
> 
> ### **Vulnerable Code Path**
> 
> ```
> User Input (Malicious Proof/Data)
>          ↓
> gnark Proof/Data Deserialization
>          ↓
> Vector.ReadFrom() (ecc/bn254/fr/vector.go:136-144)
>   → sliceLen := binary.BigEndian.Uint32(buf[:4])   // ← ATTACKER-CONTROLLED
>   → (*vector) = make(Vector, sliceLen)             // ← UNCHECKED ALLOCATION
>          ↓
> runtime.makeslice attempts 100+ GB allocation
>          ↓
> fatal error: runtime: out of memory → SIGABRT
> 
> ```
>
> ### **Vulnerable Code**
> 
> **File**: [`gnark-crypto@v0.14.0+/ecc/bn254/fr/vector.go:136-144`](https://github.com/Consensys/gnark-crypto/blob/8310aae2de6104d3fe3610e3370b2bed10c63111/ecc/bn254/fr/vector.go#L136)
> 
> The code reads a 4-byte big-endian unsigned integer (`sliceLen`) directly from the input stream and uses it to allocate a slice without any bounds checking or validation. Each element is 32 bytes (fr.Element for BN254 curve), so an attacker can request up to:
> 
> **Maximum Allocation**: `2^32 elements × 32 bytes = 137,438,953,472 bytes ≈ 128 GB`
> 
> ## **Root Cause Analysis**
> 
> The gnark-crypto library implements a generic serialization format for field element vectors. The format is:
> 
> ```
> [4 bytes: length (n)] [n × 32 bytes: elements]
> ```
> 
> The deserialization code **trusts** the length field implicitly without any validation. This is a classic **integer-to-allocation vulnerability** pattern, similar to issues that have affected many serialization libraries over the years.

### Impact

The issue impacts users deserializing vectors directly from untrusted sources. In case of malicious input it would lead to OOM in case the server doesn't have sufficient memory (depending on the field, but could allocate from 32GB to 196GB).

### Patches

The issue is patched in https://github.com/Consensys/gnark-crypto/pull/759. It will be backported to gnark-crypto v0.18 and v0.19.

### Workarounds

The user could manually peek into the first 4 bytes of the serialized data to estimate if the header would allocate large amounts of memory.
GitHub Security Advisory: GHSA-cf57-c578-7jvv
Package: github.com/TecharoHQ/anubis (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 1.23.0
Patched in: 1.23.0

Summary: Anubis vulnerable to possible XSS via redir parameter when using subrequest auth mode

Details:
### Summary

When using subrequest authentication, Anubis did not perform validation of the redirect URL and redirects user to any URL scheme. While most modern browsers do not allow a redirect to `javascript:` URLs, it could still trigger dangerous behavior in some cases.

`GET https://example.com/.within.website/?redir=javascript:alert()` responds with `Location: javascript:alert()`.

### Impact

Anybody with a subrequest authentication seems affected. Using `javascript:` URLs will probably be blocked by most modern browsers, but using custom protocols for third-party applications might still trigger dangerous operations.

### Note

This was originally reported by @mbiesiad against Weblate.
GitHub Security Advisory: GHSA-cfjq-28r2-4jv5
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-308: Use of Single-factor Authentication
Vulnerable versions: >= 2.55.0, <= 2.71.17
Patched in: 2.71.18

Summary: Zitadel May Bypass Second Authentication Factor

Details:
### Summary

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified. 

### Impact

Zitadel provides an API for managing sessions, enabling custom login experiences in a dedicated UI or direct integration into applications. Session Tokens are issued for active sessions, which can be used as Bearer tokens to call the Zitadel API.

Starting from 2.55.0 (see other affected versions below), Zitadel only required multi factor authentication in case the login policy has either enabled `requireMFA` or `requireMFAForLocalUsers`. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors.

Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled.

### Affected Versions

Systems using the session API (v2 beta and v2) directly or via the new login UI in the following versions are affected:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.53.6` to `v2.53.9`,  `v2.54.3` to `v2.54.10`, `2.55.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring a configured second factor regardless of the login policies `requireMFA` or `requireMFAForLocalUsers` configuration.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-cfjq-28r2-4jv5
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-308: Use of Single-factor Authentication
Vulnerable versions: >= 2.54.3, <= 2.54.10
Patched in: unpatched

Summary: Zitadel May Bypass Second Authentication Factor

Details:
### Summary

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified. 

### Impact

Zitadel provides an API for managing sessions, enabling custom login experiences in a dedicated UI or direct integration into applications. Session Tokens are issued for active sessions, which can be used as Bearer tokens to call the Zitadel API.

Starting from 2.55.0 (see other affected versions below), Zitadel only required multi factor authentication in case the login policy has either enabled `requireMFA` or `requireMFAForLocalUsers`. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors.

Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled.

### Affected Versions

Systems using the session API (v2 beta and v2) directly or via the new login UI in the following versions are affected:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.53.6` to `v2.53.9`,  `v2.54.3` to `v2.54.10`, `2.55.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring a configured second factor regardless of the login policies `requireMFA` or `requireMFAForLocalUsers` configuration.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-cfjq-28r2-4jv5
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-308: Use of Single-factor Authentication
Vulnerable versions: >= 2.53.6, <= 2.53.9
Patched in: unpatched

Summary: Zitadel May Bypass Second Authentication Factor

Details:
### Summary

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified. 

### Impact

Zitadel provides an API for managing sessions, enabling custom login experiences in a dedicated UI or direct integration into applications. Session Tokens are issued for active sessions, which can be used as Bearer tokens to call the Zitadel API.

Starting from 2.55.0 (see other affected versions below), Zitadel only required multi factor authentication in case the login policy has either enabled `requireMFA` or `requireMFAForLocalUsers`. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors.

Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled.

### Affected Versions

Systems using the session API (v2 beta and v2) directly or via the new login UI in the following versions are affected:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.53.6` to `v2.53.9`,  `v2.54.3` to `v2.54.10`, `2.55.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring a configured second factor regardless of the login policies `requireMFA` or `requireMFAForLocalUsers` configuration.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-xrw9-r35x-x878
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts
Vulnerable versions: < 2.71.18
Patched in: 2.71.18

Summary: Zitadel allows brute-forcing authentication factors

Details:
### Summary

A vulnerability in Zitadel allowed brute-force attack on OTP, TOTP and password allowing to impersonate the attacked user.

### Impact

An attacker can perform an online brute-force attack on OTP, TOTP, and passwords. While Zitadel allows preventing online brute force attacks in scenarios like TOTP, Email OTP, or passwords using a lockout mechanism. The mechanism is not enabled by default and can cause a denial of service for the corresponding user if enabled. Additionally, the mitigation strategies were not fully implemented in the more recent resource-based APIs.

### Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected:
- **4.x**: `4.0.0` to `4.4.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.0.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the lockout policy on all OTP, TOTP and password checks. Additionally a “tar pit” has been introduced to slow down brute-force attacks by default. Zitadel responses will be delayed by t seconds, where t increases over the number of failed attempts within a given timeframe.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

The problem might be mitigated by enabling the optional logout policy ("Password maximum attempts") or by implementing more strict rate limits.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-qh7p-pfq3-677h
Package: github.com/hashicorp/consul (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.22.0
Patched in: 1.22.0

Summary: Consul event endpoint is vulnerable to denial of service

Details:
Consul and Consul Enterprise’s (“Consul”) event endpoint is vulnerable to denial of service (DoS) due to lack of maximum value on the Content Length header. This vulnerability, CVE-2025-11375, is fixed in Consul Community Edition 1.22.0 and Consul Enterprise 1.22.0, 1.21.6, 1.20.8 and 1.18.12.