deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-cwxj-rr6w-m6w7
Package: Scrapy (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: >= 1.4.0, <= 2.14.1
Patched in: 2.14.2

Summary: Scrapy: Arbitrary Module Import via Referrer-Policy Header in RefererMiddleware

Details:
### Impact

Since version 1.4.0, Scrapy respects the `Referrer-Policy` response header to decide whether and how to set a `Referer` header on follow-up requests.

If the header value looked like a valid Python import path, Scrapy would import the referenced object and call it, assuming it referred to a referrer policy class (for example, `scrapy.spidermiddlewares.referer.DefaultReferrerPolicy`) and attempting to instantiate it to handle the `Referer` header.

A malicious site could exploit this by setting `Referrer-Policy` to a path such as `sys.exit`, causing Scrapy to import and execute it and potentially terminate the process.

### Patches

Upgrade to Scrapy 2.14.2 (or later).

### Workarounds

If you cannot upgrade to Scrapy 2.14.2, consider the following mitigations.

- **Disable the middleware:** If you don't need the `Referer` header on follow-up requests, set [`REFERER_ENABLED`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referer-enabled) to `False`.
- **Set headers manually:** If you do need a `Referer`, disable the middleware and set the header explicitly on the requests that require it.
- **Set `referrer_policy` in request metadata:** If disabling the middleware is not viable, set the [`referrer_policy`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referrer-policy) request meta key on all requests to prevent evaluating preceding responses' `Referrer-Policy`. For example:

```python
Request(
    url,
    meta={
        "referrer_policy": "scrapy.spidermiddlewares.referer.DefaultReferrerPolicy",
    },
)
```

Instead of editing requests individually, you can:

- implement a custom [spider middleware](https://docs.scrapy.org/en/latest/topics/spider-middleware.html) that runs before the built-in referrer policy middleware and sets the `referrer_policy` meta key; or
- set the meta key in start requests and use the [scrapy-sticky-meta-params](https://github.com/heylouiz/scrapy-sticky-meta-params) plugin to propagate it to follow-up requests.

If you want to continue respecting legitimate `Referrer-Policy` headers while protecting against malicious ones, disable the built-in referrer policy middleware by setting it to `None` in [`SPIDER_MIDDLEWARES`](https://docs.scrapy.org/en/latest/topics/settings.html#std-setting-SPIDER_MIDDLEWARES) and replace it with the fixed implementation from Scrapy 2.14.2.

If the Scrapy 2.14.2 implementation is incompatible with your project (for example, because your Scrapy version is older), copy the corresponding middleware from your Scrapy version, apply the same patch, and use that as a replacement.
GitHub Security Advisory: GHSA-f38f-5xpm-9r7c
Package: CairoSVG (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 2.8.2
Patched in: 2.9.0

Summary: CairoSVG vulnerable to Exponential DoS via recursive <use> element amplification

Details:
## Summary

Kozea/CairoSVG (~300K downloads/week) has exponential denial of service via recursive `<use>` element amplification in `cairosvg/defs.py` (line ~335). This causes CPU exhaustion from a small input.

## Severity

High — CVSS 3.1: 7.5
Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`

## Vulnerable Code

File: `cairosvg/defs.py` (line ~335), function `use()`

The `use()` function recursively processes `<use>` elements without any depth or count limits. With 5 levels of nesting and 10 references each, a 1,411-byte SVG triggers 10^5 = 100,000 render calls.

## Impact

- 1,411-byte SVG payload pins CPU at 100% indefinitely
- Memory stays flat at ~43MB — no OOM kill, process never terminates
- Any service accepting SVG input (thumbnailing, PDF generation, avatar rendering) is DoS-able
- Amplification factor: O(10^N) rendering calls from O(N) input

## Proof of Concept

Save as `poc.svg` and run `timeout 10 cairosvg poc.svg -o test.png`:

```xml
<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <g id="a"><rect width="1" height="1"/></g>
    <g id="b"><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/></g>
    <g id="c"><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/></g>
    <g id="d"><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/></g>
    <g id="e"><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/></g>
  </defs>
  <use xlink:href="#e"/>
</svg>
```

Expected: `timeout` kills the process after 10 seconds (it never completes on its own).

Alternatively test with Python:
```python
import cairosvg, signal
signal.alarm(5)  # Kill after 5 seconds
try:
    cairosvg.svg2png(bytestring=open("poc.svg").read())
except:
    print("[!!!] CONFIRMED: CPU exhaustion — process did not complete in 5s")
```

## Suggested Fix

Add recursion depth counter to `use()` function. Cap at e.g. 10 levels. Also add total element budget to prevent amplification.

## References

- [CWE-400](https://cwe.mitre.org/data/definitions/400.html)

## Credit

Kai Aizen (SnailSploit) — Adversarial AI & Security Research
GitHub Security Advisory: GHSA-4g4c-mfqg-pj8r
Package: magic-wormhole (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.21.0, < 0.23.0
Patched in: 0.23.0

Summary: Magic Wormhole: "wormhole receive" allows arbitrary local file overwrite

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

Receiving a file (`wormhole receive`) from a malicious party could result in overwriting critical local files, including `~/.ssh/authorized_keys` and `.bashrc`. This could be used to compromise the receiver's computer.

Only the sender of the file (the party who runs `wormhole send`) can mount the attack. Other parties (including the transit/relay servers) are excluded by the wormhole protocol.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

The bug has been fixed in magic-wormhole 0.23.0. All users should upgrade to this version.

The vulnerability first surfaced in the 0.21.0 release on 23-Oct-2025.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

As a workaround, the receiver can override the sender's filename with the `--output` or `-o` option. For example: `wormhole receive -o shopping-list.txt` will write the file to `shopping-list.txt` in the local directory, regardless of what the sender tries to do. To be effective, this option must be added to every invocation of `wormhole receive` / `wormhole rx`.

### References
_Are there any links users can visit to find out more?_

Incoming file transfer requests include a `filename`, used to decide where the file contents will be written. Well-behaving senders compute this from the `basename()` of the sent file (which discards all but the last segment of the path). To guard against malicious senders, the receiver also applies `basename()` to the incoming filename. During refactoring in version 0.21.0, this receiver-side check was accidentally dropped. The check was restored in version 0.23.0 along with a unit test.

Many thanks to Ian McKenzie (@ikmckenz) for spotting the bug and reaching out with a fix.
GitHub Security Advisory: GHSA-hx9q-6w63-j58v
Package: orjson (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 3.11.6
Patched in: 3.11.6

Summary: orjson does not limit recursion for deeply nested JSON documents

Details:
The orjson.dumps function in orjson before 3.11.6 does not limit recursion for deeply nested JSON documents.
GitHub Security Advisory: GHSA-hhfx-wfvq-7g9c
Package: msmcp-azure (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2.0.0b14, < 2.0.0b17
Patched in: 2.0.0b17

Summary: Azure MCP Server has Server-Side Request Forgery issue that allows authorized attacker to elevate privileges over a network

Details:
Server-Side Request Forgery (SSRF) in Azure MCP Server allows an authorized attacker to elevate privileges over a network.
GitHub Security Advisory: GHSA-3936-cmfr-pm3m
Package: black (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 26.3.1
Patched in: 26.3.1

Summary: Black: Arbitrary file writes from unsanitized user input in cache file name

Details:
### Impact

Black writes a cache file, the name of which is computed from various formatting options. The value of the `--python-cell-magics` option was placed in the filename without sanitization, which allowed an attacker who controls the value of this argument to write cache files to arbitrary file system locations. 

### Patches

Fixed in Black 26.3.1.

### Workarounds

Do not allow untrusted user input into the value of the `--python-cell-magics` option.
GitHub Security Advisory: GHSA-p2m9-wcp5-6qw3
Package: multipart (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 1.2.2
Patched in: 1.2.2

Summary: multipart vulnerable to ReDoS in `parse_options_header()`

Details:
## Summary

The `parse_options_header()` function in `multipart.py` uses a regular expression with an *ambiguous alternation*, which can cause *exponential backtracking (ReDoS)* when parsing maliciously crafted HTTP or multipart segment headers. This can be abused for **denial of service (DoS)** attacks against web applications using this library to parse request headers or `multipart/form-data` streams.

## Impact

Any WSGI or ASGI application using `multipart.parse_form_data()` directly or indirectly (e.g. while parsing `multipart/form-data` streams) is vulnerable. The slow-down is significant enough to block request handling threads for multiple seconds per request.

## Affected versions

All versions up to and including `1.3.0` are affected. The issue is fixed in `1.2.2`, `1.3.1` and `1.4.0-dev`.
GitHub Security Advisory: GHSA-p2m9-wcp5-6qw3
Package: multipart (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 1.3.0, < 1.3.1
Patched in: 1.3.1

Summary: multipart vulnerable to ReDoS in `parse_options_header()`

Details:
## Summary

The `parse_options_header()` function in `multipart.py` uses a regular expression with an *ambiguous alternation*, which can cause *exponential backtracking (ReDoS)* when parsing maliciously crafted HTTP or multipart segment headers. This can be abused for **denial of service (DoS)** attacks against web applications using this library to parse request headers or `multipart/form-data` streams.

## Impact

Any WSGI or ASGI application using `multipart.parse_form_data()` directly or indirectly (e.g. while parsing `multipart/form-data` streams) is vulnerable. The slow-down is significant enough to block request handling threads for multiple seconds per request.

## Affected versions

All versions up to and including `1.3.0` are affected. The issue is fixed in `1.2.2`, `1.3.1` and `1.4.0-dev`.
GitHub Security Advisory: GHSA-pf93-j98v-25pv
Package: ha-mcp (PIP)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 7.0.0
Patched in: 7.0.0

Summary: ha-mcp has XSS via Unescaped HTML in OAuth Consent Form

Details:
### Summary

The ha-mcp OAuth consent form renders user-controlled parameters via Python f-strings with no HTML escaping. An attacker who can reach the OAuth endpoint and convince the server operator to follow a crafted authorization URL could execute JavaScript in the operator's browser. This affects only users running the beta OAuth mode (`ha-mcp-oauth`), which is not part of the standard setup and requires explicit configuration.

### Details

**Unescaped f-string rendering**

`consent_form.py` builds HTML using Python f-strings. No call to `html.escape()` exists anywhere in the file. The following values are rendered unescaped:

- `client_name` / `client_id` — in HTML element context (lines 299, 303)
- `client_id`, `redirect_uri`, `state` — in HTML attribute context (lines 310–312), where a `"` character breaks out of `value=""`
- `error_message`, `error`, `error_description` — in error display paths (lines 36–40, 496–497)

An attacker can register a client with a malicious `client_name` via the `/register` (DCR) endpoint, which accepts `client_name` without sanitization. If the server operator then visits a crafted authorization URL for that client, the payload executes in their browser.

**Open Dynamic Client Registration**

DCR is enabled by default with no initial access token required. This is intentional: Claude.ai and ChatGPT must self-register on first use, which is the standard MCP OAuth flow (RFC 7591). Requiring a pre-shared token would break those integrations. Registration alone grants no access — authorization requires an explicit action by the server operator.

### Impact

**Affected configuration:** OAuth mode only (`ha-mcp-oauth`, requires `MCP_BASE_URL`). This mode is in beta and is not included in the main setup documentation. The vast majority of ha-mcp users run stdio mode, which is not affected.

**Attack requirements:**
1. The attacker can reach the ha-mcp OAuth endpoint (it binds to `0.0.0.0` in HTTP mode)
2. The attacker registers a malicious client via `/register`
3. The attacker convinces the **server operator** — the person who set up ha-mcp — to follow a crafted authorization URL for an unrecognized application

Step 3 is a meaningful social engineering bar: the consent form displays the (unfamiliar) application name, and the operator has no legitimate reason to authorize an OAuth client they didn't initiate through Claude.ai or ChatGPT. Normal usage involves being redirected to the consent form from one of those platforms, not from an external link.

If exploited, a JavaScript payload could exfiltrate data entered into the consent form, including the Home Assistant Long-Lived Access Token.

### Fix

Upgrade to 7.0.0
GitHub Security Advisory: GHSA-rcp6-88mm-9vgf
Package: copyparty (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.20.12
Patched in: 1.20.12

Summary: Copyparty has unexpected JavaScript execution via crafted URL to folder with `.prologue.html`

Details:
If an attacker has been given both read- and write-permissions to the server, they can upload a malicious file with the filename `.prologue.html` and then craft a link to potentially execute arbitrary JavaScript in the victim's context.

Note that it is intended behavior that the JavaScript would execute if the target clicks a link to the HTML file itself; "https://example.com/foo/.prologue.html". The vulnerability is that "https://example.com/foo/?b" would also evaluate the file, making the behavior unexpected.

There are existing preventative measures (strict SameSite cookies) which makes it harder to leverage this vulnerability in an attack; in order to gain control of the target's authenticated session, the link must be clicked from a page served by the server itself -- most likely by editing an existing resource, which would require additional access permissions.

Finally, for this attack to be successful, the attacker's target must click the specific crafted link given by the attacker. This vulnerability is not activated by normally browsing the web-UI on the server.

## Impact

If successful, the malicious JavaScript could move or delete existing files on the server, or upload new files, using the account of the person who opens the link.
GitHub Security Advisory: GHSA-67rw-2x62-mqqm
Package: copyparty (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.20.12
Patched in: 1.20.12

Summary: Copyparty ftp/sftp: Sharing a single file did not fully restrict source-folder access

Details:
There was a missing permission-check in the shares feature (the `shr` global-option).

This vulnerability only applies in the following scenario:
* The [shares](https://github.com/9001/copyparty/#shares) feature is used for the specific purpose of creating a share of just a single file inside a folder
* Either the FTP or SFTP server is enabled, and also made publically accessible
  * If a share is password-protected, then SFTP was not vulnerable unless the `sftp-pw` global-option was also enabled

Given these conditions, when a user is browsing a share through either FTP or SFTP (not http or https), they can gain read-access to the remaining files inside the shared folder by guessing/bruteforcing the filenames.

It was not possible to descend into subdirectories in this manner; only the sibling files were accessible.

This issue did not affect filekeys or dirkeys.

This vulnerability is [CVE-2025-58753](https://nvd.nist.gov/vuln/detail/CVE-2025-58753) which was previously fixed for HTTP and HTTPS, but not for FTP. The FTPS server did not yet exist at that time.
GitHub Security Advisory: GHSA-qjxf-f2mg-c6mc
Package: tornado (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 6.5.4
Patched in: 6.5.5

Summary: Tornado is vulnerable to DoS due to too many multipart parts

Details:
In versions of Tornado prior to 6.5.5, the only limit on the number of parts in `multipart/form-data` is the `max_body_size` setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts. 

Tornado 6.5.5 introduces new limits on the size and complexity of multipart bodies, including a default limit of 100 parts per request. These limits are configurable if needed; see `tornado.httputil.ParseMultipartConfig`. It is also now possible to disable `multipart/form-data` parsing entirely if it is not required for the application.
GitHub Security Advisory: GHSA-78cv-mqj4-43f7
Package: tornado (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 6.5.4
Patched in: 6.5.5

Summary: Tornado has incomplete validation of cookie attributes

Details:
Values passed to the `domain`, `path`, and `samesite` arguments of `RequestHandler.set_cookie` were not completely validated in versions of Tornado prior to 6.5.5. In particular, semicolons would be allowed, which could be used to inject attacker-controlled values for other cookie attributes.
GitHub Security Advisory: GHSA-hqmh-ppp3-xvm7
Package: pypdf (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 6.8.0
Patched in: 6.8.0

Summary: pypdf: manipulated stream length values can exhaust RAM

Details:
### Impact

An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing a content stream with a rather large `/Length` value, regardless of the actual data length inside the stream.

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

### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3675](https://github.com/py-pdf/pypdf/pull/3675).

As far as we are aware, this mostly affects reading from buffers of unknown size, as returned by `open("file.pdf", mode="rb")` for example. Passing a file path or a `BytesIO` buffer to *pypdf* instead does not seem to trigger the vulnerability.
GitHub Security Advisory: GHSA-ffv6-jj46-x367
Package: django-unicorn (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-284: Improper Access Control, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: < 0.67.0
Patched in: 0.67.0

Summary: django-unicorn affected by component state manipulation via unvalidated attribute access

Details:
## Summary
Component state manipulation is possible in `django-unicorn` due to missing access control checks during property updates and method calls. An attacker can bypass the intended `_is_public` protection to modify internal attributes such as `template_name` or trigger protected methods.

## Vulnerability Details: Component Access Control Bypass
Security analysis identified that the framework fails to enforce visibility boundaries defined by `_is_public` within the action parsers. Specifically, the logic in `set_property_value()` and `_call_method_name()` utilizes `getattr` and `setattr` directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:
- `src/django_unicorn/views/action_parsers/call_method.py`
- `src/django_unicorn/views/action_parsers/utils.py`

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal `reset()` method.

## Proof of Concept (PoC)
Attacker can overwrite the `template_name` attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:
   ```json
   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   ```
2. The server-side component updates its internal state: `self.template_name = "admin/base.html"`.
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

## Impact
Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.
GitHub Security Advisory: GHSA-qhqw-rrw9-25rm
Package: asyncmy (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 0.2.11
Patched in: unpatched

Summary: asyncmy is vulnerable to SQL injection via crafted dict keys

Details:
SQL injection vulnerability in long2ice asyncmy thru 0.2.10 allows attackers to execute arbitrary SQL commands via crafted dict keys.
GitHub Security Advisory: GHSA-rv5f-ccpm-xjj4
Package: apache-airflow-providers-amazon (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: < 9.22.0
Patched in: 9.22.0

Summary: Apache Airflow AWS Auth Manager has Host Header Injection Leading to SAML Authentication Bypass

Details:
In AWS Auth manager, the origin of the SAML authentication has been used as provided by the client and not verified against the actual instance URL. 
This allowed to gain access to different instances with potentially different access controls by reusing SAML response from other instances.

You should upgrade to 9.22.0 version of provider if you use AWS Auth Manager.