deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6mq3-xmgp-pjm5
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-302: Authentication Bypass by Assumed-Immutable Data
Vulnerable versions: >= 2.31.0, <= 2.71.19
Patched in: unpatched

Summary: ZITADEL's truncated opaque tokens are still valid

Details:
### Summary

Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid. 

ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.

The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. This is an example of such a cleartext: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:[PII_REDACTED]02363650`

### Impact

V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID.

V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database.

By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:`  The back-end still accepts this for above reasons.

This issue is not considered exploitable, but may look awkward when reproduced.

### Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected:
- **v4.x**: `4.0.0` through `4.10.1`
- **3.x**: `3.0.0` through `3.4.6`
- **2.x**: `2.31.0` through `2.71.19`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the `user_id` from the token against the session data from the database

4.x: Upgrade to >=[4.11.0](https://github.com/zitadel/zitadel/releases/tag/v4.11.0)
3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)
2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)

### Workarounds

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

### Questions

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

### Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.
GitHub Security Advisory: GHSA-6mq3-xmgp-pjm5
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-302: Authentication Bypass by Assumed-Immutable Data
Vulnerable versions: >= 3.0.0, < 3.4.7
Patched in: 3.4.7

Summary: ZITADEL's truncated opaque tokens are still valid

Details:
### Summary

Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid. 

ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.

The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. This is an example of such a cleartext: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:[PII_REDACTED]02363650`

### Impact

V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID.

V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database.

By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:`  The back-end still accepts this for above reasons.

This issue is not considered exploitable, but may look awkward when reproduced.

### Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected:
- **v4.x**: `4.0.0` through `4.10.1`
- **3.x**: `3.0.0` through `3.4.6`
- **2.x**: `2.31.0` through `2.71.19`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the `user_id` from the token against the session data from the database

4.x: Upgrade to >=[4.11.0](https://github.com/zitadel/zitadel/releases/tag/v4.11.0)
3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)
2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)

### Workarounds

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

### Questions

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

### Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.
GitHub Security Advisory: GHSA-6mq3-xmgp-pjm5
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-302: Authentication Bypass by Assumed-Immutable Data
Vulnerable versions: >= 4.0.0, < 4.11.0
Patched in: 4.11.0

Summary: ZITADEL's truncated opaque tokens are still valid

Details:
### Summary

Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid. 

ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.

