deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4mq7-pvjg-xp2r
Package: github.com/ory/oathkeeper (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-305: Authentication Bypass by Primary Weakness, CWE-1289: Improper Validation of Unsafe Equivalence in Input
Vulnerable versions: < 0.40.10-0[PII_REDACTED]4801-198a2bc82a99
Patched in: 0.40.10-0[PII_REDACTED]4801-198a2bc82a99

Summary: Ory Oathkeeper has an authentication bypass by cache key confusion

Details:
## Description

Ory Oathkeeper is vulnerable to authentication bypass due to cache key confusion. The `oauth2_introspection` authenticator cache does not distinguish tokens that were validated with different introspection URLs. An attacker can therefore legitimately use a token to prime the cache, and subsequently use the same token for rules that use a different introspection server.

## Preconditions

Ory Oathkeeper has to be configured with multiple `oauth2_introspection` authenticator servers, each accepting different tokens. The authenticators also must be [configured to use caching](https://www.ory.com/docs/oathkeeper/pipeline/authn#oauth2_introspection-configuration). An attacker has to have a way to gain a valid token for one of the configured introspection servers.

## Mitigation

Ory Oathkeeper now includes the introspection server URL in the cache key, preventing confusion of tokens.

Update to the patched version of Ory Oathkeeper. If that is not immediately possible, disable caching for `oauth2_introspection` authenticators.
GitHub Security Advisory: GHSA-vhr5-ggp3-qq85
Package: github.com/ory/oathkeeper (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 0.40.10-0[PII_REDACTED]4810-e9acca14a04d
Patched in: 0.40.10-0[PII_REDACTED]4810-e9acca14a04d

Summary: Ory Oathkeeper has an authentication bypass by usage of untrusted header

Details:
## Description

Ory Oathkeeper is often deployed behind other components like CDNs, WAFs, or reverse proxies. Depending on the setup, another component might forward the request to the Oathkeeper proxy with a different protocol (http vs. https) than the original request. In order to properly match the request against the configured rules, Oathkeeper considers the `X-Forwarded-Proto`  header when evaluating rules. The configuration option `serve.proxy.trust_forwarded_headers` (defaults to false) governs whether this and other `X-Forwarded-*` headers should be trusted. Oathkeeper did not properly respect this configuration, and would always consider the `X-Forwarded-Proto`  header.

## Preconditions

In order for an attacker to abuse this, an installation of Ory Oathkeeper needs to have distinct rules for HTTP and HTTPS requests. Also, the attacker needs to be able to trigger one but not the other rule. In this scenario, the attacker can send the same request but with the `X-Forwarded-Proto`  header in order to trigger the other rule. We do not expect many configurations to meet these preconditions.

## Mitigation

It is generally recommended to drop any unexpected headers as early as possible when a request is handled, e.g. in the WAF.

Ory Oathkeeper will correctly respect the `serve.proxy.trust_forwarded_headers` configuration going forward, thereby eliminating the attack scenario. We recommend upgrading to a fixed version even if the preconditions are not met.
GitHub Security Advisory: GHSA-q8m4-xhhv-38mg
Package: go.etcd.io/etcd (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 3.3.27
Patched in: unpatched

Summary: etcd: Authorization bypasses in multiple APIs

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

Multiple vulnerabilities allow unauthorized users to bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients.

In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to:

  - call MemberList and learn cluster topology, including member IDs and advertised endpoints
  - call Alarm, which can be abused for operational disruption or denial of service
  - use Lease APIs, interfering with TTL-based keys and lease ownership
  - trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

These vulnerabilities are patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected 
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
    distribution

### Reporters
_Community efforts help keep etcd secure_

The etcd community thanks Isaac David, bugbunny.ai, Asim Viladi Oglu Manizada, Alex Schapiro & Ahmed Allam from Strix security, Luke Francis, and @OLU-DEVX for reporting these vulnerabilities.

### Dependency Between Reported Issues

These issues all originate from the same underlying flaw in the gRPC API layer.

They affect the same API surface and share a common root cause. In practice, the fix is implemented as a single, unified change at the API layer, which resolves all issues together.

Given this, we believe these issues are best treated as a single vulnerability and should be assigned a single CVE.
GitHub Security Advisory: GHSA-q8m4-xhhv-38mg
Package: go.etcd.io/etcd/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 3.4.41
Patched in: 3.4.42

Summary: etcd: Authorization bypasses in multiple APIs

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

Multiple vulnerabilities allow unauthorized users to bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients.

In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to:

  - call MemberList and learn cluster topology, including member IDs and advertised endpoints
  - call Alarm, which can be abused for operational disruption or denial of service
  - use Lease APIs, interfering with TTL-based keys and lease ownership
  - trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

These vulnerabilities are patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected 
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
    distribution

### Reporters
_Community efforts help keep etcd secure_

The etcd community thanks Isaac David, bugbunny.ai, Asim Viladi Oglu Manizada, Alex Schapiro & Ahmed Allam from Strix security, Luke Francis, and @OLU-DEVX for reporting these vulnerabilities.

### Dependency Between Reported Issues

These issues all originate from the same underlying flaw in the gRPC API layer.

They affect the same API surface and share a common root cause. In practice, the fix is implemented as a single, unified change at the API layer, which resolves all issues together.

Given this, we believe these issues are best treated as a single vulnerability and should be assigned a single CVE.
GitHub Security Advisory: GHSA-q8m4-xhhv-38mg
Package: go.etcd.io/etcd/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 3.5.0-alpha.0, <= 3.5.27
Patched in: 3.5.28

Summary: etcd: Authorization bypasses in multiple APIs

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

Multiple vulnerabilities allow unauthorized users to bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients.

In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to:

  - call MemberList and learn cluster topology, including member IDs and advertised endpoints
  - call Alarm, which can be abused for operational disruption or denial of service
  - use Lease APIs, interfering with TTL-based keys and lease ownership
  - trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

These vulnerabilities are patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected 
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
    distribution

### Reporters
_Community efforts help keep etcd secure_

The etcd community thanks Isaac David, bugbunny.ai, Asim Viladi Oglu Manizada, Alex Schapiro & Ahmed Allam from Strix security, Luke Francis, and @OLU-DEVX for reporting these vulnerabilities.

### Dependency Between Reported Issues

These issues all originate from the same underlying flaw in the gRPC API layer.

They affect the same API surface and share a common root cause. In practice, the fix is implemented as a single, unified change at the API layer, which resolves all issues together.

Given this, we believe these issues are best treated as a single vulnerability and should be assigned a single CVE.
GitHub Security Advisory: GHSA-q8m4-xhhv-38mg
Package: go.etcd.io/etcd/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 3.6.0-alpha.0, <= 3.6.8
Patched in: 3.6.9

Summary: etcd: Authorization bypasses in multiple APIs

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

Multiple vulnerabilities allow unauthorized users to bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients.

In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to:

  - call MemberList and learn cluster topology, including member IDs and advertised endpoints
  - call Alarm, which can be abused for operational disruption or denial of service
  - use Lease APIs, interfering with TTL-based keys and lease ownership
  - trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

These vulnerabilities are patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected 
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
    distribution

### Reporters
_Community efforts help keep etcd secure_

The etcd community thanks Isaac David, bugbunny.ai, Asim Viladi Oglu Manizada, Alex Schapiro & Ahmed Allam from Strix security, Luke Francis, and @OLU-DEVX for reporting these vulnerabilities.

### Dependency Between Reported Issues

These issues all originate from the same underlying flaw in the gRPC API layer.

They affect the same API surface and share a common root cause. In practice, the fix is implemented as a single, unified change at the API layer, which resolves all issues together.

Given this, we believe these issues are best treated as a single vulnerability and should be assigned a single CVE.
GitHub Security Advisory: GHSA-rjcw-vg7j-m9rc
Package: github.com/anchore/syft (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-460: Improper Cleanup on Thrown Exception
Vulnerable versions: < 1.42.3
Patched in: 1.42.3

Summary: Syft improper temporary file cleanup

Details:
### Impact
Syft versions before v1.42.3 would not properly cleanup temporary storage if the temporary storage was exhausted during a scan. When scanning archives Syft will unpack those archives into temporary storage then inspect the unpacked contents. Under normal operation Syft will remove the temporary data it writes after completing a scan.

This vulnerability would affect users of Syft that were scanning content that could cause Syft to fill the temporary storage that would then cause Syft to raise an error and exit. When the error is triggered Syft would exit without properly removing the temporary files in use. In our testing this was most easily reproduced by scanning very large artifacts or highly compressed artifacts such as a zipbomb.

Because Syft would not clean up its temporary files, the result would be filling temporary file storage preventing future runs of Syft or other system utilities that rely on temporary storage being available.

### Patches

The patch has been released in v1.42.3

Syft now cleans up temporary files when an error condition is encountered.

### Workarounds

There are no workarounds for this vulnerability in Syft. Users that find their temporary storage depleted can manually remove the temporary files.
GitHub Security Advisory: GHSA-rfx7-8w68-q57q
Package: go.etcd.io/etcd (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 3.3.27
Patched in: unpatched

Summary: etcd: Nested etcd transactions bypass RBAC authorization checks

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

An authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store.  
 
Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

* restrict network access to etcd server ports so only trusted components can connect
* require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters
_Our community helps keep etcd secure_

SIG-Etcd thanks community members Luke Francis and Battulga Byambaa for reporting this vulnerability.
GitHub Security Advisory: GHSA-rfx7-8w68-q57q
Package: go.etcd.io/etcd/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 3.4.41
Patched in: 3.4.42

Summary: etcd: Nested etcd transactions bypass RBAC authorization checks

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

An authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store.  
 
Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

* restrict network access to etcd server ports so only trusted components can connect
* require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters
_Our community helps keep etcd secure_

SIG-Etcd thanks community members Luke Francis and Battulga Byambaa for reporting this vulnerability.
GitHub Security Advisory: GHSA-rfx7-8w68-q57q
Package: go.etcd.io/etcd/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.5.0-alpha.0, <= 3.5.27
Patched in: 3.5.28

Summary: etcd: Nested etcd transactions bypass RBAC authorization checks

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

An authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store.  
 
Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

* restrict network access to etcd server ports so only trusted components can connect
* require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters
_Our community helps keep etcd secure_

SIG-Etcd thanks community members Luke Francis and Battulga Byambaa for reporting this vulnerability.
GitHub Security Advisory: GHSA-rfx7-8w68-q57q
Package: go.etcd.io/etcd/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.6.0-alpha.0, <= 3.6.8
Patched in: 3.6.9

Summary: etcd: Nested etcd transactions bypass RBAC authorization checks

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

An authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store.  
 
Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:

* etcd 3.6.9
* etcd 3.5.28
* etcd 3.4.42

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

* restrict network access to etcd server ports so only trusted components can connect
* require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters
_Our community helps keep etcd secure_

SIG-Etcd thanks community members Luke Francis and Battulga Byambaa for reporting this vulnerability.
GitHub Security Advisory: GHSA-f53h-mxv9-cp98
Package: k8s.io/ingress-nginx (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.0.0[PII_REDACTED]5635-5183b7d86137
Patched in: 0.0.0[PII_REDACTED]5635-5183b7d86137

Summary: ingress-nginx comment-based nginx configuration injection

Details:
A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)
GitHub Security Advisory: GHSA-mr3j-p26x-72x4
Package: code.vikunja.io/api (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2.1.0
Patched in: unpatched

Summary: Vikunja has an IDOR in Task Comments Allows Reading Arbitrary Comments

Details:
An authenticated user can read any task comment by ID, regardless of whether they have access to the task the comment belongs to, by substituting the task ID in the API URL with a task they do have access to.

## Details

The `GET /api/v1/tasks/{taskID}/comments/{commentID}` endpoint performs an authorization check against the task ID provided in the URL path, then loads the comment by its own ID without verifying it belongs to that task.

### Root Cause

In `pkg/models/task_comment_permissions.go`, `CanRead` constructs a `Task` using the `TaskID` from the URL and checks `Task.CanRead`:

```go
func (tc *TaskComment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
    t := Task{ID: tc.TaskID}
    return t.CanRead(s, a)
}
```

In `pkg/models/task_comments.go`, `getTaskCommentSimple` loads the comment by ID only, with `NoAutoCondition()` explicitly disabling XORM's implicit struct-field filtering:

```go
func getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {
    exists, err := s.
        Where("id = ?", tc.ID).
        NoAutoCondition().
        Get(tc)
    // ...
}
```

The generic web handler (`pkg/web/handler/read_one.go`) calls `CanRead` before `ReadOne`, so the permission check passes against the attacker-controlled task ID, and then `ReadOne` returns the comment from a completely different task.

### Attack Scenario

1. Attacker is authenticated and has read access to any task (task ID `A`) — e.g. their own task.
2. Attacker guesses or enumerates a comment ID (`C`) belonging to a task in another user's private project.
3. Attacker requests: `GET /api/v1/tasks/A/comments/C`
4. Authorization passes because the attacker can read task `A`.
5. The comment `C` is loaded by ID only and returned, leaking its contents and author.

## Credit

This vulnerability was found using [GitHub Security Lab Taskflows](https://github.com/GitHubSecurityLab/seclab-taskflows).