deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4rv8-5cmm-2r22
Package: github.com/jmpsec/osctrl (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.5.0
Patched in: 0.5.0

Summary: osctrl has Stored Cross-Site Scripting (XSS) in On-Demand Query List

Details:
### Summary
A stored Cross-site Scripting (XSS) vulnerability exists in the `osctrl-admin` on-demand query list. A user with query-level permissions can inject arbitrary JavaScript via the query parameter when running an on-demand query. The payload is stored and executes in the browser of any user (including administrators) who visits the query list page. This can be chained with CSRF token extraction to escalate privileges and take actions as the logged in user.

### Impact
An attacker with query-level permissions (the lowest privilege tier) can execute arbitrary JavaScript in the browsers of all users who view the query list. Depending on their level of access, it can lead to full platform compromise if an administrator executes the payload.

### Patches
Fixed in osctrl `v0.5.0`. Users should upgrade immediately.

### Workarounds
Restrict query-level permissions to trusted users. Monitor query list for suspicious payloads. Review osctrl user accounts for unauthorized administrators.

### References
- https://github.com/jmpsec/osctrl/pull/778
- https://cwe.mitre.org/data/definitions/79.html

### Credits

Leon Johnson and Kwangyun Keum from TikTok USDS JV Offensive Security Operations (Offensive Privacy Team) 

https://github.com/Kwangyun → @Kwangyun

https://github.com/sho-luv → @sho-luv
GitHub Security Advisory: GHSA-rchw-322g-f7rm
Package: github.com/jmpsec/osctrl (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 0.5.0
Patched in: 0.5.0

Summary: osctrl is Vulnerable to OS Command Injection via Environment Configuration

Details:
### Summary
An OS command injection vulnerability exists in the `osctrl-admin` environment configuration. An authenticated administrator can inject arbitrary shell commands via the hostname parameter when creating or editing environments. These commands are embedded into enrollment one-liner scripts generated using Go's `text/template` package (which does not perform shell escaping) and execute on every endpoint that enrolls using the compromised environment.

### Impact
An attacker with administrator access can achieve remote code execution on every endpoint that enrolls using the compromised environment. Commands execute as root/SYSTEM (the privilege level used for osquery enrollment) before osquery is installed, leaving no agent-level audit trail. This enables backdoor installation, credential exfiltration, and full endpoint compromise.

### Patches
Fixed in osctrl `v0.5.0`. Users should upgrade immediately.

### Workarounds
Restrict osctrl administrator access to trusted personnel. Review existing environment configurations for suspicious hostnames. Monitor enrollment scripts for unexpected commands.

### Credits

Leon Johnson and Kwangyun Keum from TikTok USDS JV Offensive Security Operations (Offensive Privacy Team)

https://github.com/Kwangyun → @Kwangyun
https://github.com/sho-luv → @sho-luv
GitHub Security Advisory: GHSA-f4w5-5xv9-85f6
Package: chainguard.dev/apko (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.14.8, < 1.1.1
Patched in: 1.1.1

Summary: apko affected by potential unbounded resource consumption in expandapk.ExpandApk on attacker-controlled .apk streams

Details:
An attacker who controls or compromises an APK repository used by apko could cause resource exhaustion on the build host. The ExpandApk function in pkg/apk/expandapk/expandapk.go expands .apk streams without enforcing decompression limits, allowing a malicious repository to serve a small, highly-compressed .apk that inflates into a large tar stream, consuming excessive disk space and CPU time, causing build failures or denial of service.                                                                                                                       
                                                                                                                                                                                             
**Fix**: Fixed in [2be3903](https://github.com/chainguard-dev/apko/commit/2be3903fe194ad46351840f0569b35f5ac965f09). Released in 1.1.0.
                                                                                                                                                                                             
**Acknowledgements**                                                                                                                                                                            
                                                                                                                                                                                              
apko thanks Oleh Konko (@1seal) from 1seal for discovering and reporting this issue.
GitHub Security Advisory: GHSA-9h8m-3fm2-qjrq
Package: go.opentelemetry.io/otel/sdk (GO)
Severity: HIGH (CVSS 7.0)
CWE: CWE-426: Untrusted Search Path
Vulnerable versions: >= 1.21.0, < 1.40.0
Patched in: 1.40.0

Summary: OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking

Details:
### Impact
The OpenTelemetry Go SDK in version `v1.20.0`-`1.39.0` is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in `sdk/resource/host_id.go` executes the `ioreg` system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application.

### Patches
This has been patched in [d45961b](https://github.com/open-telemetry/opentelemetry-go/commit/d45961bcda453fcbdb6469c22d6e88a1f9970a53), which was released with `v1.40.0`.

### References
- [CWE-426: Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html)
GitHub Security Advisory: GHSA-7777-fhq9-592v
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]3328-b2532e966621
Patched in: 1.80.0-v2.20.0[PII_REDACTED]3328-b2532e966621

Summary: ZITADEL has potential SSRF via Actions

Details:
### Summary

ZITADEL Action V2 (introduced as early preview in 2.59.0, beta in 3.0.0 and GA in 4.0.0) is a webhook based approach to allow developers act on API request to Zitadel and customize flows such the issue of a token.

ZITADEL's Action target URLs can point to local hosts, potentially allowing adversaries to gather internal network information and connect to internal services.

### Impact

When the URL points to a local host / IP address, an adversary might gather information about the internal network structure, the services exposed on internal hosts etc. This is sometimes called a Server-Side Request Forgery (SSRF).

ZITADEL Actions expect responses according to specific schemas, which reduces the threat vector.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.0` (including RC version)
- **3.x**: `3.0.0` to `3.4.6` (including RC versions)
- **2.x**: `2.59.0` to `2.71.19`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by checking the target URL against a denylist. By default localhost, resp. loopback IPs are denied.

Note that this fix was only released on v4.x. Due to the stage (preview / beta) in which the functionality was in v2.x and v3.x, the changes that have been applied to it since then and the severity, respectively the actual thread vector, a backport to the corresponding versions was not feasible. Please check the workaround section for alternative solutions if an upgrade to v4.x is not possible.

4.x: Upgrade to >=[4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)
3.x: Update to >=[v4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1) or check out workarounds
2.x: Update to >=[v4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1) or check out workarounds

### Workarounds

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

If an upgrade is not possible, users can prevent actions from using unintended endpoints by setting network policies or firewall rules in your infrastructure. Note that this is outside of the functionality provided by ZITADEL.

### 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 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-7777-fhq9-592v
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2.59.0, < 4.11.1
Patched in: 4.11.1

Summary: ZITADEL has potential SSRF via Actions

Details:
### Summary

ZITADEL Action V2 (introduced as early preview in 2.59.0, beta in 3.0.0 and GA in 4.0.0) is a webhook based approach to allow developers act on API request to Zitadel and customize flows such the issue of a token.

ZITADEL's Action target URLs can point to local hosts, potentially allowing adversaries to gather internal network information and connect to internal services.

### Impact

When the URL points to a local host / IP address, an adversary might gather information about the internal network structure, the services exposed on internal hosts etc. This is sometimes called a Server-Side Request Forgery (SSRF).

ZITADEL Actions expect responses according to specific schemas, which reduces the threat vector.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.0` (including RC version)
- **3.x**: `3.0.0` to `3.4.6` (including RC versions)
- **2.x**: `2.59.0` to `2.71.19`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by checking the target URL against a denylist. By default localhost, resp. loopback IPs are denied.

Note that this fix was only released on v4.x. Due to the stage (preview / beta) in which the functionality was in v2.x and v3.x, the changes that have been applied to it since then and the severity, respectively the actual thread vector, a backport to the corresponding versions was not feasible. Please check the workaround section for alternative solutions if an upgrade to v4.x is not possible.

4.x: Upgrade to >=[4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)
3.x: Update to >=[v4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1) or check out workarounds
2.x: Update to >=[v4.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1) or check out workarounds

### Workarounds

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

If an upgrade is not possible, users can prevent actions from using unintended endpoints by setting network policies or firewall rules in your infrastructure. Note that this is outside of the functionality provided by ZITADEL.

### 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 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-282g-fhmx-xf54
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]3[PII_REDACTED]243e5
Patched in: 1.80.0-v2.20.0[PII_REDACTED]3[PII_REDACTED]243e5

Summary: ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API

Details:
### Summary

A vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.

### Impact

Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.

Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user.
This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.

Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.0` (including RC versions)
- **3.x**: `3.0.0` through `3.4.6` (including RC versions)
- **2.x**: `2.43.0` 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.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)
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 upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.

### 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 identified by [MhdAsfan](https://github.com/MhdAsfan) during a security audit of a system utilizing Zitadel.
GitHub Security Advisory: GHSA-282g-fhmx-xf54
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.43.0, < 3.4.7
Patched in: 3.4.7

Summary: ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API

Details:
### Summary

A vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.

### Impact

Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.

Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user.
This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.

Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.0` (including RC versions)
- **3.x**: `3.0.0` through `3.4.6` (including RC versions)
- **2.x**: `2.43.0` 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.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)
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 upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.

### 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 identified by [MhdAsfan](https://github.com/MhdAsfan) during a security audit of a system utilizing Zitadel.
GitHub Security Advisory: GHSA-282g-fhmx-xf54
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 4.0.0, < 4.11.0
Patched in: 4.11.1

Summary: ZITADEL Users Can Self-Verify Email/Phone via UpdateHumanUser API

Details:
### Summary

A vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.

### Impact

Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.

Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user.
This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.

Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.0` (including RC versions)
- **3.x**: `3.0.0` through `3.4.6` (including RC versions)
- **2.x**: `2.43.0` 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.11.1](https://github.com/zitadel/zitadel/releases/tag/v4.11.1)
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 upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.

### 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 identified by [MhdAsfan](https://github.com/MhdAsfan) during a security audit of a system utilizing Zitadel.
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: < 1.80.0-v2.20.0[PII_REDACTED]2519-feab8e1fa371
Patched in: 1.80.0-v2.20.0[PII_REDACTED]2519-feab8e1fa371

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.