deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pmwq-pjrm-6p5r
Package: github.com/in-toto/in-toto-golang (GO)
Severity: MODERATE (CVSS 4.1)
CWE: CWE-168: Improper Handling of Inconsistent Special Elements
Vulnerable versions: < 0.11.0
Patched in: 0.11.0

Summary: in-toto-golang and in-toto-python have inconsistent negation behavior

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

in-toto-golang and in-toto-python both support glob patterns in artifact rules to indicate the artifacts that a rule applies to. Both support negations in character classes to indicate what should *not* be matched, but they used different operators to indicate the negation. in-toto-python uses `!` while in-toto-golang used `^`. A layout authored with the expectations of one implementation can therefore exhibit different behavior in the other implementation.

This impacts users in a specific set of circumstances where two different implementations are used to verify the same layout + attestation bundle at different stages of the same pipeline. As a rule of thumb, we advise using a single implementation across all aspects of a pipeline, from layout creation to pipeline execution and verification to prevent this class of bugs.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

in-toto-golang has been updated to use `!` instead of `^` to indicate negation. See https://github.com/in-toto/in-toto-golang/pull/462. This is part of v0.11.0.
GitHub Security Advisory: GHSA-8wxp-xxp2-rcgx
Package: volcano.sh/volcano (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.14.0, < 1.14.2
Patched in: 1.14.2

Summary: Volcano's webhook server vulnerable to OOM due to unbounded HTTP request body size

Details:
### Impact
The Volcano webhook server does not enforce a size limit on incoming HTTP request bodies. Any in-cluster pod that can reach the webhook endpoint may send an arbitrarily large request body, potentially causing the webhook server to be killed by OOM. All Volcano deployments with the webhook server exposed to in-cluster traffic are affected.

### Patches
This issue will be fixed in the following versions:
- v1.14.2
- v1.13.3
- v1.12.4

Users running versions below these should upgrade accordingly.

### Workarounds
No known workarounds. Upgrade to the patched versions listed above.
GitHub Security Advisory: GHSA-8wxp-xxp2-rcgx
Package: volcano.sh/volcano (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.13.0, < 1.13.3
Patched in: 1.13.3

Summary: Volcano's webhook server vulnerable to OOM due to unbounded HTTP request body size

Details:
### Impact
The Volcano webhook server does not enforce a size limit on incoming HTTP request bodies. Any in-cluster pod that can reach the webhook endpoint may send an arbitrarily large request body, potentially causing the webhook server to be killed by OOM. All Volcano deployments with the webhook server exposed to in-cluster traffic are affected.

### Patches
This issue will be fixed in the following versions:
- v1.14.2
- v1.13.3
- v1.12.4

Users running versions below these should upgrade accordingly.

### Workarounds
No known workarounds. Upgrade to the patched versions listed above.
GitHub Security Advisory: GHSA-8wxp-xxp2-rcgx
Package: volcano.sh/volcano (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.12.4
Patched in: 1.12.4

Summary: Volcano's webhook server vulnerable to OOM due to unbounded HTTP request body size

Details:
### Impact
The Volcano webhook server does not enforce a size limit on incoming HTTP request bodies. Any in-cluster pod that can reach the webhook endpoint may send an arbitrarily large request body, potentially causing the webhook server to be killed by OOM. All Volcano deployments with the webhook server exposed to in-cluster traffic are affected.

### Patches
This issue will be fixed in the following versions:
- v1.14.2
- v1.13.3
- v1.12.4

Users running versions below these should upgrade accordingly.

### Workarounds
No known workarounds. Upgrade to the patched versions listed above.
GitHub Security Advisory: GHSA-7x9r-wcgg-w86f
Package: github.com/hashicorp/boundary (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.21.0, < 0.21.3
Patched in: 0.21.3

Summary: Hashicorp Boundary workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes

Details:
Boundary Community Edition and Boundary Enterprise ("Boundary") workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes. An attacker with network access to the worker authentication listener may open a connection and delay or withhold the client certificate during the TLS handshake, causing worker connection handling to block. This may prevent legitimate worker connections from being accepted or routed. This vulnerability, CVE-2026-7776, is fixed in Boundary 0.21.3, 0.20.3, 0.19.5.
GitHub Security Advisory: GHSA-7x9r-wcgg-w86f
Package: github.com/hashicorp/boundary (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.20.0, < 0.20.3
Patched in: 0.20.3

Summary: Hashicorp Boundary workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes

Details:
Boundary Community Edition and Boundary Enterprise ("Boundary") workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes. An attacker with network access to the worker authentication listener may open a connection and delay or withhold the client certificate during the TLS handshake, causing worker connection handling to block. This may prevent legitimate worker connections from being accepted or routed. This vulnerability, CVE-2026-7776, is fixed in Boundary 0.21.3, 0.20.3, 0.19.5.
GitHub Security Advisory: GHSA-7x9r-wcgg-w86f
Package: github.com/hashicorp/boundary (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.19.5
Patched in: 0.19.5

Summary: Hashicorp Boundary workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes

Details:
Boundary Community Edition and Boundary Enterprise ("Boundary") workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes. An attacker with network access to the worker authentication listener may open a connection and delay or withhold the client certificate during the TLS handshake, causing worker connection handling to block. This may prevent legitimate worker connections from being accepted or routed. This vulnerability, CVE-2026-7776, is fixed in Boundary 0.21.3, 0.20.3, 0.19.5.
GitHub Security Advisory: GHSA-wmvj-f67g-qg4g
Package: github.com/osrg/gobgp/v4 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 4.4.0
Patched in: 4.4.0

Summary: GoBGP has an out-of-bounds read in the ParseIP6Extended function

Details:
An out-of-bounds read in the ParseIP6Extended function (/bgp/bgp.go) of gobgp v4.3.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.
GitHub Security Advisory: GHSA-7hgr-xvrr-xpw3
Package: github.com/nhost/nhost (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 0.0.0[PII_REDACTED]2514-52c70664a7e9
Patched in: 0.0.0[PII_REDACTED]2514-52c70664a7e9

Summary: nhost has Session Persistence After Password Change

Details:
## Description

When a user changes their password, either through the authenticated password change endpoint or a password reset ticket, the [`ChangePassword`](https://github.com/nhost/nhost/blob/main/services/auth/go/controller/workflows.go#L731-L759) workflow correctly hashes and persists the new password via [`UpdateUserChangePassword`](https://github.com/nhost/nhost/blob/main/services/auth/go/sql/query.sql#L314-L318). However, it does not revoke existing sessions. The `auth.refresh_tokens` and `auth.oauth2_refresh_tokens` tables are left untouched, meaning all previously issued refresh tokens remain valid and can continue generating new access tokens indefinitely.

This vulnerability affects all password change paths (handled in [`change_user_password.go`](https://github.com/nhost/nhost/blob/main/services/auth/go/controller/change_user_password.go)), since they share the same underlying workflow:

- Authenticated password change via the Nhost dashboard or client SDK
- Ticket-based password reset (magic links / recovery flows)
- OAuth2/OIDC sessions managed via `auth.oauth2_refresh_tokens`

## Attack Scenario

1. An attacker steals a victim's refresh token via XSS or a compromised device.
2. The victim changes their password, expecting it to terminate all active sessions.
3. The server updates `password_hash` but performs no session cleanup, the stolen token remains fully functional.

## Impact

The attacker retains persistent access even after the victim's password change. This is especially severe in credential theft scenarios, where the victim's only recovery action does nothing against an active session. Depending on configured TTL, the attacker's window could be days or weeks.
GitHub Security Advisory: GHSA-x8qc-fggm-mpqg
Package: github.com/ollama/ollama (GO)
Severity: HIGH (CVSS 9.1)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.17.1
Patched in: 0.17.1

Summary: Ollama contains a heap out-of-bounds read vulnerability in the GGUF model loader

Details:
Ollama before 0.17.1 contains a heap out-of-bounds read vulnerability in the GGUF model loader. The /api/create endpoint accepts an attacker-supplied GGUF file in which the declared tensor offset and size exceed the file's actual length; during quantization in fs/ggml/gguf.go and server/quantization.go (WriteTo()), the server reads past the allocated heap buffer. The leaked memory contents may include environment variables, API keys, system prompts, and concurrent users' conversation data, and can be exfiltrated by uploading the resulting model artifact through the /api/push endpoint to an attacker-controlled registry. The /api/create and /api/push endpoints have no authentication in the upstream distribution. Default deployments bind to 127.0.0.1, but the documented OLLAMA_HOST=0.0.0.0 configuration is widely used in practice (large public-internet exposure observed).
GitHub Security Advisory: GHSA-fq7h-9x26-6j22
Package: github.com/external-secrets/external-secrets/apis (GO)
Severity: MODERATE (CVSS 4.9)
Vulnerable versions: >= 0.1.0, < 2.4.1
Patched in: 2.4.1

Summary: ExternalSecrets vulnerable to privilege escalation with secret overwriting

Details:
ExternalSecrets allows users to craft Service Account tokens for misconfigured Service Accounts in namespaces the users have access to.

### Impact

A user who only has permission to create ExternalSecret resources can cause the operator to create a Secret that Kubernetes will automatically populate with a long-lived token for the sepcified service account. This effectively allows the user to impersonate any service account in the namespace without needing direct create permissions on TokenRequest or Secrets of that type.

The problem is mitigated in severity by the fact that the user must have pre-existing permissions already at almost the same level as the escalation later gives. The attacker cannot use this method to gain access to more information without other things also being misconfigured in the ESO installation.

### Patches

Disallow this combination including the bootstrap token secret type.

### Workarounds

* Add admission control logic to prevent the use of Templates targeting undesired Types
* Remove Service Account Token generation via kube-controller-manager flags
* Restrict User RBAC on production clusters and sensitive namespaces
GitHub Security Advisory: GHSA-rxvx-hhpj-q6px
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: >= 3.1.0, <= 3.4.9
Patched in: 3.4.10

Summary: ZITADEL has LDAP Filter Injection in Login Flow

Details:
## Summary

A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.

## Impact

While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as `*`, `(`, `)`) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.

Note that an authentication bypass is not possible.

## Affected Versions

Systems integrating LDAP as IdPs and running one of the following versions are affected:

- **4.x**: `4.0.0` through `4.14.0` (including RC versions)
- **3.x**: `3.1.0` through `3.4.9`
- **2.x**: `2.71.11` through `2.71.19`

## Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

- **4.x**: Upgrade to >=[4.15.0](https://github.com/zitadel/zitadel/releases/tag/v4.15.0)
- **3.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)
- **2.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)

## Workarounds

The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.

## Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

## Credits

This vulnerability was identified and reported by **ProScan AppSec** ([https://proscan.one/](https://proscan.one)).
GitHub Security Advisory: GHSA-rxvx-hhpj-q6px
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: >= 2.71.11, <= 2.71.19
Patched in: unpatched

Summary: ZITADEL has LDAP Filter Injection in Login Flow

Details:
## Summary

A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.

## Impact

While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as `*`, `(`, `)`) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.

Note that an authentication bypass is not possible.

## Affected Versions

Systems integrating LDAP as IdPs and running one of the following versions are affected:

- **4.x**: `4.0.0` through `4.14.0` (including RC versions)
- **3.x**: `3.1.0` through `3.4.9`
- **2.x**: `2.71.11` through `2.71.19`

## Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

- **4.x**: Upgrade to >=[4.15.0](https://github.com/zitadel/zitadel/releases/tag/v4.15.0)
- **3.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)
- **2.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)

## Workarounds

The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.

## Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

## Credits

This vulnerability was identified and reported by **ProScan AppSec** ([https://proscan.one/](https://proscan.one)).
GitHub Security Advisory: GHSA-rxvx-hhpj-q6px
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: >= 4.0.0, <= 4.14.0
Patched in: 4.15.0

Summary: ZITADEL has LDAP Filter Injection in Login Flow

Details:
## Summary

A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.

## Impact

While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as `*`, `(`, `)`) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.

Note that an authentication bypass is not possible.

## Affected Versions

Systems integrating LDAP as IdPs and running one of the following versions are affected:

- **4.x**: `4.0.0` through `4.14.0` (including RC versions)
- **3.x**: `3.1.0` through `3.4.9`
- **2.x**: `2.71.11` through `2.71.19`

## Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

- **4.x**: Upgrade to >=[4.15.0](https://github.com/zitadel/zitadel/releases/tag/v4.15.0)
- **3.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)
- **2.x**: Update to >=[3.4.10](https://github.com/zitadel/zitadel/releases/tag/v3.4.10)

## Workarounds

The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.

## Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

## Credits

This vulnerability was identified and reported by **ProScan AppSec** ([https://proscan.one/](https://proscan.one)).
GitHub Security Advisory: GHSA-v8vw-gw5j-w7m6
Package: github.com/modelcontextprotocol/registry (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 1.1.0, < 1.7.5
Patched in: 1.7.5

Summary: MCP Registry has open redirect via protocol-relative path in trailing-slash middleware

Details:
### Summary
The TrailingSlashMiddleware in internal/api/server.go is vulnerable to an open redirect attack. An attacker can craft a URL with a protocol-relative path (e.g., //evil.com/) that, after trailing slash removal, results in a Location header of //evil.com — which browsers interpret as an absolute URL to an external domain.

### Details
The TrailingSlashMiddleware strips trailing slashes from request paths and issues a 308 Permanent Redirect to the cleaned path. However, it does not validate or sanitize the resulting path before using it as the redirect target.

When a request is made with a path like //evil.com/, the middleware processes it as follows:

### PoC
1. Start the registry server locally or identify a deployed instance
2. Send a request with a double-slash path followed by an external domain:
`curl -v https://<registry-host>//evil.com/`
<img width="3066" height="969" alt="image" src="https://github.com/user-attachments/assets/a5305f00-29bf-4708-952a-478d608f2074" />
3. Observe the 308 Permanent Redirect response with Location: //evil.com:
4. When accessed in a browser, the user is redirected to https://evil.com



### Impact
**Phishing**: Attackers can abuse the trusted registry domain to redirect users to credential-harvesting pages
**Malware distribution**: Redirect users to sites serving malicious downloads
**Trust abuse:** Links originating from the official MCP Registry domain carry implicit trust
GitHub Security Advisory: GHSA-hj4w-qr9j-c4cf
Package: github.com/osrg/gobgp/v4 (GO)
Severity: MODERATE (CVSS 7.3)
CWE: CWE-191: Integer Underflow (Wrap or Wraparound)
Vulnerable versions: < 4.4.0
Patched in: 4.4.0

Summary: GoBGP has an Integer Underflow Issue

Details:
A vulnerability was determined in osrg GoBGP up to 4.3.0. Affected by this vulnerability is the function parseRibEntry of the file pkg/packet/mrt/mrt.go. Executing a manipulation can lead to integer underflow. It is possible to launch the attack remotely. Upgrading to version 4.4.0 addresses this issue. This patch is called 76d911046344a3923cbe573364197aa081944592. It is suggested to upgrade the affected component.
GitHub Security Advisory: GHSA-vm3g-8xwv-mxfp
Package: github.com/osrg/gobgp/v4 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: < 4.4.0
Patched in: 4.4.0

Summary: GoBGP has an Improper Resource Shutdown or Release

Details:
A vulnerability has been found in osrg GoBGP up to 4.3.0. This impacts the function SRv6L3ServiceAttribute.DecodeFromBytes of the file pkg/packet/bgp/prefix_sid.go of the component SRv6 L3 Service. Such manipulation of the argument data leads to denial of service. The attack may be performed from remote. Upgrading to version 4.4.0 will fix this issue. The name of the patch is f9f7b55ec258e514be0264871fa645a2c3edad11. Users should upgrade the affected component.
GitHub Security Advisory: GHSA-pqhx-w72w-m393
Package: heckel.io/ntfy/v2 (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 2.22.0
Patched in: 2.22.0

Summary: ntfy.sh allows a remote attacker to execute arbitrary code via the parseActions function

Details:
An issue in Ntfy ntfy.sh before v.2.22.0 allows a remote attacker to execute arbitrary code via the parseActions function.