The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. This is an example of such a cleartext: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:[PII_REDACTED]02363650`

### Impact

V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID.

V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database.

By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: `V2_[PII_REDACTED]79099906-at_[PII_REDACTED]79165442:`  The back-end still accepts this for above reasons.

This issue is not considered exploitable, but may look awkward when reproduced.

### Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected:
- **v4.x**: `4.0.0` through `4.10.1`
- **3.x**: `3.0.0` through `3.4.6`
- **2.x**: `2.31.0` through `2.71.19`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the `user_id` from the token against the session data from the database

4.x: Upgrade to >=[4.11.0](https://github.com/zitadel/zitadel/releases/tag/v4.11.0)
3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)
2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7)

### Workarounds

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

### Questions

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

### Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.
GitHub Security Advisory: GHSA-r492-hjgh-c9gw
Package: vitess.io/vitess (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.22.4
Patched in: 0.22.4

Summary: Vitess users with backup storage access can write to arbitrary file paths on restore

Details:
### Impact

Anyone with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that files in the manifest — which may be files that they have also added to the manifest and backup contents — are written to any accessible location on restore. This is a common [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) security issue. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there.

### Patches

v23.0.3 and v22.0.4

### Resources

https://github.com/vitessio/vitess/pull/19470
GitHub Security Advisory: GHSA-r492-hjgh-c9gw
Package: vitess.io/vitess (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.23.0-rc1, < 0.23.3
Patched in: 0.23.3

Summary: Vitess users with backup storage access can write to arbitrary file paths on restore

Details:
### Impact

Anyone with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that files in the manifest — which may be files that they have also added to the manifest and backup contents — are written to any accessible location on restore. This is a common [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) security issue. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there.

### Patches

v23.0.3 and v22.0.4

### Resources

https://github.com/vitessio/vitess/pull/19470
GitHub Security Advisory: GHSA-8g8j-r87h-p36x
Package: vitess.io/vitess (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 0.23.2
Patched in: unpatched

Summary: Vitess users with backup storage access can gain unauthorized access to production deployment environments

Details:
### Impact

Any user with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that arbitrary code is later executed when that backup is restored. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there.

### Patches
Fixes are expected to be released with versions v23.0.3 and v22.0.4
See fix commit at https://github.com/vitessio/vitess/commit/4c[PII_REDACTED]af9cb942a6683c465c3f1e9fdb5c

### Workarounds

If maintainers *intended* to use an external decompressor then they can always specify that decompressor command in the `--external-decompressor` flag value for `vttablet` and `vtbackup`. That then overrides any value specified in the manifest file.

If maintainers did *not intend* to use an external decompressor, nor an internal one, then they can specify a value such as `cat` or `tee` in the `--external-decompressor` flag value for `vttablet` and `vtbackup` to ensure that a harmless command is always used. 

### References

Users can read more about the issue here: https://github.com/vitessio/vitess/issues/19459
GitHub Security Advisory: GHSA-465p-v42x-3fmj
Package: github.com/bitnami-labs/sealed-secrets (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.36.0
Patched in: 0.36.0

Summary: Sealed Secrets for Kubernetes: Rotate API Allows Scope Widening from Strict/Namespace-Wide to Cluster-Wide via Untrusted Template Annotations

Details:
This report shows a scope-widening issue in the rotate (re-encrypt) flow: the output scope can be derived from untrusted `spec.template.metadata.annotations` on the input sealed secret.

If a victim sealed secret is strict- or namespace-scoped, an attacker who can submit it to the rotate endpoint can set `sealedsecrets.bitnami.com/cluster-wide=true` in the template metadata and receive a rotated sealed secret that is cluster-wide, enabling retargeting (`metadata.name`/`metadata.namespace`) and unsealing to recover the victim plaintext.

## Relevant Links (Pinned)

- Rotate handler uses `NewSealedSecret(..., secret)` after unsealing: https://github.com/bitnami-labs/sealed-secrets/blob/946bc048f3407117c837da6e[PII_REDACTED]d4c4eb/pkg/controller/controller.go#L560-L606
- Scope derivation reads secret annotations (`SecretScope`): https://github.com/bitnami-labs/sealed-secrets/blob/946bc048f3407117c837da6e[PII_REDACTED]d4c4eb/pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go#L112-L122

## Root Cause

The rotate flow unseals the input sealed secret to a `Secret`, then reseals using `NewSealedSecret(..., secret)`.

Because `SecretScope(secret)` is computed from secret annotations, and unsealing applies `spec.template` metadata onto the unsealed secret, an attacker can influence the scope of the rotated output by mutating template annotations on the rotate input.

## Attack Path

1. Attacker obtains a victim `SealedSecret` object (for example via read access to resources or logs) and can submit it to the controller rotate endpoint.
2. Attacker sets `spec.template.metadata.annotations.sealedsecrets.bitnami.com/cluster-wide=true` (and optionally retargets name/namespace fields).
3. Rotate returns a resealed, cluster-wide sealed secret that is no longer bound to the victim name/namespace.
4. Attacker unseals the rotated output in their chosen namespace/name to recover the victim plaintext.

## Proof of Concept

Setup + run:

```bash
unzip poc.zip -d poc
cd poc
make test
```

Canonical output (excerpt):

```
[CALLSITE_HIT]: pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go:112 SecretScope
[PROOF_MARKER]: scope_widened=true rotated_scope=cluster-wide
```

Control output (excerpt):

```
[NC_MARKER]: scope_widened=false strict_scope_preserved=true
```

## Fix Accepted When

Rotate preserves the original sealing scope and does not allow scope widening based on untrusted template metadata; strict or namespace-wide inputs cannot produce cluster-wide outputs.

[poc.zip](https://github.com/user-attachments/files/25080027/poc.zip)
[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25080028/PR_DESCRIPTION.md)
[attack_scenario.md](https://github.com/user-attachments/files/25080029/attack_scenario.md)
GitHub Security Advisory: GHSA-5rmx-256w-8mj9
Package: github.com/h44z/wg-portal (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-269: Improper Privilege Management, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2.1.2
Patched in: 2.1.3

Summary: WireGuard Portal is Vulnerable to Privilege Escalation via User Self-Update to Admin Level

Details:
# Privilege Escalation to Admin via User Self-Update in wg-portal

## Summary

Any authenticated non-admin user can become a full administrator by sending a single PUT request to their own user profile endpoint with `"IsAdmin": true` in the JSON body. After logging out and back in, the session picks up admin privileges from the database.

Tested against wg-portal v2.1.2 (Docker image `wgportal/wg-portal:v2`).

## Root Cause

When a user updates their own profile, the server parses the full JSON body into the user model, including the `IsAdmin` boolean field. A function responsible for preserving calculated or protected attributes pins certain fields to their database values (such as base model data, linked peer count, and authentication data), but it does not do this for `IsAdmin`. As a result, whatever value the client sends for `IsAdmin` is written directly to the database.

## Impact

After the exploit, the attacker has full admin access to the WireGuard VPN management portal. They can:

- Read and modify every user account
- Create, modify, and delete WireGuard peers on any interface
- View WireGuard interface configurations
- Disable or lock other user accounts
- Access the full user list and their API tokens

## Patches
The problem was fixed in the latest release, [v2.1.3](https://github.com/h44z/wg-portal/releases/tag/v2.1.3). The [docker images](https://hub.docker.com/r/wgportal/wg-portal) for the tag 'latest' built from the master branch also include the fix.
GitHub Security Advisory: GHSA-wvj2-96wp-fq3f
Package: github.com/modelcontextprotocol/go-sdk (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-178: Improper Handling of Case Sensitivity, CWE-436: Interpretation Conflict
Vulnerable versions: < 1.3.1
Patched in: 1.3.1

Summary: MCP Go SDK Vulnerable to Improper Handling of Case Sensitivity

Details:
The Go MCP SDK used Go's standard encoding/json.Unmarshal for JSON-RPC and MCP protocol message parsing. Go's standard library performs case-insensitive matching of JSON keys to struct field tags — a field tagged json:"method" would also match "Method", "METHOD", etc. Additionally, Go's standard library folds the Unicode characters ſ (U+017F) and K (U+212A) to their ASCII equivalents s and k, meaning fields like "paramſ" would match "params". This violated the JSON-RPC 2.0 specification, which defines exact field names.

#### Impact:

A malicious MCP peer may have been able to send protocol messages with non-standard field casing (e.g., "Method" instead of "method") that the SDK would silently accept. This had the potential for:
  - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.
  - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.

####  Fix:

Go's standard JSON unmarshaling was replaced with a case-sensitive decoder (github.com/segmentio/encoding) in commit 7b8d81c. Users are advised to update to v1.3.1 to resolve this issue.

#### Credits:
MCP Go SDK thanks Francesco Lacerenza (Doyensec) for reporting this issue.
GitHub Security Advisory: GHSA-5rc7-2jj6-mp64
Package: github.com/linode/terraform-provider-linode (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 1.30.0
Patched in: unpatched

Summary: Terraform Provider  for Linode Debug Logs Vulnerable to Sensitive Information Exposure

Details:
### Impact
The Terraform Provider for Linode versions prior to v3.9.0 logged sensitive information including some passwords, StackScript content, object storage data, and NodeBalancer TLS keys in debug logs without redaction.

**Important:** Provider debug logging is **not enabled by default**.  
This issue is exposed when debug/provider logs are explicitly enabled (for example in local troubleshooting, CI/CD jobs, or centralized log collection). If enabled, sensitive values may be written to logs and then retained, shared, or exported beyond the original execution environment.

Specifically:
- Instance creation operations logged the full InstanceCreateOptions struct containing RootPass and StackScriptData
- Instance disk creation logged InstanceDiskCreateOptions containing RootPass and StackscriptData
- StackScript update operations logged the complete script content via StackscriptUpdateOptions.Script
- Image share group member creation logged tokens in ImageShareGroupAddMemberOptions.Token
- Object storage operations logged full PutObjectInput structures containing user data
- NodeBalancer config create and update operations logged NodeBalancerConfigCreateOptions and NodeBalancerConfigUpdateOptions containing the SSLKey (TLS private key)

An authenticated user with access to provider debug logs (through log aggregation systems, CI/CD pipelines, or debug output) would thus be able to extract these sensitive credentials.

### Patches
Update to version v3.9.0 or later, which sanitizes debug logs by logging only non-sensitive metadata such as labels, regions, and resource IDs while redacting credentials, tokens, keys, scripts, and other sensitive content.

### Workarounds and Mitigations
- Disable Terraform/provider debug logging or set it to `WARN` level or above
  - To disable the logging, you can unset `TF_LOG_PROVIDER` and `TF_LOG` environment variables
  - Or you can set them to `WARN` or `ERROR` levels to avoid sensitive information logged in `INFO` and `DEBUG` levels.
  - See Terraform docs for details: https://developer.hashicorp.com/terraform/internals/debugging
- Restrict access to existing and historical logs
- Purge/retention-trim logs that may contain sensitive values
- Rotate potentially exposed secrets/credentials, including:
  - Root passwords
  - Image share group tokens
  - TLS private keys/certificates used in NodeBalancer configs
  - StackScript content/secrets if embedded

### Credits
This issue was reported to Terraform by Hasan Sheet via [Akamai's HackerOne Bug Bounty program](https://hackerone.com/akamai).

### Resources
https://github.com/linode/terraform-provider-linode/releases/tag/v3.9.0
https://github.com/linode/terraform-provider-linode/pull/2269
https://github.com/linode/terraform-provider-linode/commit/43a925d826b999f0355de3dc7330c55f496824c0