deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6pw3-h7xf-x4gp
Package: blacksheep (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection'), CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Vulnerable versions: < 2.4.6
Patched in: 2.4.6

Summary: BlackSheep's ClientSession is vulnerable to CRLF injection

Details:
### Impact
The HTTP Client implementation in BlackSheep is vulnerable to CRLF injection. Missing headers validation makes it possible for an attacker to modify the HTTP requests (e.g. insert a new header) or even create a new HTTP request.
Exploitation requires developers to pass unsanitized user input directly into headers.
The server part is not affected because BlackSheep delegates to an underlying ASGI server handling of response headers.

**Attack vector:** Applications using user input in HTTP client requests (method, URL, headers).

### Patches
Users who use the HTTP Client in BlackSheep should upgrade to `2.4.6`.

### Workarounds
If users handle headers from untrusted parties, they might reject values for header names and values that contain carriage returns.

### References
https://owasp.org/www-community/vulnerabilities/CRLF_Injection
GitHub Security Advisory: GHSA-3g2f-4rjg-9385
Package: weblate (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 5.15.2
Patched in: 5.15.2

Summary: Weblate leaks information via screenshots

Details:
### Impact
The screenshot images were served directly by the HTTP server without proper access control. This could allow an unauthenticated user to access screenshots after guessing their filename.

### Patches
* https://github.com/WeblateOrg/weblate/pull/17516

### References

Thanks to Lukas May and Michael Leu for reporting this.
GitHub Security Advisory: GHSA-jm66-cg57-jjv5
Package: azure-core (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 1.38.0
Patched in: 1.38.0

Summary: Azure Core is vulnerable to deserialization of untrusted data

Details:
Deserialization of untrusted data in Azure Core shared client library for Python allows an authorized attacker to execute code over a network.
GitHub Security Advisory: GHSA-xg9w-vg3g-6m68
Package: guarddog (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.7.1
Patched in: 2.7.1

Summary: GuardDog Path Traversal Vulnerability Leads to Arbitrary File Overwrite and RCE

Details:
## Summary

A **path traversal vulnerability** exists in GuardDog's `safe_extract()` function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to **Arbitrary File Overwrite** and **Remote Code Execution** on systems running GuardDog.

**CWE:** CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)

## Details

### Vulnerable Code

**File:** `guarddog/utils/archives.py`

```python
elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            # Note: zip.extract cleans up any malicious file name
            # such as directory traversal attempts This is not the
            # case of zipfile.extractall
            zip.extract(file, path=os.path.join(target_directory, file))  # ❌ VULNERABLE
```

### Root Cause

The comment about `zip.extract()` fooled me at first :) then I noticed the `os.path.join()` call. 
The vulnerability stems from **incorrect usage of Python's `zipfile.ZipFile.extract()` API**:

- The `path` parameter should be the **target directory**, not a full file path
- `extract()` automatically appends the member name to the path
- By passing `os.path.join(target_directory, file)`, GuardDog causes the filename to be appended **twice**
- This breaks zipfile's built-in path traversal sanitization

### Attack Vector

1. Attacker creates malicious wheel with path traversal filenames
2. Uploads to PyPI or distributes directly
3. Package scan: `guarddog pypi scan malicious-pkg`
4. GuardDog downloads and extracts the package
5. Malicious files written to arbitrary locations
6. Code execution could be achieved

## Impact

Impact depends on how GuardDog is running and under which environment.

### Critical Scenarios

1. **Immediate Code Execution**
   - Write to `~/.bashrc` → executes on next shell
   - Write to `~/.profile` → executes on login

2. **Persistent Backdoors**
   - Write to `~/.ssh/authorized_keys` → SSH access
   - Write to `/etc/cron.d/malicious` → scheduled execution (if root)
   - Write to systemd user services → persistent execution

and more...

## Credits

**Reported by:** Charbel (dwbruijn)
GitHub Security Advisory: GHSA-ffj4-jq7m-9g6v
Package: guarddog (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Vulnerable versions: < 2.7.1
Patched in: 2.7.1

Summary: GuardDog Zip Bomb Vulnerability in safe_extract() Allows DoS

Details:
## Summary

GuardDog's `safe_extract()` function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data.

## Vulnerability Details

**Affected Component:** `guarddog/utils/archives.py` - `safe_extract()` function  
**Vulnerability Type:** CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb)  
**Severity:** HIGH (CVSS ~8)  
**Attack Vector:** Network (malicious package uploaded to PyPI/npm) or local

### Root Cause

The `safe_extract()` function handles TAR files securely using the `tarsafe` library, but ZIP file extraction has no size validation:
```python
elif zipfile.is_zipfile(source_archive):
    with zipfile.ZipFile(source_archive, "r") as zip:
        for file in zip.namelist():
            zip.extract(file, path=os.path.join(target_directory, file))
```

**Missing protections:**
- ❌ No decompressed size limit
- ❌ No compression ratio validation  
- ❌ No file count limits
- ❌ No total extracted size validation

## Impact

### Denial of Service Scenarios

**1. CI/CD Pipeline Disruption**
- Attacker publishes malicious package to PyPI
- Developer adds package to requirements.txt
- CI/CD runs GuardDog scan
- Disk fills (GitHub Actions: standard 14GB limit)
- All deployments blocked

**2. Resource Exhaustion**
- Local development environments
- Security scanning infrastructure  
- Automated scanning systems
- Docker containers with limited disk

**3. Supply Chain Attack Amplification**
- Single malicious package blocks security scanning
- Prevents detection of other malicious packages
- Forces manual intervention
- Increases security team workload

## Recommended Fix

Add size validation for ZIP files similar to what `tarsafe` provides for TAR files

### Configuration Options

Make limits configurable via environment variables or config file

## Additional Improvements

1. **Add warning logs** when archives approach limits
2. **Provide clear error messages** for users
3. **Document limits** in user-facing documentation
4. **Add tests** for zip bomb detection
5. **Consider using a safe ZIP library** (similar to tarsafe)

## Credit

Reported by: Charbel (dwbruijn)
GitHub Security Advisory: GHSA-jm5j-jfrm-hm23
Package: hermes (PIP)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 0.8.1, <= 0.9.0
Patched in: 0.9.1

Summary: hermes's raw options logging may disclose secrets passed in via subcommand options argument

Details:
Thanks, @thunze for reporting this!

`hermes` subcommands take arbitrary options under the `-O` argument. These have been logged in raw form since https://github.com/softwarepub/hermes/commit/7f64f102e916c76dc44404b77ab2a80f5a4e59b1 in: https://github.com/softwarepub/hermes/blob/3a92f42b2b976fdbc2c49a621de6d665364a7cee/src/hermes/commands/cli.py#L66

If users provide sensitive data such as API tokens (e.g., via `hermes deposit -O invenio_rdm.auth_token SECRET`), these are written to the log file in plain text, making them available to whoever can access the log file.

### Impact

As currently, `hermes.log` is not yet uploaded automatically as an artifact in CI, this vuln impacts:

- local users working on shared access computers, where logs may be written to a commonly accessible file system
- CI users whose CI logs are accessible to others, e.g., through group or organization rights

Potentially, if the changes merged from https://github.com/softwarepub/ci-templates/pull/13 are merged into `ci-templates` via https://github.com/softwarepub/ci-templates/pull/14, this would automate the disclosure of Invenio auth tokens at least for all CI runs against Invenio instances!

### Patches

This has been patched in [`hermes` 0.9.1](TODO) by masking all values passed using `-O`.

### Workarounds

Upgrade to `hermes` >= 0.9.1.
GitHub Security Advisory: GHSA-pgqp-8h46-6x4j
Package: mlflow (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: < 3.5.0
Patched in: 3.5.0

Summary: MLFlow is vulnerable to DNS rebinding attacks due to a lack of Origin header validation

Details:
MLFlow versions up to and including 3.4.0 are vulnerable to DNS rebinding attacks due to a lack of Origin header validation in the MLFlow REST server. This vulnerability allows malicious websites to bypass Same-Origin Policy protections and execute unauthorized calls against REST endpoints. An attacker can query, update, and delete experiments via the affected endpoints, leading to potential data exfiltration, destruction, or manipulation. The issue is resolved in version 3.5.0.
GitHub Security Advisory: GHSA-m86r-wr74-693h
Package: opencolorio (PIP)
Severity: LOW (CVSS 3.3)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-125: Out-of-bounds Read
Vulnerable versions: < 2.5.1
Patched in: 2.5.1

Summary: AcademySoftwareFoundation OpenColorIO has an out-of-bounds vulnerability

Details:
A vulnerability was found in AcademySoftwareFoundation OpenColorIO up to 2.5.0. This issue affects the function ConvertToRegularExpression of the file src/OpenColorIO/FileRules.cpp. Performing a manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is named ebdbb75123c9d5f4643e041314e2bc988a13f20d. To fix this issue, it is recommended to deploy a patch. The fix was added to the 2.5.1 milestone.
GitHub Security Advisory: GHSA-562r-8445-54r2
Package: comfy-cli (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: < 3.39.2
Patched in: 3.39.2

Summary: ComfyUI-Manager is Vulnerable to CRLF Injection in Configuration Handler

Details:
## Impact

**Vulnerability Type**: CRLF Injection via ConfigParser

An attacker can inject special characters into HTTP query parameters to add arbitrary configuration values to the `config.ini` file. This can lead to security setting tampering or modification of application behavior.

**Affected Users**: Users running ComfyUI-Manager in environments where ComfyUI is configured with the `--listen` option to allow remote access.

**CVSS Score**: 7.5 (High)

## Patches

Fixed in the following versions:
- **3.39.2** (v3.x branch)
- **4.0.5** (v4.x branch)

Sanitization logic was added to the `write_config()` function to remove CRLF and NULL characters from all string values.

## Workarounds

If upgrading is not possible:
- Run ComfyUI-Manager only on trusted networks
- Block external access via firewall
- Run on localhost only without the `--listen` option

## References

- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)
- [OWASP CRLF Injection](https://owasp.org/www-community/vulnerabilities/CRLF_Injection)

## Credit

This vulnerability was reported by:
- 李存义 <xiaoheihei1107@gmail.com>
- D0n9 Li <wyd0n9@gmail.com>
- Swings <swing@mail.exp.sh>
- Osword from SGLAB of Legendsec at Qi'anxin Group <zhzhdoai@gmail.com>
GitHub Security Advisory: GHSA-562r-8445-54r2
Package: comfy-cli (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 4.0.0, <= 4.0.4
Patched in: 4.0.5

Summary: ComfyUI-Manager is Vulnerable to CRLF Injection in Configuration Handler

Details:
## Impact

**Vulnerability Type**: CRLF Injection via ConfigParser

An attacker can inject special characters into HTTP query parameters to add arbitrary configuration values to the `config.ini` file. This can lead to security setting tampering or modification of application behavior.

**Affected Users**: Users running ComfyUI-Manager in environments where ComfyUI is configured with the `--listen` option to allow remote access.

**CVSS Score**: 7.5 (High)

## Patches

Fixed in the following versions:
- **3.39.2** (v3.x branch)
- **4.0.5** (v4.x branch)

Sanitization logic was added to the `write_config()` function to remove CRLF and NULL characters from all string values.

## Workarounds

If upgrading is not possible:
- Run ComfyUI-Manager only on trusted networks
- Block external access via firewall
- Run on localhost only without the `--listen` option

## References

- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)
- [OWASP CRLF Injection](https://owasp.org/www-community/vulnerabilities/CRLF_Injection)

## Credit

This vulnerability was reported by:
- 李存义 <xiaoheihei1107@gmail.com>
- D0n9 Li <wyd0n9@gmail.com>
- Swings <swing@mail.exp.sh>
- Osword from SGLAB of Legendsec at Qi'anxin Group <zhzhdoai@gmail.com>
GitHub Security Advisory: GHSA-597g-3phw-6986
Package: virtualenv (PIP)
Severity: MODERATE (CVSS 4.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 20.36.1
Patched in: 20.36.1

Summary: virtualenv Has TOCTOU Vulnerabilities in Directory Creation

Details:
## Impact

TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in `virtualenv` allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv's app_data and lock file operations to attacker-controlled locations.

**Affected versions:** All versions up to and including 20.36.1

**Affected users:** Any user running `virtualenv` on multi-user systems where untrusted local users have filesystem access to shared temporary directories or where `VIRTUALENV_OVERRIDE_APP_DATA` points to a user-writable location.

**Attack scenarios:**
- Cache poisoning: Attacker corrupts wheels or Python metadata in the cache
- Information disclosure: Attacker reads sensitive cached data or metadata
- Lock bypass: Attacker controls lock file semantics to cause concurrent access violations
- Denial of service: Lock starvation preventing virtualenv operations

## Patches

The vulnerability has been patched by replacing check-then-act patterns with atomic `os.makedirs(..., exist_ok=True)` operations.

**Fixed in:** PR #3013

**Versions with the fix:** 20.36.2 and later

Users should upgrade to version 20.36.2 or later.

## Workarounds

If you cannot upgrade immediately:

1. Ensure `VIRTUALENV_OVERRIDE_APP_DATA` points to a directory owned by the current user with restricted permissions (mode 0700)
2. Avoid running `virtualenv` in shared temporary directories where other users have write access
3. Use separate user accounts for different projects to isolate app_data directories

## References

- GitHub PR: https://github.com/pypa/virtualenv/pull/3013
- Vulnerability reported by: @tsigouris007
- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (TOCTOU)
- CWE-59: Improper Link Resolution Before File Access
GitHub Security Advisory: GHSA-grg2-63fw-f2qr
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.6.4, < 0.12.0
Patched in: 0.12.0

Summary: vLLM is vulnerable to DoS in Idefics3 vision models via image payload with ambiguous dimensions

Details:
### Summary
Users can crash the vLLM engine serving multimodal models that use the _Idefics3_ vision model implementation by sending a specially crafted 1x1 pixel image. This causes a tensor dimension mismatch that results in an unhandled runtime error, leading to complete server termination.

### Details
The vulnerability is triggered when the image processor encounters a 1x1 pixel image with shape (1, 1, 3) in HWC (Height, Width, Channel) format. Due to the ambiguous dimensions, the processor incorrectly assumes the image is in CHW (Channel, Height, Width) format with shape (3, H, W). This misinterpretation causes an incorrect calculation of the number of image patches, resulting in a fatal tensor split operation failure.

**Crash location**: `vllm/model_executor/models/idefics3.py` line 672:
```python
def _process_image_input(self, image_input: ImageInputs) -> torch.Tensor | list[torch.Tensor]:
    # ...
    num_patches = image_input["num_patches"]
    return [e.flatten(0, 1) for e in image_features.split(num_patches.tolist())]
```

The `split()` call fails because the computed `num_patches` value (17) does not match the actual tensor dimension (9):
```
RuntimeError: split_with_sizes expects split_sizes to sum exactly to 9 
(input tensor's size at dimension 0), but got split_sizes=[17]
```

This unhandled exception terminates the EngineCore process, crashing the server.

#### Affected Models
Any model using the Idefics3 architecture. The vulnerability was tested with `HuggingFaceTB/SmolVLM-Instruct`.

### Impact
Denial of service by crashing the engine

### Mitigation
Validating the input:
```python
def _validate_image_dimensions(self, image_shape):
    h, w = image_shape[:2] if len(image_shape) == 3 else image_shape
    if h < MIN_IMAGE_SIZE or w < MIN_IMAGE_SIZE:
        raise ValueError(f"Image dimensions too small: {h}x{w}")
```

Managing the exception:
```python
try:
    return [e.flatten(0, 1) for e in image_features.split(num_patches.tolist())]
except RuntimeError as e:
    logger.error(f"Image processing failed: {e}")
    raise InvalidImageError("Failed to process image features") from e
```

### Fixes

* https://github.com/vllm-project/vllm/pull/29881
GitHub Security Advisory: GHSA-mjjp-xjfg-97wg
Package: lief (PIP)
Severity: LOW (CVSS 3.3)
CWE: CWE-404: Improper Resource Shutdown or Release, CWE-476: NULL Pointer Dereference
Vulnerable versions: < 0.17.2
Patched in: 0.17.2

Summary: LIEF is vulnerable to segmentation fault

Details:
A security flaw has been discovered in lief-project LIEF up to 0.17.1. Affected by this issue is the function Parser::parse_binary of the file src/ELF/Parser.tcc of the component ELF Binary Parser. The manipulation results in null pointer dereference. The attack must be initiated from a local position. The exploit has been released to the public and may be used for attacks. Upgrading to version 0.17.2 can resolve this issue. The patch is identified as 81bd5d7ea0c390563f1c4c017c9019d154802978. It is recommended to upgrade the affected component.
GitHub Security Advisory: GHSA-9rp8-h4g8-8766
Package: wlc (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-922: Insecure Storage of Sensitive Information
Vulnerable versions: < 1.17.0
Patched in: 1.17.0

Summary: Weblate wlc has insecure API key configuration

Details:
### Impact
Historically, wlc supported providing unscoped API keys in the setting. This practice was discouraged for years, but the code was never removed. This might cause the API key to be used against different server.

### Patches
* https://github.com/WeblateOrg/wlc/pull/1098

### Workarounds
Remove unscoped `key` from wlc configuration. Only use URL-scoped keys in the `[keys]` sections.

### References
This issue was reported to us by [wh1zee](https://hackerone.com/wh1zee) via HackerOne.
GitHub Security Advisory: GHSA-2mmv-7rrp-g8xh
Package: wlc (PIP)
Severity: LOW (CVSS 2.5)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 1.17.0
Patched in: 1.17.0

Summary: Weblate command-line client susceptible to SSL verification skip

Details:
### Impact
The SSL verification would be skipped for some crafted URLs.

### Patches
* https://github.com/WeblateOrg/wlc/pull/1097

### Workarounds
Avoid using untrusted wlc configurations, as that might cause insecure connections.

### References
This issue was reported to us by [wh1zee](https://hackerone.com/wh1zee) via HackerOne.
GitHub Security Advisory: GHSA-qqhf-pm3j-96g7
Package: MindsDB (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-23: Relative Path Traversal, CWE-36: Absolute Path Traversal
Vulnerable versions: < 25.11.1
Patched in: 25.11.1

Summary: MindsDB has improper sanitation of filepath that leads to information disclosure and DOS

Details:
### Summary

[BlueRock](https://bluerock.io/) discovered an unauthenticated path traversal in the file upload API lets any caller read arbitrary files from the server filesystem and move them into MindsDB’s storage, exposing sensitive data. 

### Details
The PUT handler in file.py directly joins user-controlled data into a filesystem path when the request body is JSON and `source_type` is not `"url"`:

- `data = request.json` (line ~104) accepts attacker input without validation.
- `file_path = os.path.join(temp_dir_path, data["file"])` (line ~178) creates the path inside a temporary directory, but if `data["file"]` is absolute (e.g., `/home/secret.csv`), `os.path.join` ignores `temp_dir_path` and targets the attacker-specified location.
- The resulting path is handed to `ca.file_controller.save_file(...)`, which wraps `FileReader(path=source_path)` (`mindsdb/interfaces/file/file_controller.py:66`), causing the application to read the contents of that arbitrary file. The subsequent `shutil.move(file_path, ...)` call also relocates the victim file into MindsDB’s managed storage.

Only multipart uploads and URL-sourced uploads receive sanitization; JSON uploads lack any call to `clear_filename` or equivalent checks.

### PoC
1. Run MindsDB in Docker:
   ```bash
   docker pull mindsdb/mindsdb:latest
   docker run --rm -it -p 47334:47334 --name mindsdb-poc mindsdb/mindsdb:latest
   ```
2. Execute the exploit from the host (save as poc.py and run with `python poc.py`):
   ```python
   # poc.py
   import requests, json

   base = "http://127.0.0.1:47334"
   payload = {"file": "../../../../../etc/passwd"}  # no source_type -> hits vulnerable branch

   r = requests.put(f"{base}/api/files/leak_rel", json=payload, timeout=10)
   print("PUT status:", r.status_code, r.text)

   q = requests.post(
       f"{base}/api/sql/query",
       json={"query": "SELECT * FROM files.leak_rel"},
       timeout=10,
   )
   print("SQL response:", json.dumps(q.json(), indent=2))
   ```
3. The SQL response returns the contents of `/etc/passwd` . The original file disappears from its source location because the handler moves it into MindsDB’s storage directory.
4. Detailed report is available on BlueRock's blog: https://www.bluerock.io/post/cve-2025-68472-mindsdb-file-upload-path-traversal

### Impact
- Any user able to reach the REST API can read and exfiltrate arbitrary files that the MindsDB process can access, potentially including credentials, configuration secrets, and private keys.