deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-77v3-r3jw-j2v2
Package: github.com/external-secrets/external-secrets (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.20.2, < 1.2.0
Patched in: 1.2.0

Summary: External Secrets Operator insecurely retrieves secrets through the getSecretKey templating function

Details:
### Summary

The `getSecretKey` template function, while introduced for senhasegura Devops Secrets Management (DSM) provider, has the ability to fetch secrets cross-namespaces with the roleBinding of the external-secrets controller, bypassing our security mechanisms.

This function was completely removed, as everything done with that templating function can be done in a different way while respecting our safeguards (for example, using `sourceRef` like explained here: https://github.com/external-secrets/external-secrets/issues/5690#issuecomment[PII_REDACTED])

### Impact
- Cross-namespace secret access: Attackers or misconfigured resources could retrieve secrets from namespaces other than the one intended.
- privilege escalation: Unauthorized access to secrets could lead to privilege escalation, data exfiltration, or compromise of service accounts and credentials.

### Resolution

We removed the incriminated templating function from our codebase. All users should upgrade to the latest version containing this fix.

### Workarounds

Use a policy engine such as Kubernetes, Kyverno, Kubewarden, or OPA to prevent the usage of `getSecretKey` in any ExternalSecret resource.

### Details

See also:
- https://github.com/external-secrets/external-secrets/issues/5690
- https://github.com/external-secrets/external-secrets/pull/3895
GitHub Security Advisory: GHSA-2497-gp99-2m74
Package: github.com/pterodactyl/wings (GO)
Severity: HIGH (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.7.0, < 1.12.0
Patched in: 1.12.0

Summary: Pterodactyl endlessly reprocesses/reuploads activity log data due to SQLite max parameters limit not being considered

Details:
### Summary 
Wings does not consider SQLite max parameter limit when processing activity log entries allowing for low privileged user to trigger a condition that floods the panel with activity records 

### Details 
After wings sends activity logs to the panel it deletes the processed activity entries from the wings SQLite database. However, it does not consider the max parameter limit of SQLite, 32766 as of SQLite 3.32.0. 

If wings attempts to delete more than 32766 entries from the SQLite database in one query, it triggers an error (SQL logic error: too many SQL variables (1)) and does not remove any entries from the database. These entries are then indefinitely re-processed and resent to the panel each time the cron runs. 

https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/activity_cron.go#L81
https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/sftp_cron.go#L86

### PoC 
Any method that can create the required 32767+ activity entries can trigger this vulnerability. It can (and has) been triggered by normal (non-malicious) use. I attached a simple PoC I used while verifying this that uses sftp to quickly create many small files, thus creating activity entries in the SQLite database. 
https://ptero.co/mococesoca.go


  

### Impact 
By successfully exploiting this vulnerability you can trigger a situation where wings will keep uploading the same activity data to the panel repeatedly (growing each time to include new activity) until the panels’ database server runs out of disk space.
GitHub Security Advisory: GHSA-8w7m-w749-rx98
Package: github.com/pterodactyl/wings (GO)
Severity: HIGH (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.12.0
Patched in: 1.12.0

Summary: Pterodactyl websocket endpoints have no visible rate limits or monitoring, allowing for DOS attacks

Details:
### Summary
Websockets within wings lack proper rate limiting and throttling. As a result a malicious user can open a large number of connections and then request data through these sockets, causing an excessive volume of data over the network and overloading the host system memory and cpu.

Additionally, there is not a limit applied to the total size of messages being sent or received, allowing a malicious user to open thousands of websocket connections and then send massive volumes of information over the socket, overloading the host network, and causing increased CPU and memory load within Wings.
GitHub Security Advisory: GHSA-m25m-5778-fm22
Package: github.com/grafana/grafana (GO)
Severity: HIGH (CVSS 5.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: >= 6.0.0-beta1, < 7.2.1
Patched in: 7.2.1

Summary: Grafana world readable configuration files

Details:
In certain Red Hat packages for Grafana 6.x through 6.3.6, the configuration files `/etc/grafana/grafana.ini` and `/etc/grafana/ldap.toml` (which contain a secret_key and a bind_password) are world readable.
GitHub Security Advisory: GHSA-57gg-cj55-q5g2
Package: github.com/hashicorp/vault (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 1.0.0-beta1, < 1.5.4
Patched in: 1.5.4

Summary: Token leases could outlive their TTL in HashiCorp Vault

Details:
HashiCorp Vault and Vault Enterprise 1.0 before 1.5.4 have Incorrect Access Control.
GitHub Security Advisory: GHSA-2jq6-ffph-p4h8
Package: k8s.io/kubernetes (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.5.0-alpha.0, < 1.9.6
Patched in: 1.9.6

Summary: Kubernetes arbitrary file overwrite

Details:
In Kubernetes versions 1.5.x, 1.6.x, 1.7.x, 1.8.x, and prior to version 1.9.6, the kubectl cp command insecurely handles tar data returned from the container, and can be caused to overwrite arbitrary local files.
GitHub Security Advisory: GHSA-cc8m-98fm-rc9g
Package: github.com/zalando/skipper (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-250: Execution with Unnecessary Privileges, CWE-522: Insufficiently Protected Credentials
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Skipper is vulnerable to arbitrary code execution through lua filters

Details:
### Impact

Arbitrary code execution through [lua filters](https://opensource.zalando.com/skipper/reference/scripts/).

The default skipper configuration before v0.23 was `-lua-sources=inline,file`. 
The problem starts if untrusted users can create lua filters, because of `-lua-sources=inline` , for example through a Kubernetes Ingress resource. The configuration `inline` allows these user to create a script that is able to read the filesystem accessible to the skipper process and if the user has access to read the logs they an read skipper secrets.

Kubernetes example (vulnerability is not limited to Kubernetes)
```lua
function request(ctx, params)
  local file = io.open('/var/run/secrets/kubernetes.io/serviceaccount/token', 'r')
  if file then
    local token = file:read('*all')
    file:close()
    error('[EXFIL] ' .. token)  -- Exfiltrate via error logs
  end
end
```

### Patches

https://github.com/zalando/skipper/releases/tag/v0.23.0 disables Lua by default.

### Workarounds

You can reduce support of how you can pass lua filter script data by providing config for lua sources https://opensource.zalando.com/skipper/reference/scripts/#enable-and-disable-lua-sources. For example `-lua-sources=file` will only be exploitable if the attacker can create a lua script file on the target system. 

### References

https://opensource.zalando.com/skipper/reference/scripts/#enable-and-disable-lua-sources
GitHub Security Advisory: GHSA-mx8m-v8qm-xwr8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 11.0.0, <= 11.0.6
Patched in: 11.0.7

Summary: Mattermost is vulnerable to DoS due to infinite re-renders on API errors

Details:
Mattermost versions 10.11.x <= 10.11.8, 11.1.x <= 11.1.1, 11.0.x <= 11.0.6 fail to prevent infinite re-renders on API errors which allows authenticated users to cause application-level DoS via triggering unbounded component re-render loops.
GitHub Security Advisory: GHSA-mx8m-v8qm-xwr8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 11.1.0, <= 11.1.1
Patched in: 11.1.2

Summary: Mattermost is vulnerable to DoS due to infinite re-renders on API errors

Details:
Mattermost versions 10.11.x <= 10.11.8, 11.1.x <= 11.1.1, 11.0.x <= 11.0.6 fail to prevent infinite re-renders on API errors which allows authenticated users to cause application-level DoS via triggering unbounded component re-render loops.
GitHub Security Advisory: GHSA-mx8m-v8qm-xwr8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 10.11.0, <= 10.11.8
Patched in: 10.11.9

Summary: Mattermost is vulnerable to DoS due to infinite re-renders on API errors

Details:
Mattermost versions 10.11.x <= 10.11.8, 11.1.x <= 11.1.1, 11.0.x <= 11.0.6 fail to prevent infinite re-renders on API errors which allows authenticated users to cause application-level DoS via triggering unbounded component re-render loops.
GitHub Security Advisory: GHSA-9r42-rhw3-2222
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-407: Inefficient Algorithmic Complexity, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 11.0.0, < 11.2.0
Patched in: 11.2.0

Summary: Mattermost is vulnerable to CPU exhaustion via crafted HTTP request

Details:
Mattermost versions 10.11.x <= 10.11.8 fail to validate input size before processing hashtags which allows an authenticated attacker to exhaust CPU resources via a single HTTP request containing a post with thousands space-separated tokens.
GitHub Security Advisory: GHSA-9r42-rhw3-2222
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-407: Inefficient Algorithmic Complexity, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 10.11.0, <= 10.11.8
Patched in: 10.11.9

Summary: Mattermost is vulnerable to CPU exhaustion via crafted HTTP request

Details:
Mattermost versions 10.11.x <= 10.11.8 fail to validate input size before processing hashtags which allows an authenticated attacker to exhaust CPU resources via a single HTTP request containing a post with thousands space-separated tokens.
GitHub Security Advisory: GHSA-pcjq-j3mq-jv5j
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.0.0[PII_REDACTED]1155-11115da3d0de
Patched in: 0.0.0[PII_REDACTED]1155-11115da3d0de

Summary: SiYuan Has a Stored Cross-Site Scripting (XSS) Vulnerability via Unrestricted SVG File Upload

Details:
### Summary
A Stored Cross-Site Scripting (XSS) vulnerability exists in SiYuan Note. The application does not sanitize uploaded SVG files. If a user uploads and views a malicious SVG file (e.g., imported from an untrusted source), arbitrary JavaScript code is executed in the context of their authenticated session.

### Details
The application allows authenticated users to upload files, including .svg images, without sanitizing the input to remove embedded JavaScript code (such as <script> tags or event handlers).

### PoC
1. Create a new "Daily note" in the workspace.
<img width="1287" height="572" alt="image" src="https://github.com/user-attachments/assets/3a4389b9-695d-4e1b-94dc-72efdb047aa9" />
2. Create a file named  test.svg with malicious JavaScript inside:

```
<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200" viewBox="0 0 124 124" fill="none">
<rect width="124" height="124" rx="24" fill="red"/>
   <script type="text/javascript">  
      alert(window.origin);
   </script>
</svg>
```
3. Upload a file in current daily note:
<img width="1617" height="316" alt="image" src="https://github.com/user-attachments/assets/6e14318a-08ec-48e5-b278-9174ad17cfcb" />
<img width="1482" height="739" alt="image" src="https://github.com/user-attachments/assets/95c996e8-5591-436a-9467-ab56c9ffbde0" />
<img width="1321" height="548" alt="image" src="https://github.com/user-attachments/assets/249fb187-3caa-4372-a9c9-56dfda6b8a8f" />
4. Open the file:

- Right-click the uploaded asset in the note.
- Select "Export"
<img width="934" height="718" alt="image" src="https://github.com/user-attachments/assets/ec943dfa-92ba-47f6-8b1e-56e53f1b0ca6" />
5. The JavaScript code executes immediately.
<img width="1033" height="632" alt="image" src="https://github.com/user-attachments/assets/a1611291-d333-4f8e-9da9-62104aaa1bdd" />
<img width="1381" height="641" alt="image" src="https://github.com/user-attachments/assets/d5018203-dbd0-4285-8702-8cb3e7c5cd07" />

### Impact
The vulnerability allows  to upload an SVG file containing malicious scripts. When a user  exports this file, the embedded arbitrary JavaScript code is executed within their browser context

###  Notes
Tested  version: 
<img width="1440" height="534" alt="image" src="https://github.com/user-attachments/assets/a62271e4-6850-4f59-be88-c4f8055429c0" />

### Solution

https://github.com/siyuan-note/siyuan/issues/16844
GitHub Security Advisory: GHSA-q4rr-64r9-fwgf
Package: k8s.io/kubernetes (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.0.0, <= 1.10.14
Patched in: unpatched

Summary: Kubernetes DoS Vulnerability

Details:
In all Kubernetes versions prior to v1.11.8, v1.12.6, and v1.13.4, users that are authorized to make patch requests to the Kubernetes API Server can send a specially crafted patch of type "json-patch" (e.g. `kubectl patch --type json` or `"Content-Type: application/json-patch+json"`) that consumes excessive resources while processing, causing a Denial of Service on the API Server.
GitHub Security Advisory: GHSA-f2ph-gc9m-q55f
Package: github.com/treeverse/lakefs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-294: Authentication Bypass by Capture-replay
Vulnerable versions: < 1.75.0
Patched in: 1.75.0

Summary: lakeFS is Missing Timestamp Validation in S3 Gateway Authentication

Details:
### Impact
LakeFS's S3 gateway does not validate timestamps in authenticated requests, allowing replay attacks. An attacker who captures a valid signed request (e.g., through network interception, logs, or compromised systems) can replay that request until credentials are rotated, even after the request is intended to expire.

### Patches
This issue affects all versions of lakeFS up to and including v1.74.4.

The vulnerability has been fixed in version v1.75.0.

Users should upgrade to version v1.75.0.

### Workarounds

Until upgraded, implement these mitigations:

- **Use short-lived credentials** - Rotate access keys frequently and **deactivate old keys**. For regular requests, captured requests only work until rotation. For presigned URLs, they remain valid until the credentials used to create them are deactivated.
- **Network controls** - Restrict S3 gateway access to trusted networks/IPs to limit where replay attacks can originate.

Note: These workarounds reduce risk but do not fully eliminate the vulnerability.

### References
- Original issue: https://github.com/treeverse/lakeFS/issues/9599
- AWS Signature V4 Documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html
- AWS Signature V4 S3 Requests: https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
- AWS Signature V2 Documentation: https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html
GitHub Security Advisory: GHSA-gjqq-6r35-w3r8
Package: github.com/getarcaneapp/arcane/backend (GO)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 0.0.0[PII_REDACTED]5515-5a9c2f92e11f
Patched in: 0.0.0[PII_REDACTED]5515-5a9c2f92e11f

Summary: Arcane Has a Command Injection in Arcane Updater Lifecycle Labels That Enables RCE

Details:
## Summary

Arcane’s updater service supported lifecycle labels `com.getarcaneapp.arcane.lifecycle.pre-update` and `com.getarcaneapp.arcane.lifecycle.post-update` that allowed defining a command to run before or after a container update. The label value is passed directly to /bin/sh -c without sanitization or validation.

Because any authenticated user (not limited to administrators) can create projects through the API, an attacker can create a project that specifies one of these lifecycle labels with a malicious command. When an administrator later triggers a container update (either manually or via scheduled update checks), Arcane reads the lifecycle label and executes its value as a shell command inside the container.

If the container is configured with host volume mounts in its Compose definition, the executed command may be able to read from or write to the host filesystem through the mounted paths. This can enable data theft and, in some configurations, escalation to full host compromise (for example, if /var/run/docker.sock is mounted).

### Impact

- Remote code execution (RCE) within the updated container context.
- Host filesystem access when host volumes are mounted into the container.
- Potential data exfiltration via outbound network requests or by exposing readable files.
- Potential full host compromise if sensitive mounts are present (e.g., /var/run/docker.sock).

### Patches
The lifecycle labels `com.getarcaneapp.arcane.lifecycle.pre-update` and `com.getarcaneapp.arcane.lifecycle.post-update` have been removed to eliminate this attack surface.
GitHub Security Advisory: GHSA-pvm5-9frx-264r
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-203: Observable Discrepancy, CWE-204: Observable Response Discrepancy
Vulnerable versions: <= 3.4.5
Patched in: 3.4.6

Summary: Zitadel has a user enumeration vulnerability in Login UIs

Details:
### Summary

A user enumeration vulnerability has been discovered in Zitadel's login interfaces. An unauthenticated attacker can exploit this flaw to confirm the existence of valid user accounts by iterating through usernames and userIDs.

### Impact

The login UIs (in version 1 and 2) provide the possibility to request a password reset, where an email will be sent to the user with a link to a verification endpoint.
By submitting arbitrary userIDs to these endpoints, an attacker can differentiate between valid and invalid accounts based on the system's response.

For an effective exploit the attacker needs to iterate through the potential set of userIDs. The impact can be limited by implementing [rate limiting](https://zitadel.com/docs/self-hosting/manage/production#limits-and-quotas) or similar measures to limit enumeration of userIDs.

Additionally, Zitadel includes a security feature "Ignoring unknown usernames", designed to prevent username enumeration attacks by presenting a generic response for both valid and invalid usernames on the login page. The login UI V2 did not handle the setting correctly and would allow attackers to enumerate through usernames to check their existence.

### Affected Versions

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

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by returning a generic error message, which does not indicate it the user exists.

4.x: Upgrade to >=[4.9.1](https://github.com/zitadel/zitadel/releases/tag/v4.9.1)
3.x: Update to >=[3.4.6](https://github.com/zitadel/zitadel/releases/tag/v3.4.6)
2.x: Update to >=[3.4.6](https://github.com/zitadel/zitadel/releases/tag/v3.4.6)

### Workarounds

The recommended solution is to update ZITADEL to a patched version. You can limit the impact by implementing [rate limiting](https://zitadel.com/docs/self-hosting/manage/production#limits-and-quotas) or similar measures to limit enumeration of userIDs.

There is no workaround for the "Ignoring unknown usernames" issue in login V2. Please upgrade to a patched version, if you rely on this feature.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to Niklas Kunz from Seamly for reporting this vulnerability from their pentest.
GitHub Security Advisory: GHSA-pvm5-9frx-264r
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-203: Observable Discrepancy, CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 4.0.0, <= 4.9.0
Patched in: 4.9.1

Summary: Zitadel has a user enumeration vulnerability in Login UIs

Details:
### Summary

A user enumeration vulnerability has been discovered in Zitadel's login interfaces. An unauthenticated attacker can exploit this flaw to confirm the existence of valid user accounts by iterating through usernames and userIDs.

### Impact

The login UIs (in version 1 and 2) provide the possibility to request a password reset, where an email will be sent to the user with a link to a verification endpoint.
By submitting arbitrary userIDs to these endpoints, an attacker can differentiate between valid and invalid accounts based on the system's response.

For an effective exploit the attacker needs to iterate through the potential set of userIDs. The impact can be limited by implementing [rate limiting](https://zitadel.com/docs/self-hosting/manage/production#limits-and-quotas) or similar measures to limit enumeration of userIDs.

Additionally, Zitadel includes a security feature "Ignoring unknown usernames", designed to prevent username enumeration attacks by presenting a generic response for both valid and invalid usernames on the login page. The login UI V2 did not handle the setting correctly and would allow attackers to enumerate through usernames to check their existence.

### Affected Versions

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

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by returning a generic error message, which does not indicate it the user exists.

4.x: Upgrade to >=[4.9.1](https://github.com/zitadel/zitadel/releases/tag/v4.9.1)
3.x: Update to >=[3.4.6](https://github.com/zitadel/zitadel/releases/tag/v3.4.6)
2.x: Update to >=[3.4.6](https://github.com/zitadel/zitadel/releases/tag/v3.4.6)

### Workarounds

The recommended solution is to update ZITADEL to a patched version. You can limit the impact by implementing [rate limiting](https://zitadel.com/docs/self-hosting/manage/production#limits-and-quotas) or similar measures to limit enumeration of userIDs.

There is no workaround for the "Ignoring unknown usernames" issue in login V2. Please upgrade to a patched version, if you rely on this feature.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to Niklas Kunz from Seamly for reporting this vulnerability from their pentest.