deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8c4j-f57c-35cf
Package: langflow (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: <= 1.5.0
Patched in: 1.5.1

Summary: Langflow: Authenticated Users Can Read, Modify, and Delete Any Flow via Missing Ownership Check

Details:
## Vulnerability

### IDOR in `GET/PATCH/DELETE /api/v1/flow/{flow_id}`

The `_read_flow` helper in `src/backend/base/langflow/api/v1/flows.py` branched on the `AUTO_LOGIN` setting to decide whether to filter by `user_id`. When `AUTO_LOGIN` was `False` (i.e., authentication was enabled), neither branch enforced an ownership check — the query returned any flow matching the given UUID regardless of who owned it.

This exposed any authenticated user to:

- **Read** any other user's flow, including embedded plaintext API keys
- **Modify** the logic of another user's AI agents
- **Delete** flows belonging to other users

The vulnerability was introduced by the conditional logic that was meant to accommodate public/example flows (those with `user_id = NULL`) under auto-login mode, but inadvertently left the authenticated path without an ownership filter.

---

## Fix (PR #8956)

The fix removes the `AUTO_LOGIN` conditional entirely and unconditionally scopes the query to the requesting user:

```diff
-    auth_settings = settings_service.auth_settings
-    stmt = select(Flow).where(Flow.id == flow_id)
-    if auth_settings.AUTO_LOGIN:
-        stmt = stmt.where(
-            (Flow.user_id == user_id) | (Flow.user_id == None)  # noqa: E711
-        )
+    stmt = select(Flow).where(Flow.id == flow_id).where(Flow.user_id == user_id)
```

All three operations — read, update, and delete — route through `_read_flow`, so the single change covers the full attack surface. A cross-user isolation test (`test_read_flows_user_isolation`) was added to prevent regression.

---

## Acknowledgements

Langflow thanks the security researcher who responsibly disclosed this vulnerability:

- **[@chximn-dt](https://github.com/chximn-dt)**
GitHub Security Advisory: GHSA-26gm-93rw-cchf
Package: open-webui (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 0.8.6
Patched in: 0.8.6

Summary: Open WebUI has unauthorized deletion of knowledge files

Details:
### Summary
An access control check is missing when deleting a file from a knowledge base. The only check being done is that the user has write access to the knowledge base (or is admin), but NOT that the file actually belongs to this knowledge base. It is thus possible to delete arbitrary files from arbitrary knowledge bases (as long as one knows the file id)

### Details
The source code at https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/knowledge.py#L803 does not properly validate that the file being deleted belongs to the current knowledge base:
```
@router.post("/{id}/file/remove", response_model=Optional[KnowledgeFilesResponse])
def remove_file_from_knowledge_by_id(
    id: str,
    form_data: KnowledgeFileIdForm,
    delete_file: bool = Query(True),
    user=Depends(get_verified_user),
    db: Session = Depends(get_session),
):
    knowledge = Knowledges.get_knowledge_by_id(id=id, db=db)
    [...]
    # Note  : Access control check on the knowledge base
    if (
        knowledge.user_id != user.id
        and not AccessGrants.has_access(
            user_id=user.id,
            resource_type="knowledge",
            resource_id=knowledge.id,
            permission="write",
            db=db,
        )
        and user.role != "admin"
    ):
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail=ERROR_MESSAGES.ACCESS_PROHIBITED,
        )

    file = Files.get_file_by_id(form_data.file_id, db=db)
    [...]
    # Note : No checks on the file

    if delete_file:
        try:
            # Remove the file's collection from vector database
            file_collection = f"file-{form_data.file_id}"
            if VECTOR_DB_CLIENT.has_collection(collection_name=file_collection):
                VECTOR_DB_CLIENT.delete_collection(collection_name=file_collection)
        except Exception as e:
            log.debug("This was most likely caused by bypassing embedding processing")
            log.debug(e)
            pass

        # Delete file from database
        Files.delete_file_by_id(form_data.file_id, db=db)
[...]
```

### PoC
Victim has a knowledge base with a file (id: 9db6dcee-bb3b-483e-aaf3-310fda366af1)
Attacker creates their own collection (id: dde9e2b6-21c9-4aa1-a1cf-8cb0e4392f2b)
Attacker deletes the victim file from their own collection:
```
POST /api/v1/knowledge/dde9e2b6-21c9-4aa1-a1cf-8cb0e4392f2b/file/remove HTTP/1.1
Host: gaius-neo-val.fr.space.corp
Authorization: Bearer eyJhbGciOiJIUzI1[...]nHiaod-3vfNE0
[...]

{"file_id":"9db6dcee-bb3b-483e-aaf3-310fda366af1"}

-----

HTTP/1.1 200 OK
[...]
```
The file is then deleted from the victim's knowledge base.


### Impact
Arbitrary file deletion
GitHub Security Advisory: GHSA-7972-pg2x-xr59
Package: vllm (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: >= 0.10.1, < 0.18.0
Patched in: 0.18.0

Summary: vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out

Details:
### Summary

  Two model implementation files hardcode `trust_remote_code=True` when loading sub-components, bypassing the user's explicit `--trust-remote-code=False` security opt-out. This enables remote code execution via malicious model
  repositories even when the user has explicitly disabled remote code trust.

  ### Details

  **Affected files (latest main branch):**

  1. `vllm/model_executor/models/nemotron_vl.py:430`
  ```python
  vision_model = AutoModel.from_config(config.vision_config, trust_remote_code=True)
```

  2. vllm/model_executor/models/kimi_k25.py:177
 
```python
  cached_get_image_processor(self.ctx.model_config.model, trust_remote_code=True)
```

  Both pass a hardcoded trust_remote_code=True to HuggingFace API calls, overriding the user's global --trust-remote-code=False setting.

  Relation to prior CVEs:
  - CVE-2025-66448 fixed auto_map resolution in vllm/transformers_utils/config.py (config loading path)
  - CVE-2026-22807 fixed broader auto_map at startup
  - Both fixes are present in the current code. These hardcoded instances in model files survived both patches — different code paths.

### Impact

  Remote code execution. An attacker can craft a malicious model repository that executes arbitrary Python code when loaded by vLLM, even when the user has explicitly set --trust-remote-code=False. This undermines the security guarantee
  that trust_remote_code=False is intended to provide.

  Remediation: Replace hardcoded trust_remote_code=True with self.config.model_config.trust_remote_code in both files. Raise a clear error if the model component requires remote code but the user hasn't opted in.
GitHub Security Advisory: GHSA-wcjx-v2wj-xg87
Package: c2cciutils (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-674: Uncontrolled Recursion, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 1.1.65
Patched in: 1.1.66

Summary: C2C CI utils is vulnerable to DoS via pyasn dependency (CVE-2026-30922)

Details:
Pin vulnerable version of pyasn, see: See: https://github.com/advisories/GHSA-jr27-m4p2-rc6r
GitHub Security Advisory: GHSA-87mj-5ggw-8qc3
Package: pypdf (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 6.9.2
Patched in: 6.9.2

Summary: pypdf: Possible infinite loop during recovery attempts in DictionaryObject.read_from_stream

Details:
### Impact

An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires reading a file in non-strict mode.

### Patches

This has been fixed in [pypdf==6.9.2](https://github.com/py-pdf/pypdf/releases/tag/6.9.2).

### Workarounds

If users cannot upgrade yet, consider applying the changes from PR [#3693](https://github.com/py-pdf/pypdf/pull/3693).
GitHub Security Advisory: GHSA-wwv8-cqpr-vx3m
Package: modoboa (PIP)
Severity: HIGH (CVSS 7.2)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 2.7.0
Patched in: 2.7.1

Summary: Modoboa has OS Command Injection

Details:
### Summary

`exec_cmd()` in `modoboa/lib/sysutils.py` always runs subprocess calls with `shell=True`. Since domain names flow directly into shell command strings without any sanitization, a Reseller or SuperAdmin can include shell metacharacters in a domain name to run arbitrary OS commands on the server.

### Details

The root cause is in `modoboa/lib/sysutils.py:31`:

```python
kwargs["shell"] = True
process = subprocess.Popen(cmd, **kwargs)
```

When a create a domain is created with DKIM enabled, the domain name gets embedded into a shell command like this:

```python
exec_cmd(f"openssl genrsa -out {dkim_storage_dir}/{domain.name}.pem {key_size}")
```

If the domain name contains something like `$(id>/tmp/proof).example.com`, the shell executes the injected command before running openssl.

The same pattern appears in several other places:

- `modoboa/admin/jobs.py:38` — mailbox rename via `mv` using `full_address`
- `modoboa/amavis/lib.py:202` — `sa-learn` using `domain.name`
- `modoboa/admin/models/mailbox.py:150` — `doveadm user` using `full_address`
- `modoboa/maillog/graphics.py:105–107` — `rrdtool` using `domain.name`
- `modoboa/webmail/models.py:54–57` — `doveadm move/delete` using `account.email`

### PoC

1. Deploy modoboa <= 2.7.0
2. Log in as a Reseller or SuperAdmin
3. Create a new domain named `$(id>/tmp/proof).example.com` with DKIM enabled
4. SSH into the server and read `/tmp/proof`

Something like this will be displayed:

```
uid=0(root) gid=0(root) groups=0(root)
```

Confirmed on commit b521bcb4f (latest main at time of discovery).

### Impact

An attacker with Reseller-level access (or higher) can execute arbitrary OS commands on the mail server — in a typical Modoboa deployment this means running as root. All six identified sinks are reachable through normal application workflows.
GitHub Security Advisory: GHSA-gc5v-m9x4-r6x2
Package: requests (PIP)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-377: Insecure Temporary File
Vulnerable versions: < 2.33.0
Patched in: 2.33.0

Summary: Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility function

Details:
### Impact
The `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one.

### Affected usages
**Standard usage of the Requests library is not affected by this vulnerability.** Only applications that call `extract_zipped_paths()` directly are impacted.

### Remediation
Upgrade to at least Requests 2.33.0, where the library now extracts files to a non-deterministic location.

If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.
GitHub Security Advisory: GHSA-xwc8-rf6m-xr86
Package: hnswlib (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-415: Double Free
Vulnerable versions: < 0.8.0
Patched in: 0.8.0

Summary: hnswlib Double Free vulnerability

Details:
Hnswlib 0.7.0 has a double free in `init_index` when the M argument is a large integer.
GitHub Security Advisory: GHSA-5mg7-485q-xm76
Package: litellm (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-506: Embedded Malicious Code
Vulnerable versions: >= 1.82.7, <= 1.82.8
Patched in: unpatched

Summary: Two LiteLLM versions published containing credential harvesting malware

Details:
After an API Token exposure from an exploited trivy dependency, two new releases of `litellm` were uploaded to PyPI containing automatically activated malware, harvesting sensitive credentials and files, and exfiltrating to a remote API.

Anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate thema ccordingly.
GitHub Security Advisory: GHSA-5vp3-3cg6-2rq3
Package: justhtml (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: <= 1.12.0
Patched in: 1.13.0

Summary: JustHTML is vulnerable to XSS via code fence breakout in <pre> content

Details:
## Summary

`to_markdown()` is vulnerable when serializing attacker-controlled `<pre>` content. The `<pre>` handler emits a fixed three-backtick fenced code block, but writes decoded text content into that fence without choosing a delimiter longer than any backtick run inside the content.

An attacker can place backticks and HTML-like text inside a sanitized `<pre>` element so that the generated Markdown closes the fence early and leaves raw HTML outside the code block. When that Markdown is rendered by a CommonMark/GFM-style renderer that allows raw HTML, the HTML executes.

This is a bypass of the v1.12.0 Markdown hardening. That fix escaped HTML-significant characters for regular text nodes, but `<pre>` uses a separate serialization path and does not apply the same protection.

## Details

The vulnerable `<pre>` Markdown path:

- extracts decoded text from the `<pre>` subtree
- opens a fenced block with a fixed delimiter of ``````
- writes the decoded text directly into the output
- closes with another fixed ``````

Because the fence length is fixed, attacker-controlled content containing a backtick run of length 3 or more can terminate the code block. If the content also contains decoded HTML-like text such as `&lt;img ...&gt;`, that text appears outside the fence in the resulting Markdown and is treated as raw HTML by downstream Markdown renderers.

The issue is not that HTML-like text appears inside code blocks. The issue is that the serializer allows attacker-controlled `<pre>` text to break out of the fixed fence.

## Reproduction

```python
from justhtml import JustHTML

payload = "<pre>&#96;&#96;&#96;\n&lt;img src=x onerror=alert(1)&gt;</pre>"
doc = JustHTML(payload, fragment=True)  # default sanitize=True

print(doc.to_html(pretty=False))
# <pre>```
# &lt;img src=x onerror=alert(1)&gt;</pre>

print(doc.to_markdown())
# ```
# ```
# <img src=x onerror=alert(1)>
# ```

```

Rendered as CommonMark/GFM-style Markdown, that output is interpreted as:

1. Line 1 opens a fenced code block
2. Line 2 closes it
3. Line 3 is raw HTML outside the fence
4. Line 4 opens a new fence

## Impact

Applications that treat `JustHTML(..., sanitize=True).to_markdown()` output as safe for direct rendering in Markdown contexts may be exposed to XSS, depending on the downstream Markdown renderer's raw-HTML handling.

## Root Cause

The `<pre>` Markdown serializer uses a fixed fence instead of selecting a delimiter longer than the longest backtick run in the content.

## Fix

When serializing `<pre>` content to Markdown, choose a fence length longer than any backtick run present in the code block content, with a minimum length of 3.
GitHub Security Advisory: GHSA-m6m4-34cj-4hh7
Package: mindsql (PIP)
Severity: LOW (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 0.2.1
Patched in: unpatched

Summary: MindSQL is vulnerable to Code Injection through its ask_db function

Details:
A vulnerability was found in Mindinventory MindSQL up to 0.2.1. Impacted is the function ask_db of the file mindsql/core/mindsql_core.py. Performing a manipulation results in code injection. The attack can be initiated remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-r3r2-35v9-v238
Package: briefcase (PIP)
Severity: HIGH (CVSS 7.3)
CWE: CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: >= 0.3.0, < 0.3.26
Patched in: 0.3.26

Summary: Briefcase: Windows MSI Installer Privilege Escalation via Insecure Directory Permissions 

Details:
### Impact

If a developer uses Briefcase to produce an Windows MSI installer for a project, and that project is installed for All Users (i.e., per-machine scope), the installation process creates an directory that inherits all the permissions of the parent directory. Depending on the location chosen by the installing user, this may allow a low privilege but authenticated user to replace or modify the binaries installed by the application. If an administrator then runs the altered binary, the binary will run with elevated privileges.

### Patches

The problem is caused by the template used to generate the WXS file for Windows projects. It was fixed with the following PRs:

* beeware/briefcase-windows-app-template#86
* beeware/briefcase-windows-VisualStudio-template#85

These patches have been backported to the templates used in Briefcase 0.3.26, 0.4.0, and 0.4.1. Re-running `briefcase create` on your Briefcase project will result in the updated templates being used.

### Workarounds

The change from beeware/briefcase-windows-app-template#86 can be added to any existing Briefcase .wxs file generated by Briefcase 0.3.24 or later.

### Resources

beeware/briefcase#2759 is a formal bug report of the problem.
GitHub Security Advisory: GHSA-rm2q-f7jv-3cfp
Package: indico (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.3.12
Patched in: 3.3.12

Summary: Indico discloses local files resulting in Remote Code Execution through LaTeX injection 

Details:
> [!NOTE]
> If server-side LaTeX rendering is not in use (ie `XELATEX_PATH` was not set in `indico.conf`), this vulnerability does not apply.

### Impact
Due to vulnerabilities in TeXLive and obscure LaTeX syntax that allowed circumventing Indico's LaTeX sanitizer, it is possible to use specially-crafted LaTeX snippets which can read local files or execute code with the privileges of the user running Indico on the server.

### Patches
It is recommended to update to [Indico 3.3.12](https://github.com/indico/indico/releases/tag/v3.3.12) as soon as possible.
See [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.

It is also strongly recommended to enable the containerized LaTeX renderer (using `podman`), which isolates it from the rest of the system. See [the docs](https://docs.getindico.io/en/stable/installation/upgrade/#upgrading-to-3-3-12) for details - it is very easy and from now on the only recommended/supported way of using LaTeX.

### Workarounds
Remove the `XELATEX_PATH` setting from `indico.conf` (or comment it out or set it to `None`) and restart the `indico-uwsgi` and `indico-celery` services to disable LaTeX functionality.

### For more information
For any questions or comments about this advisory:

- Open a thread in [the forum](https://talk.getindico.io/)
- Send an email to [indico-team@cern.ch](mailto:indico-team@cern.ch)
GitHub Security Advisory: GHSA-7grx-3xcx-2xv5
Package: langflow (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 1.0.0, <= 1.8.1
Patched in: unpatched

Summary: langflow has Unauthenticated IDOR on Image Downloads

Details:
### Summary
The `/api/v1/files/images/{flow_id}/{file_name}` endpoint serves image files without any authentication or ownership check. Any unauthenticated request with a known flow_id and file_name returns the image with HTTP 200.

### Details
`src/backend/base/langflow/api/v1/files.py:138-164` — `download_image` takes `flow_id`: UUID as a bare path parameter with no Depends(get_flow) or `CurrentActiveUser`. All other file routes (`download_file`, `upload_file`, `list_files`, `delete_file`) use `Depends(get_flow)` which enforces both authentication and ownership. There is no global auth middleware on /api/v1; protection is per-endpoint only.

### PoC
```
curl -v "http://localhost:7860/api/v1/files/images/<flow_uuid>/<filename.png>"
# Returns HTTP 200 with image bytes, no auth header required
```

### Impact
Unauthenticated cross-tenant data leak. In a multi-tenant deployment, any attacker who can discover or guess a `flow_id` (UUIDs can be leaked through other API responses) can download any user's uploaded images without credentials.
GitHub Security Advisory: GHSA-cxqh-p2w9-fmr7
Package: PyMuPDF (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 1.26.5, < 1.26.7
Patched in: 1.26.7

Summary: PyMuPDF has a path traversal in _main_.py

Details:
A path traversal and arbitrary file write vulnerability exist in the embedded get function in '_main_.py' in PyMuPDF version, 1.26.5.
GitHub Security Advisory: GHSA-w5g8-5849-vj76
Package: nicegui (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 3.8.0
Patched in: 3.9.0

Summary: NiceGUI's unvalidated chunk size parameter in media routes can cause memory exhaustion

Details:
## Summary

NiceGUI's `app.add_media_file()` and `app.add_media_files()` media routes accept a user-controlled query parameter that influences how files are read during streaming. The parameter is passed to the range-response implementation without validation, allowing an attacker to bypass chunked streaming and force the server to load entire files into memory at once.

With large media files and concurrent requests, this can lead to excessive memory consumption, degraded performance, or denial of service.

## Impact

**Affected applications:** NiceGUI applications that serve media content via `app.add_media_file()` or `app.add_media_files()`, particularly those serving large files (video, audio).

**What an attacker can do:**
- Force the server to load entire files into memory instead of streaming them in chunks
- Amplify memory usage with concurrent requests to large media files
- Cause performance degradation, memory pressure, and potential OOM conditions

**Attack difficulty:** Low - requires only a crafted query parameter.

## Remediation

Upgrade to a patched version of NiceGUI.

As a workaround, restrict access to media endpoints or strip unexpected query parameters at a reverse proxy layer.