deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7q7g-x6vg-xpc3
Package: github.com/openbao/openbao (GO)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-384: Session Fixation
Vulnerable versions: < 0.0.0[PII_REDACTED]2553-e[PII_REDACTED]5
Patched in: 0.0.0[PII_REDACTED]2553-e[PII_REDACTED]5

Summary: OpenBao lacks user confirmation for OIDC direct callback mode

Details:
### Impact

OpenBao does not prompt for user confirmation when logging in via JWT/OIDC and a role with `callback_mode` set to `direct`.

This allows an attacker to start an authentication request and perform "remote phishing" by having the victim visit the URL and automatically log-in to the session of the attacker. Despite being based on the authorization code flow, the  `direct` mode calls back directly to the API and allows an attacker to poll for an OpenBao token until it is issued.

### Patches
Version 2.5.2 includes an additional confirmation screen for `direct` type logins that requires manual user interaction in order to finish the authentication.

### Workarounds
This issue can be worked around either by removing any roles with `callback_mode=direct` or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao.
GitHub Security Advisory: GHSA-4vrq-3vrq-g6gg
Package: github.com/moby/buildkit (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 0.28.1
Patched in: 0.28.1

Summary: BuildKit Git URL subdir component can cause access to restricted files

Details:
### Impact
Insufficient validation of Git URL fragment subdir components (`<url>#<ref>:<subdir>`, [docs](https://docs.docker.com/build/concepts/context/#url-fragments)) may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem.

### Patches
The issue has been fixed in version v0.28.1

### Workarounds
The issue affects only builds that use Git URLs with a subpath component. Avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.
GitHub Security Advisory: GHSA-4c29-8rgm-jvjj
Package: github.com/moby/buildkit (GO)
Severity: HIGH (CVSS 8.4)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.28.1
Patched in: 0.28.1

Summary: BuildKit's Malicious frontend can cause file escape outside of storage root

Details:
### Impact
When using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context.

### Patches
The issue has been fixed in v0.28.1+

### Workarounds
Issue requires using an untrusted BuildKit frontend set with `#syntax` or `--build-arg BUILDKIT_SYNTAX`. Using these options with a well-known frontend image like `docker/dockerfile` is not affected.
GitHub Security Advisory: GHSA-7v6r-w4r6-mhch
Package: github.com/ory/hydra (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.4.8
Patched in: 1.4.8

Summary: Hydra has Reflected XSS via error_hint parameter

Details:
ORY Hydra before v1.0.0-rc.3+oryOS.9 has Reflected XSS via the oauth2/fallbacks/error error_hint parameter.
GitHub Security Advisory: GHSA-h6c8-cww8-35hf
Package: github.com/openfga/openfga (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-345: Insufficient Verification of Data Authenticity, CWE-1289: Improper Validation of Unsafe Equivalence in Input
Vulnerable versions: < 1.13.1
Patched in: 1.13.1

Summary: OpenFGA has an Authorization Bypass through cached keys

Details:
### Description
In OpenFGA, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request.

### Am I Affected?
Users are affected if the following preconditions are met:
1. The model has relations which rely on condition evaluation.
1. Caching is enabled.

### Fix
Upgrade to OpenFGA v1.13.1.

### Acknowledgement
OpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.
GitHub Security Advisory: GHSA-hxv8-4j4r-cqgv
Package: github.com/cilium/cilium (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.19.0, < 1.19.2
Patched in: 1.19.2

Summary: Cilium L7 proxy may bypass Kubernetes NetworkPolicy for same-node traffic

Details:
### Impact

Ingress [Network Policies](https://docs.cilium.io/en/stable/network/kubernetes/policy/#network-policy) are not enforced for traffic from pods to L7 Services ([Envoy](https://docs.cilium.io/en/stable/network/servicemesh/l7-traffic-management), GAMMA) with a local backend on the same node, when [Per-Endpoint Routing](https://docs.cilium.io/en/stable/network/concepts/routing/#routing) is enabled and [BPF Host Routing](https://docs.cilium.io/en/stable/operations/performance/tuning/#ebpf-host-routing) is disabled.

Per-Endpoint Routing is disabled by default, but is automatically enabled in deployments using cloud IPAM, including Cilium ENI on EKS (`eni.enabled`), AlibabaCloud ENI (`alibabacloud.enabled`), Azure IPAM (`azure.enabled`, but not AKS BYOCNI), and some GKE deployments (`gke.enabled`; managed offerings such as GKE Dataplane V2 may use different defaults). It is typically not enabled in tunneled deployments, and chaining deployments are not affected. In practice, Amazon EKS with Cilium ENI mode is likely the most common affected environment.

### Patches

This issue was fixed by #44693.

This issue affects:

* Cilium v1.19 between v1.19.0 and v1.19.1 inclusive
* Cilium v1.18 between v1.18.0 and v1.18.7 inclusive
* All versions of Cilium prior to v1.17.13

This issue is fixed in:

* Cilium v1.19.2
* Cilium v1.18.8
* Cilium v1.17.14

### Workarounds

Disclaimer: There is currently no officially verified or comprehensive workaround for this issue. The only option would be to disable per-endpoint routes, but this will likely cause disruptions to ongoing connections, and potential conflicts if running in cloud providers.

### Acknowledgements

The Cilium community has worked together with members of the Northflank and Isovalent teams to prepare these mitigations. Cilium thanks @sudeephb and @Champ-Goblem for reporting the issue and to @smagnani96 and @julianwiedmann for helping with the resolution.

### For more information

Anyone who believes a vulnerability affecting Cilium has been found is strongly encouraged to report it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and any such report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.
GitHub Security Advisory: GHSA-hxv8-4j4r-cqgv
Package: github.com/cilium/cilium (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.18.0, < 1.18.8
Patched in: 1.18.8

Summary: Cilium L7 proxy may bypass Kubernetes NetworkPolicy for same-node traffic

Details:
### Impact

Ingress [Network Policies](https://docs.cilium.io/en/stable/network/kubernetes/policy/#network-policy) are not enforced for traffic from pods to L7 Services ([Envoy](https://docs.cilium.io/en/stable/network/servicemesh/l7-traffic-management), GAMMA) with a local backend on the same node, when [Per-Endpoint Routing](https://docs.cilium.io/en/stable/network/concepts/routing/#routing) is enabled and [BPF Host Routing](https://docs.cilium.io/en/stable/operations/performance/tuning/#ebpf-host-routing) is disabled.

Per-Endpoint Routing is disabled by default, but is automatically enabled in deployments using cloud IPAM, including Cilium ENI on EKS (`eni.enabled`), AlibabaCloud ENI (`alibabacloud.enabled`), Azure IPAM (`azure.enabled`, but not AKS BYOCNI), and some GKE deployments (`gke.enabled`; managed offerings such as GKE Dataplane V2 may use different defaults). It is typically not enabled in tunneled deployments, and chaining deployments are not affected. In practice, Amazon EKS with Cilium ENI mode is likely the most common affected environment.

### Patches

This issue was fixed by #44693.

This issue affects:

* Cilium v1.19 between v1.19.0 and v1.19.1 inclusive
* Cilium v1.18 between v1.18.0 and v1.18.7 inclusive
* All versions of Cilium prior to v1.17.13

This issue is fixed in:

* Cilium v1.19.2
* Cilium v1.18.8
* Cilium v1.17.14

### Workarounds

Disclaimer: There is currently no officially verified or comprehensive workaround for this issue. The only option would be to disable per-endpoint routes, but this will likely cause disruptions to ongoing connections, and potential conflicts if running in cloud providers.

### Acknowledgements

The Cilium community has worked together with members of the Northflank and Isovalent teams to prepare these mitigations. Cilium thanks @sudeephb and @Champ-Goblem for reporting the issue and to @smagnani96 and @julianwiedmann for helping with the resolution.

### For more information

Anyone who believes a vulnerability affecting Cilium has been found is strongly encouraged to report it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and any such report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.
GitHub Security Advisory: GHSA-hxv8-4j4r-cqgv
Package: github.com/cilium/cilium (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 1.17.14
Patched in: 1.17.14

Summary: Cilium L7 proxy may bypass Kubernetes NetworkPolicy for same-node traffic

Details:
### Impact

Ingress [Network Policies](https://docs.cilium.io/en/stable/network/kubernetes/policy/#network-policy) are not enforced for traffic from pods to L7 Services ([Envoy](https://docs.cilium.io/en/stable/network/servicemesh/l7-traffic-management), GAMMA) with a local backend on the same node, when [Per-Endpoint Routing](https://docs.cilium.io/en/stable/network/concepts/routing/#routing) is enabled and [BPF Host Routing](https://docs.cilium.io/en/stable/operations/performance/tuning/#ebpf-host-routing) is disabled.

Per-Endpoint Routing is disabled by default, but is automatically enabled in deployments using cloud IPAM, including Cilium ENI on EKS (`eni.enabled`), AlibabaCloud ENI (`alibabacloud.enabled`), Azure IPAM (`azure.enabled`, but not AKS BYOCNI), and some GKE deployments (`gke.enabled`; managed offerings such as GKE Dataplane V2 may use different defaults). It is typically not enabled in tunneled deployments, and chaining deployments are not affected. In practice, Amazon EKS with Cilium ENI mode is likely the most common affected environment.

### Patches

This issue was fixed by #44693.

This issue affects:

* Cilium v1.19 between v1.19.0 and v1.19.1 inclusive
* Cilium v1.18 between v1.18.0 and v1.18.7 inclusive
* All versions of Cilium prior to v1.17.13

This issue is fixed in:

* Cilium v1.19.2
* Cilium v1.18.8
* Cilium v1.17.14

### Workarounds

Disclaimer: There is currently no officially verified or comprehensive workaround for this issue. The only option would be to disable per-endpoint routes, but this will likely cause disruptions to ongoing connections, and potential conflicts if running in cloud providers.

### Acknowledgements

The Cilium community has worked together with members of the Northflank and Isovalent teams to prepare these mitigations. Cilium thanks @sudeephb and @Champ-Goblem for reporting the issue and to @smagnani96 and @julianwiedmann for helping with the resolution.

### For more information

Anyone who believes a vulnerability affecting Cilium has been found is strongly encouraged to report it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and any such report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.
GitHub Security Advisory: GHSA-fh3m-562m-w4f6
Package: github.com/digitalocean/droplet-agent (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 0.0.0[PII_REDACTED]2243-1101ffcb5672
Patched in: unpatched

Summary: DigitalOcean Droplet Agent: Command Injection via Metadata Service Endpoint

Details:
A command injection vulnerability exists in DigitalOcean Droplet Agent through 1.3.2. The troubleshooting actioner component (internal/troubleshooting/actioner/actioner.go) processes metadata from the metadata service endpoint and executes commands specified in the TroubleshootingAgent.Requesting array without adequate input validation. While the code validates that artifacts exist in the validInvestigationArtifacts map, it fails to sanitize the actual command content after the "command:" prefix. This allows an attacker who can control metadata responses to inject and execute arbitrary OS commands with root privileges. The attack is triggered by sending a TCP packet with specific sequence numbers to the SSH port, which causes the agent to fetch metadata from http://169.254.169.254/metadata/v1.json. 

The vulnerability affects the command execution flow in internal/troubleshooting/actioner/actioner.go (insufficient validation), internal/troubleshooting/command/exec.go (direct exec.CommandContext call), and internal/troubleshooting/command/command.go (command parsing without sanitization). This can lead to complete system compromise, data exfiltration, privilege escalation, and potential lateral movement across cloud infrastructure.
GitHub Security Advisory: GHSA-f95f-77jx-fcjc
Package: code.vikunja.io/api (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2.2.1
Patched in: 2.2.1

Summary: Vikunja has a Link Share Delete IDOR — Missing Project Ownership Check Allows Cross-Project Link Share Deletion

Details:
## Summary

The `DELETE /api/v1/projects/:project/shares/:share` endpoint does not verify that the link share belongs to the project specified in the URL. An attacker with admin access to any project can delete link shares from other projects by providing their own project ID combined with the target share ID.

## Details

The permission check in `canDoLinkShare` (`pkg/models/link_sharing_permissions.go:53-70`) validates admin access on the project from the `:project` URL parameter. However, the `Delete` method at `pkg/models/link_sharing.go:305` queries only `WHERE id = ?` using the share ID, without verifying it belongs to the URL-specified project:

```go
func (share *LinkSharing) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.Where("id = ?", share.ID).Delete(share)
    return
}
```

This is the same vulnerability class as GHSA-jfmm-mjcp-8wq2 (task attachment IDOR) and the fixed GHSA-mr3j-p26x-72x4 (task comment IDOR).

Additionally, `ReadOne` at line 203 has the same pattern (`WHERE id = ?` only), though it is not currently exploitable because `CanRead` fails first due to an unrelated issue with the hash parameter binding.

## Impact

An authenticated user with admin access to any project can:
- Delete link shares belonging to any other project in the system
- Disrupt collaboration by removing shared access links
- Link share IDs are sequential integers, making enumeration trivial

## Reproduction

1. User A creates Project A and a link share on it (share ID = X)
2. User B creates Project B (gaining admin access)
3. User B calls `DELETE /api/v1/projects/{projectB_id}/shares/{X}`
4. The permission check passes (User B is admin on Project B)
5. The delete executes `WHERE id = X` — deleting User A's link share

## Recommended Fix

Change `Delete` at `pkg/models/link_sharing.go:305` to:

```go
_, err = s.Where("id = ? AND project_id = ?", share.ID, share.ProjectID).Delete(share)
```

Also fix `ReadOne` at line 203 as defense in depth.
GitHub Security Advisory: GHSA-94xm-jj8x-3cr4
Package: code.vikunja.io/api (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: >= 0.18.0, <= 2.2.0
Patched in: 2.2.1

Summary: Vikunja Allows Disabled/Locked User Accounts to Authenticate via API Tokens, CalDAV, and OpenID Connect

Details:
## Summary

When a user account is disabled or locked, the status check is only enforced on the local login and JWT token refresh paths. Three other authentication paths — API tokens, CalDAV basic auth, and OpenID Connect — do not verify user status, allowing disabled or locked users to continue accessing the API and syncing data.

## Details

User status (`StatusDisabled`, `StatusAccountLocked`) is checked in only two places:

1. **Local/LDAP login** (`pkg/routes/api/v1/login.go:74`) — prevents issuing new JWTs
2. **JWT token refresh** (`pkg/routes/api/v1/login.go:247`) — prevents refreshing expired JWTs

Three other authentication paths fetch the user from the database via `GetUserByID` but never inspect the returned user's status:

### 1. API Token Authentication (`pkg/routes/api_tokens.go:76-103`)

API tokens are long-lived (up to years) and have no refresh cycle. A disabled user's API tokens remain fully functional until they expire naturally.

### 2. CalDAV Basic Auth (`pkg/routes/caldav/auth.go`)

The CalDAV basic auth handler validates credentials but does not check user status before granting access. A disabled user with valid credentials or a CalDAV token can continue syncing calendars and tasks.

### 3. OpenID Connect Callback (`pkg/modules/auth/openid/openid.go`)

The OIDC callback issues a fresh JWT token after validating the identity provider's response but does not check whether the Vikunja user account is disabled. If the user's identity provider session is still active, they receive a valid JWT despite being disabled in Vikunja.

## Impact

An administrator who disables a user account expects that user to be immediately locked out. In practice:

- **API tokens**: The user retains full API access for the remaining lifetime of any issued API tokens — potentially months or years.
- **CalDAV**: The user can continue reading and writing tasks/events via any CalDAV client.
- **OIDC**: The user can obtain a fresh, fully valid JWT by re-authenticating through their identity provider, completely bypassing the account disable.

## Proof of Concept

1. Create a user and generate an API token.
2. Disable the user account via the admin API or CLI.
3. Make an API request using the API token:
   ```bash
   curl -H "Authorization: Bearer tk_<token>" https://vikunja.example/api/v1/user
   ```
4. The request succeeds with a 200 response despite the account being disabled.
GitHub Security Advisory: GHSA-p747-qc5p-773r
Package: code.vikunja.io/api (GO)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 0.13, < 2.2.1
Patched in: unpatched

Summary: Vikunja has TOTP Reuse During Validity Window

Details:
### Summary
Any user that has enabled 2FA can have their TOTP reused during the standard 30 second validity window.

### Details
The below code is called when a user that has 2FA is authenticating to the application. Once they submit a valid username-password-totp combination, the user gets authenticated. If that same TOTP is used for the same user's account again within the validity window, it will allow the other session to authenticate successfully.

**Source**: <ins>pkg/user/totp.go:128</ins>
```go
// ValidateTOTPPasscode validated totp codes of users.
func ValidateTOTPPasscode(s *xorm.Session, passcode *TOTPPasscode) (t *TOTP, err error) {
	t, err = GetTOTPForUser(s, passcode.User)
	if err != nil {
		return
	}

	if !totp.Validate(passcode.Passcode, t.Secret) {
		return nil, ErrInvalidTOTPPasscode{Passcode: passcode.Passcode}
	}

	return
}
```

Section 6.5.1 within the [Authentication](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x15-V6-Authentication.md) section of the OWASP ASVS recommends multiple checks, some of which involving TOTPs:

> Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once.

The OWASP WSTG also references this as one of their [checks](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/11-Testing_Multi-Factor_Authentication) to look for:

> Can the OTPs be used more than once?

### PoC

https://github.com/user-attachments/assets/19d3b4c3-c219-4f59-b57d-45c9f6a264c8

### Impact
Any user who uses 2FA could be impacted if their traffic is able to be captured, they're phished/social engineered, or other methods of attack. This disrupts one layer of the defense-in-depth model surrounding 2FA.

### Similar CVEs

- [CVE-2025-6014](https://nvd.nist.gov/vuln/detail/CVE-2025-6014)
- [CVE-2025-55003](https://nvd.nist.gov/vuln/detail/CVE-2025-55003)

### Remediation

Store a deny-list of TOTP codes for their validity windows and check submitted codes against it to ensure none are being reused. After their validity window has closed, the 2FA code can be removed from the list.
GitHub Security Advisory: GHSA-hj7x-hmf2-hc2p
Package: github.com/goharbor/harbor (GO)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-798: Use of Hard-coded Credentials, CWE-1393: Use of Default Password
Vulnerable versions: <= 2.15.0
Patched in: unpatched

Summary: Harbor allows the use of the default password for web UI login

Details:
Use of hard coded credentials in GoHarbor Harbor version 2.15.0 and below, allows attackers to use the default password and gain access to the web UI.