deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-h3rr-9wqj-v3c6
Package: AstrBot (PIP)
Severity: LOW (CVSS 4.7)
CWE: CWE-791: Incomplete Filtering of Special Elements
Vulnerable versions: <= 4.22.1
Patched in: unpatched

Summary: AstrBot has Incomplete Filtering of Special Elements

Details:
A security flaw has been discovered in AstrBotDevs AstrBot up to 4.22.1. This affects the function create_template of the file astrbot/dashboard/routes/t2i.py of the component Dashboard API. The manipulation results in improper neutralization of special elements used in a template engine. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
GitHub Security Advisory: GHSA-67qg-7284-2277
Package: django-s3file (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-23: Relative Path Traversal, CWE-26: Path Traversal: '/dir/../filename'
Vulnerable versions: <= 7.0.1
Patched in: 7.0.2

Summary: django-s3file is vulnerable to relative path traversal

Details:
### Impact
`S3FileMiddleware` is vulnerable to relative path traversal attacks, where an attacker can use a modified request to escape pre-signed upload locations and have the Django application load files from random locations into `request.FILES`

Depending on how files are handled, this may lead to confidentiality and integrity issues.

### Patches
Django-S3File urges all users to update to a patched version >=7.0.2.
GitHub Security Advisory: GHSA-vh75-fwv3-pqrh
Package: requests-hardened (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.2.1
Patched in: 1.2.1

Summary: requests-hardened is Vulnerable to Server-Side Request Forgery

Details:
The SSRF protection in `requests-hardened` prior to version 1.2.1 fails to block IP addresses within the RFC 6598 Shared Address Space (`100.64.0.0/10`). An attacker who can supply arbitrary URLs to `requests-hardened` could exploit this gap to access internal services hosted within `100.64.0.0/10`. This is for example relevant in environments such as AWS EKS where `100.64.0.0/10` is commonly used as the default pod CIDR.

The impact is environment-dependent, deployments that utilize the affected CIDR range for internal networking are exposed to SSRF bypass, while others may not be affected.

The issue is resolved in version 1.2.1 by extending the IP filtering logic to explicitly block the RFC 6598 range in addition to standard private addresses, as well as blocking all other reserved addresses (such as multicast) to prevent the re-occurrence of similar issues.

Version 1.2.1 is now blocking the following CIDRs:

- `192.88.99.0/24` - 6to4 relay anycast
- `100.64.0.0/10` - CG-NAT
- `5f00::/16` - IPv6 Segment Routing
- `64:ff9b::/96` - used for IPv6 & IPv4 translation (NAT64)
- `2001:20::/28` - ORCHIDv2 (overlay identifiers)
- `224.0.0.0/4` - multicast
- `ff00::/8` - multicast

## Resources

- https://github.com/python/cpython/issues/119812
- https://github.com/saleor/requests-hardened/commit/b7403f88d3b3689e57435b75b51691a160aaeef5 - the fix itself
- https://github.com/saleor/requests-hardened/commit/a266b3958bb142bca515b3c230fdea19fbda327c - follow up, adding additional support for outdated Python versions (`3.11.9` and `3.10.11` instead of only `3.11.15` and `3.10.20`)
- https://github.com/saleor/requests-hardened/releases/tag/v1.2.1
GitHub Security Advisory: GHSA-pxhg-7xr2-w7xg
Package: pptagent (PIP)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.1.36
Patched in: 1.1.36

Summary: PPTAgent: Arbitrary File Write via `save_generated_slides`

Details:
## Summary

> This vulnerability has been fixed in https://github.com/icip-cas/PPTAgent/commit/418491a9a1c02d9d93194b5973bb58df35cf9d00.

The `save_generated_slides` MCP tool accepts a pptx_path argument and writes the generated PPTX file to that path without any workspace restriction or path validation:

```python
# pptagent/mcp_server.py:288-300
async def save_generated_slides(pptx_path: str):
    """Save the generated slides to a PowerPoint file.

    Args:
        pptx_path: The path to save the PowerPoint file
    """
    pptx = Path(pptx_path)
    assert len(self.slides), (
        "No slides generated, please call `generate_slide` first"
    )
    pptx.parent.mkdir(parents=True, exist_ok=True)   # ← creates arbitrary directories
    self.empty_prs.save(pptx_path)                    # ← writes to arbitrary path
```

The call to `pptx.parent.mkdir(parents=True, exist_ok=True)` creates any intermediate directories, and `self.empty_prs.save(pptx_path)` writes a valid PPTX binary (ZIP archive) to the specified path. No is_relative_to(workspace) check is performed — contrast with download_file in deeppresenter/tools/search.py:290, which correctly enforces workspace confinement.

The server changes directory to WORKSPACE (if set) on startup, so relative paths land in the workspace. Absolute paths, however, reach any filesystem location accessible to the server process.

## Impact

The concrete attack scenarios include

1. Cron persistence (root-running server): `pptx_path = "/etc/cron.d/backdoor"` → writes a PPTX ZIP to a path the cron daemon reads; if the ZIP header is misinterpreted, this may corrupt cron or be exploitable depending on parser behaviour.
2. Dot-file overwrite: `pptx_path = "/home/user/.bashrc"` → overwrites shell init file with a binary blob containing arbitrary content in the PPTX's embedded comments/custom properties.
3. Directory traversal from workspace: `pptx_path = "../../.ssh/known_hosts.pptx"` → escapes workspace entirely.
4. Denial of service: `pptx_path = "/dev/sda"` writes to a raw device.

## Remediation

The potential fix is something like:

```python
async def save_generated_slides(pptx_path: str):
    workspace = Path(os.getcwd()).resolve()
    target = Path(pptx_path).resolve()
    if not target.is_relative_to(workspace):
        raise ValueError(f"Access denied: path outside workspace: {target}")
    target.parent.mkdir(parents=True, exist_ok=True)
    self.empty_prs.save(str(target))
```
GitHub Security Advisory: GHSA-hrcw-xc63-g29m
Package: pptagent (PIP)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.1.36
Patched in: 1.1.36

Summary: PPTAgent: Arbitrary File Write + Directory Creation via markdown_table_to_image

Details:
### Summary

The `markdown_table_to_image` tool accepts a caller-controlled path parameter and passes it directly to `get_html_table_image`:

```python
# pptagent/mcp_server.py:127-143
def markdown_table_to_image(markdown_table: str, path: str, css: str) -> str:
    """
    Args:
        path (str): The file path where the image will be saved
    """
    html = markdown_to_html(markdown_table)
    get_html_table_image(html, path, css)           # ← no path validation
    return f"Markdown table converted to image and saved to {path}"

# pptagent/utils.py:337-366
def get_html_table_image(html: str, output_path: str, css: str = None):
    parent_dir, base_name = os.path.split(output_path)
    if parent_dir and not os.path.exists(parent_dir):
        os.makedirs(parent_dir)                     # ← creates arbitrary directories
    hti = Html2Image(...)
    hti.screenshot(
        html_str=html,
        css_str=css,
        save_as=base_name,                          # ← writes image to any directory
        size=(1000, 600),
    )
```

`os.makedirs(parent_dir)` creates arbitrary directory trees, and `Html2Image.screenshot` writes the rendered image to `parent_dir/base_name`. Unlike `download_file` in the same project, there is no `is_relative_to(workspace)` guard. This behaviour can be fixed with the same pattern as the above.


### Impact

The concrete attack scenarios include

- SSH key replacement: `path = "/home/user/.ssh/authorized_keys"` — replaces the authorized_keys file with an image binary (breaks - SSH but could be an image crafted with a specific PNG/JPEG payload).
- Web shell: `path = "/var/www/html/uploads/shell.php"` — writes the rendered PNG there; the file has the .php extension but PNG content; combined with Apache Options +MultiViews or file-include vulnerabilities could be dangerous.
- Directory creation oracle: `path = "/root/test/probe.png"` — if the directory is created, confirms the target path exists; if it errors, reveals permissions information.
GitHub Security Advisory: GHSA-7wc8-wvc4-m498
Package: microdot (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Vulnerable versions: < 2.6.1
Patched in: 2.6.1

Summary: Microdot has HTTP response splitting in Response.set_cookie()

Details:
### Impact
The `Response.set_cookie()` method does not sanitize its string arguments, and in particular will not detect the presence of the `\r\n` sequence in them. This can be a potential source of header injection attacks.

For a header injection attack through this issue to be possible, an attacker must first infiltrate the client (for example through an independent XSS attack), so that it can send malicious information that is destined to be stored in a cookie by the server on behalf of the victim. An attacker that infiltrates one client can only orchestrate a header injection attack for that client, all other clients that were not infiltrated are safe.

### Patches
Upgrade to version 2.6.1.

### Workarounds
Do not pass untrusted data to the `Response.set_cookie()` method.
GitHub Security Advisory: GHSA-9whx-c884-c68q
Package: langflow (PIP)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.8.4
Patched in: 1.9.0

Summary: Langflow Knowledge Bases API is Vulnerable to Path Traversal

Details:
## Summary
Langflow is vulnerable to Path Traversal in the Knowledge Bases API (`DELETE /api/v1/knowledge_bases`). This occurs because user-supplied knowledge base names are concatenated directly into file paths without proper sanitization or boundary validation. An authenticated attacker can exploit this flaw to delete arbitrary directories anywhere on the server's filesystem, leading to data loss and potential service disruption.

## Details
The vulnerability exists in the `delete_knowledge_bases_bulk` function within `src/backend/base/langflow/api/v1/knowledge_bases.py`. 

This function constructs file paths directly from the user-supplied `kb_names` parameter. While other knowledge base endpoints safely route through standard path resolution (e.g., `_resolve_kb_path()`), the bulk delete handler bypasses this entirely. It builds the path manually and passes it directly to `shutil.rmtree()` without validating if the resulting path resolves outside the intended user directory.

## PoC (Proof of Concept)
For the **Bulk Delete** endpoint, an authenticated attacker can supply a traversal sequence in the `kb_names` parameter:
`../victim_user/kb_name`

Because the path is passed directly to `shutil.rmtree()` without containment checks, this payload deletes directories outside the intended scope.

## Impact
Any Langflow instance exposing this endpoint to authenticated users is vulnerable. This exposes the server to:
* **Cross-user data compromise:** Deletion of directories within another tenant's knowledge base space.
* **Arbitrary filesystem manipulation:** Directory deletion at any path on the server where the application has write permissions.
* **Service disruption & Data Loss:** Deletion of critical application files or unrecoverable data loss if backups are co-located on the same filesystem.

## Fixes
The issue was addressed in **PR #12243**, which applies `Path.resolve()` to normalize the supplied path and validates that it starts with the authenticated user's directory before deletion. Subsequent updates (backported from PR #12337) introduced robust containment checks using `Path.is_relative_to()` to prevent prefix-ambiguity bugs.

## Acknowledgements
Thanks to the security researchers who responsibly disclosed this vulnerability:
* @ddlxstudio
* @nekros1xx
GitHub Security Advisory: GHSA-fqvv-jvhr-g5jc
Package: firefighter-incident (PIP)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-306: Missing Authentication for Critical Function, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.0.54
Patched in: 0.0.54

Summary: FireFighter has unauthenticated SSRF in its Raid jira_bot endpoint that allows IAM credential theft

Details:
### Impact
  The `POST /api/v2/firefighter/raid/jira_bot` endpoint (`CreateJiraBotView`) is
  reachable without authentication (`permission_classes = [permissions.AllowAny]`).
  Its `attachments` payload is fetched server-side via `httpx.get()` with no URL
  validation, then uploaded as an attachment on the Jira ticket that gets created.

  An unauthenticated caller able to reach the ingress can coerce the pod into
  fetching arbitrary URLs — including the cloud metadata endpoint at
  `http://169.254.169.254/` — and exfiltrate the response as a Jira attachment.

  On EC2/EKS deployments that do not enforce IMDSv2, this allows theft of the
  temporary AWS credentials attached to the pod's IAM role. The docstring on the
  view claims a Bearer token is required, but the code does not enforce it.

  Affected code paths:
  - `src/firefighter/raid/views/__init__.py` — `CreateJiraBotView`
  - `src/firefighter/raid/serializers.py` — `LandbotIssueRequestSerializer.attachments`
  - `src/firefighter/raid/client.py` — `RaidJiraClient.add_attachments_to_issue`

  ### Patches
  Fixed in `firefighter-incident` `0.0.54`:
  - `CreateJiraBotView` now enforces `BearerTokenAuthentication` + `IsAuthenticated`.
  - `attachments` URLs are validated: http(s) scheme only, max 10 URLs, rejection
    of any host resolving to a private, loopback, link-local, reserved, multicast
    or unspecified IP (IPv4 and IPv6).
  - Fixes an unrelated `KeyError('attachments')` surfaced during regression testing.

  Users should upgrade to `0.0.54` or later.

  ### Workarounds
  Until upgrade is possible, any one of the following blocks end-to-end exploitation:
  - Restrict ingress access to `/api/v2/firefighter/raid/jira_bot` to trusted
    networks only (VPN, internal load balancer).
  - Rotate or revoke the Jira API token configured as `RAID_JIRA_API_PASSWORD`;
    this breaks `jira.create_issue()` before the vulnerable attachment fetch is
    reached (legitimate traffic is also blocked — emergency mitigation only).
  - Enforce IMDSv2 with `HttpPutResponseHopLimit=1` on EC2/EKS nodes. This does
    not fix the SSRF itself but neutralises the IAM-credential-theft path.

  ### Resources
  - CWE-918: Server-Side Request Forgery
  - CWE-306: Missing Authentication for Critical Function
GitHub Security Advisory: GHSA-w7rc-q6cm-f5gm
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-1220: Insufficient Granularity of Access Control
Vulnerable versions: < 3.2.1rc1
Patched in: 3.2.1rc1

Summary: Apache Airflow's asset dependency graph did not restrict nodes by the viewer's DAG read permissions

Details:
The asset dependency graph did not restrict nodes by the viewer's DAG read permissions: a user with read access to at least one DAG could browse the asset graph for any other asset in the deployment and learn the existence and names of DAGs and assets outside their authorized scope.

Users are recommended to upgrade to version 3.2.1, which fixes this issue.
GitHub Security Advisory: GHSA-p3v3-229h-mc63
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-1220: Insufficient Granularity of Access Control
Vulnerable versions: < 3.2.1rc1
Patched in: 3.2.1rc1

Summary: Apache Airflow's authenticated /ui/dags endpoint did not enforce per-DAG access control on embedded Human-in-the-Loop (HITL) and TaskInstance record

Details:
The authenticated /ui/dags endpoint did not enforce per-DAG access control on embedded Human-in-the-Loop (HITL) and TaskInstance records: a logged-in Airflow user with read access to at least one DAG could retrieve HITL prompts (including their request parameters) and full TaskInstance details for DAGs outside their authorized scope. Because HITL prompts and TaskInstance fields routinely carry operator parameters and free-form context attached to a task, the leak widens visibility of DAG-run data beyond the intended per-DAG RBAC boundary for every authenticated user.

Users are recommended to upgrade to version 3.2.1 , which fixes this issue.
GitHub Security Advisory: GHSA-m68r-v472-jgq9
Package: jupyterhub (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 4.1.0, < 5.4.5
Patched in: 5.4.5

Summary: JupyterHub has cross-origin form POSTs bypass XSRF (CWE-352)

Details:
## Summary

JupyterHub's XSRF protection (updated in 4.1.0) inappropriately treated requests with `Sec-Fetch-Mode: no-cors` as same-origin requests, which they are not, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as `/hub/spawn` and `/hub/accept-share`, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server.

## Patches

Upgrade to JupyterHub 5.4.5.

## Mitigations

If a reverse proxy is in use, drop requests to JupyterHub with `Sec-Fetch-Mode: no-cors`.
GitHub Security Advisory: GHSA-4v9x-cqc5-j645
Package: codechecker (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing, CWE-863: Incorrect Authorization
Vulnerable versions: <= 6.27.3
Patched in: unpatched

Summary: Codechecker has an authentication bypass for certain API calls

Details:
### Summary
Authentication bypass occurs when the URL ends with Authentication with certain function calls. This bypass allows assigning arbitrary permissions to any existing user in CodeChecker.

### Details

The following functions are affected under the Authentication endpoint: `getAuthorisedNames`, `getPermissionsForUser`, `hasPermission`, `addPermission`, and `removePermission`.

The vulnerability allows unauthenticated users to execute these function calls with arbitrary arguments.
In the logs, the exploit shows as follows:
```
[INFO 2026-04-23 21:23] - 127.0.0.1:42654 -- [Anonymous] POST /v6.67/Authentication@getAuthorisedNames
[INFO 2026-04-23 21:23] - 127.0.0.1:42654 -- [Anonymous] POST /v6.67/Authentication@addPermission
```

### Impact
An attacker with a CodeChecker user can effectively acquire superuser permissions by calling these endpoints.

### Patch
A patch is available at https://github.com/Ericsson/codechecker/releases/tag/v6.27.4.
GitHub Security Advisory: GHSA-5mrq-x3x5-8v8f
Package: jupyter-server (PIP)
Severity: HIGH (CVSS 6.8)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: <= 2.17.0
Patched in: 2.18.0

Summary: Jupyter Server's Authentication Cookies Remain Valid After Password Reset and Server Restart

Details:
## Summary

A persistent cookie secret vulnerability allows authenticated users to maintain indefinite access even after password changes. 

The cookie secret used to sign authentication cookies is stored in a permanent file (`~/.local/share/jupyter/runtime/jupyter_cookie_secret`) that is never automatically rotated or cleared, allowing stolen or compromised cookies to remain valid indefinitely regardless of password resets.

## PoC

- Start a Jupyter server with password authentication: `jupyter server password`, `jupyter server`
- Log in with the password and capture the authentication cookie (e.g., just login with a browser).
- Change the password to revoke access: `jupyter server password`
- Restart the server
- Use the old stolen cookie => remains valid and provides full authenticated access.

## Impact

- All jupyter-server deployments using password authentication where security incidents may occur
- Multi-user systems where one user's compromised session should be revocable by administrators
- Shared or public-facing Jupyter servers where credential rotation is a security requirement
- Any deployment where password changes are expected to revoke existing sessions

## Patches

Jupyter Server 2.18+

## Workaround

```bash
rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret
# Then restart the server
```
GitHub Security Advisory: GHSA-24qx-w28j-9m6p
Package: jupyter-server (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-777: Regular Expression without Anchors
Vulnerable versions: <= 2.17.0
Patched in: 2.18.0

Summary: Jupyter Server has a  CORS Origin Validation Bypass via `re.match()` in `allow_origin_pat` (from huntr)

Details:
Jupyter Server uses `re.match()` to validate the Origin header against the `allow_origin_pat` configuration.

Since `re.match()` only anchors at the start of the string, an attacker who controls a domain like `http://trusted.example.com.evil.com/` passes validation against a pattern intended to match only `trusted.example.com`.

### Impact

<=2.17.0

### Patches

057869a327c46730afede3eab0ca2d2e3e74acea, 49b34392feaa97735b3b777e3baf8f22f2a14ed8 

### Workarounds

Wrap your `allow_origin_pat` value with `^` and `$`

### References

https://github.com/jupyter-server/jupyter_server/pull/603
https://docs.python.org/3/library/re.html#re.fullmatch
https://docs.python.org/3/library/re.html#re.match
GitHub Security Advisory: GHSA-5789-5fc7-67v3
Package: jupyter-server (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 2.17.0
Patched in: 2.18.0

Summary: Jupyter Server: Path Traversal via incorrect startswith() root directory check allows access to sibling directories

Details:
### Summary

Jupyter Server <=2.17.0 can access directories sibling to the root directory, if it starts with the root dir's name.

### PoC

Minimal:

```
.
├── test/              <- root directory.
│   └── test.txt
└── testtest/
    └── secret.txt     <- file to exfiltrate that we should not be able to access via API
```

```bash
HOST="http://localhost:8888"
TOKEN=""
SIBLING="testtest"
TARGET="secret.txt"

curl -s -X POST \
  "$HOST/api/contents/%2e%2e/$SIBLING/$TARGET/checkpoints" \
  -H "Authorization: token $TOKEN"
```

Full PoC by @stef41: https://gist.github.com/Yann-P/66d4982a965dee8fcb8dd89db29e7006

### Impact

It is possible for an authenticated user to access content outside the server's `root_dir` in siblings directories sharing the same prefix as the `root_dir`. The attacker can escalate access, reading, writing, and deleting from sibling directories.

This can have a tangible impact for deployments using predictable naming scheme with multi-tenant server, for example `user1`, `user2`, `user3`, ..., `user10` etc, as `user1` could access and modify files of all `user10` - `user19` and higher.

In a hypothetical system where users can choose a name of their folder, an attacker could choose a single-letter username to gain access to a significant number of sibling directories.

### Workarounds

Use folder names that do not overlap.

### Acknowledgments

Thank you to @stef41 for providing a useful PoC.