deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vr63-x8vc-m265
Package: pypdf (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-834: Excessive Iteration
Vulnerable versions: < 6.1.3
Patched in: 6.1.3

Summary: pypdf possibly loops infinitely when reading DCT inline images without EOF marker

Details:
### Impact

An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires parsing the content stream of a page which has an inline image using the DCTDecode filter.

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

### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3501](https://github.com/py-pdf/pypdf/pull/3501).
GitHub Security Advisory: GHSA-8mf9-rmgw-33qc
Package: smolagents (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')
Vulnerable versions: < 1.22.0
Patched in: 1.22.0

Summary: Hugging Face Smolagents XPath injection vulnerability in the search_item_ctrl_f function

Details:
Hugging Face Smolagents version 1.20.0 contains an XPath injection vulnerability in the search_item_ctrl_f function located in src/smolagents/vision_web_browser.py. The function constructs an XPath query by directly concatenating user-supplied input into the XPath expression without proper sanitization or escaping. This allows an attacker to inject malicious XPath syntax that can alter the intended query logic. The vulnerability enables attackers to bypass search filters, access unintended DOM elements, and disrupt web automation workflows. This can lead to information disclosure, manipulation of AI agent interactions, and compromise the reliability of automated web tasks. The issue is fixed in version 1.22.0.
GitHub Security Advisory: GHSA-r397-ff8c-wv2g
Package: aiomysql (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: <= 0.2.0
Patched in: 0.3.0

Summary: aiomysql allows arbitrary access to client files through vulnerability of a malicious MySQL server

Details:
### Summary
The client-side settings are not checked before sending local files to MySQL server, which allows obtaining arbitrary files from the client using a rogue server.

### Details
It is possible to create a rogue MySQL server that emulates authorization, ignores client flags and requests arbitrary files from the client by sending a LOAD_LOCAL instruction packet. Related to CVE-2019-2503.

### PoC
First, start up a rogue MySQL server that ignores client-side flags and sends LOAD_LOCAL packet to the client – tested with https://github.com/rmb122/rogue_mysql_server

1. Create a file to be stolen by the rogue server: `echo "gotcha" > /tmp/my_secret_file.txt`
2. Clone the repo: `git clone git@github.com:rmb122/rogue_mysql_server.git && cd rogue_mysql_server`
3. Build the server: `make rogue_mysql_server`
4. Generate a sample config: `rogue_mysql_server -generate`
5. In `config.yaml` change `file_list` to `["/tmp/my_secret_file.txt"]`
6. Run the server: `./rogue_mysql_server -config config.yaml`

Next, the vulnerability can be seen in action with the following script, which can be run in a second terminal:
```python3
import asyncio

import aiomysql


loop = asyncio.get_event_loop()


async def test_example():
    conn = await aiomysql.connect(
        host="127.0.0.1",
        port=3306,
        user="root",
        password="",
        db="mysql",
        loop=loop,
        local_infile=0, # note that we explicitly forbid local_infile
    )

    cursor = await conn.cursor()
    await cursor.execute("SELECT 1")
    print(cursor.description)
    r = await cursor.fetchall()
    print(r)
    await cursor.close()
    conn.close()


loop.run_until_complete(test_example())
```

The rogue server will output log messages indicating successful file read and save the contents in the `loot/` directory
```
level=info msg="Client from addr [xxx], ID [1] try to query [select 1]"
level=info msg="Now try to read file [/tmp/my_secret_file.txt] from addr [xxx], ID [1]"
level=info msg="Read success, stored at [./loot/xxx/[PII_REDACTED]10__tmp_top_secret_file.txt]"
level=info msg="Client leaved, Addr [xxx], ID [1]"
```

### Impact
This vulnerability impacts products and environments that require connection to untrusted MySQL servers or allow the possibility for them to be compromised.

### Fix suggestion
Can be fixed by porting relevant changes from PyMySQL – https://github.com/PyMySQL/PyMySQL/commit/b5e17cee46e0706dbfd707cdd2024452f0fb3267
GitHub Security Advisory: GHSA-cq46-m9x9-j8w2
Package: scapy (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 2.6.1
Patched in: unpatched

Summary: Scapy Session Loading Vulnerable to Arbitrary Code Execution via Untrusted Pickle Deserialization

Details:
### Summary

An unsafe deserialization vulnerability in Scapy <v2.7.0 allows attackers to execute arbitrary code **when a malicious session file is locally loaded via the `-s` option**. This requires convincing a user to manually load a malicious session file.

---

### Details

Scapy’s interactive shell supports session loading using gzip-compressed pickle files:

```bash
./run_scapy -s <session_file.pkl.gz>
```

Internally, this triggers:

```python
# main.py
SESSION = pickle.load(gzip.open(session_name, "rb"))
```

Since no validation or restriction is performed on the deserialized object, **any code embedded via `__reduce__()` will be executed immediately**. This makes it trivial for an attacker to drop a malicious `.pkl.gz` in a shared folder and have it executed by unsuspecting users.

The vulnerability exists in the `load_session` function, which deserializes data using `pickle.load()` on `.pkl.gz` files provided via the `-s` CLI flag or programmatically through `conf.session`.

**Affected lines in source code**:
https://github.com/secdev/scapy/blob/master/scapy/main.py#L569-L572

```python
try:
    s = pickle.load(gzip.open(fname, "rb"))
except IOError:
    try:
        s = pickle.load(open(fname, "rb"))
```

### Impact

This is a classic deserialization vulnerability which leads to Code Execution (CE) when untrusted data is deserialized.

Any user who can trick another user into loading a crafted `.pkl.gz` session file (e.g. via `-s` option) can execute arbitrary Python code.

- **Vulnerability type:** Insecure deserialization (Python `pickle`)
- **CWE**: [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html)
- **CVSS v4.0 Vector**: `CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`
- **CVSS Score**: 5.4 (Medium)
- **Impact:** Arbitrary Code Execution
- **Attack vector:** Local or supply chain (malicious `.pkl.gz`)
- **Affected users:** Any user who loads session files (even interactively)
- **Affected version:** **Scapy v2.6.1**

---

### Mitigations

- Do not use 'sessions' (the -s option when launching Scapy).
- Use the Scapy 2.7.0+ where the session mechanism has been removed.
GitHub Security Advisory: GHSA-535g-62r7-cx6v
Package: nautobot-ssot (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 3.10.0
Patched in: 3.10.0

Summary: Nautobot Single Source of Truth (SSoT) has an unauthenticated ServiceNow configuration URL

Details:
The servicenow config URL is using a generic django View with no authentication.

URL: `/plugins/ssot/servicenow/config/`

### Impact
_What kind of vulnerability is it? Who is impacted?_
An Unauthenticated attacker could access this page to view the Service Now public instance name e.g. `companyname.service-now.com`. This is considered **low-value information**.  This does not expose the Secret, the Secret Name, or the Secret Value for the Username/Password for Service-Now.com. An unauthenticated member would not be able to change the instance name, nor set a Secret. There is not a way to gain access to other pages Nautobot through the unauthenticated Configuration page.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
We highly recommend upgrading to SSoT v3.10.0 which includes this patch.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
Disable the servicenow SSoT integration
GitHub Security Advisory: GHSA-w476-p2h3-79g9
Package: uv (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: <= 0.9.4
Patched in: 0.9.5

Summary: uv has differential in tar extraction with PAX headers

Details:
### Impact

In versions 0.9.4 and earlier of uv, tar archives containing PAX headers with file size overrides were not handled properly. As a result, an attacker could contrive a source distribution (as a tar archive) that would extract differently when installed via uv versus other Python package installers.

The underlying parsing differential here originates with astral-tokio-tar, which disclosed this vulnerability as CVE-2025-62518.

In practice, the impact of this vulnerability is **low**: only source distributions can be formatted as tar archives, and source distributions execute arbitrary code at build/installation time by definition. Consequently, a parser differential in tar extraction is strictly less powerful than the capabilities already exposed to an attacker who has the ability to control source distributions. 

However, this particular source of malleability in source distributions is unintentional and not operating by design, and therefore we consider it a vulnerability despite its overlap in capabilities with intended behavior.

### Patches

Versions 0.9.5 and newer of uv address the vulnerability above. Users should upgrade to 0.9.5 or newer.

### Workarounds

Users are advised to upgrade to version 0.9.5 or newer to address this advisory.

Users should experience no breaking changes as a result of the patch above.

### References

* See CVE-2025-62518 for the corresponding advisory against astral-tokio-tar
GitHub Security Advisory: GHSA-g9qw-g6rv-3889
Package: taguette (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.5.0
Patched in: 1.5.0

Summary: Taguette vulnerable to cross-site scripting via tag name, tag description, document name and document description

Details:
### Impact
An issue has been discovered in Taguette versions prior to 1.5.0. It was possible for a project member to put JavaScript in name or description fields which would run on project load.

### Patches
Users should upgrade to Taguette 1.5.0.

### References
- https://gitlab.com/remram44/taguette/-/issues/330
GitHub Security Advisory: GHSA-7rc8-5c8q-jr6j
Package: taguette (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-15: External Control of System or Configuration Setting
Vulnerable versions: < 1.5.0
Patched in: 1.5.0

Summary: Taguette password reset link poisoning

Details:
### Impact
An issue has been discovered in Taguette versions prior to 1.5.0. It was possible for an attacker to request password reset email containing a malicious link, allowing the attacker to set the email if clicked by the victim.

### Patches
Users should upgrade to Taguette 1.5.0.

### References
- https://gitlab.com/remram44/taguette/-/issues/331
GitHub Security Advisory: GHSA-cvhh-q5g5-qprp
Package: keras (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.11.0, < 3.11.3
Patched in: 3.11.3

Summary: Keras framework vulnerable to deserialization of untrusted data

Details:
Deserialization of untrusted data can occur in versions of the Keras framework running versions 3.11.0 up to but not including 3.11.3, enabling a maliciously uploaded Keras file containing a TorchModuleWrapper class to run arbitrary code on an end user’s system when loaded despite safe mode being enabled. The vulnerability can be triggered through both local and remote files.
GitHub Security Advisory: GHSA-rmjr-87wv-gf87
Package: mammoth (PIP)
Severity: MODERATE (CVSS 9.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.3.25, < 1.11.0
Patched in: 1.11.0

Summary: Mammoth is vulnerable to Directory Traversal

Details:
Versions of the package mammoth from 0.3.25 and before 1.11.0; versions of the package mammoth from 0.3.25 and before 1.11.0; versions of the package mammoth before 1.11.0; versions of the package org.zwobble.mammoth:mammoth before 1.11.0 are vulnerable to Directory Traversal due to the lack of path or file type validation when processing a docx file containing an image with an external link (r:link attribute instead of embedded r:embed). The library resolves the URI to a file path and after reading, the content is encoded as base64 and included in the HTML output as a data URI. An attacker can read arbitrary files on the system where the conversion is performed or cause an excessive resources consumption by crafting a docx file that links to special device files such as /dev/random or /dev/zero.
GitHub Security Advisory: GHSA-rg9h-vx28-xxp5
Package: llama-index (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-377: Insecure Temporary File
Vulnerable versions: < 0.13.0
Patched in: 0.13.0

Summary: llama-index has Insecure Temporary File

Details:
The llama_index library version 0.12.33 sets the NLTK data directory to a subdirectory of the codebase by default, which is world-writable in multi-user environments. This configuration allows local users to overwrite, delete, or corrupt NLTK data files, leading to potential denial of service, data tampering, or privilege escalation. The vulnerability arises from the use of a shared cache directory instead of a user-specific one, making it susceptible to local data tampering and denial of service.
GitHub Security Advisory: GHSA-r7r6-cc7p-4v5m
Package: python-ldap (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-75: Failure to Sanitize Special Elements into a Different Plane (Special Element Injection), CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 3.4.5
Patched in: 3.4.5

Summary: python-ldap has sanitization bypass in ldap.filter.escape_filter_chars

Details:
### Summary
The sanitization method `ldap.filter.escape_filter_chars` can be tricked to skip escaping of special characters when a crafted `list` or `dict` is supplied as the `assertion_value` parameter, and the non-default `escape_mode=1` is configured.

### Details
The method `ldap.filter.escape_filter_chars` supports 3 different escaping modes. `escape_mode=0` (default) and `escape_mode=2` happen to raise exceptions when a `list` or `dict` object is supplied as the `assertion_value` parameter. However, `escape_mode=1` happily computes without performing adequate logic to ensure a fully escaped return value.

### PoC
```
>>> import ldap.filter
```
**Exploitable**
```
>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=1)
'abc@*()/xyz'
>>> ldap.filter.escape_filter_chars({"abc@*()/xyz": 1}, escape_mode=1)
'abc@*()/xyz'
```
**Not exploitable**
```
>>> ldap.filter.escape_filter_chars("abc@*()/xyz", escape_mode=1)
'abc@\\2a\\28\\29\\2fxyz'
>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib64/python3.12/site-packages/ldap/filter.py", line 41, in escape_filter_chars
    s = assertion_value.replace('\\', r'\5c')
        ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'replace'
>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib64/python3.12/site-packages/ldap/filter.py", line 36, in escape_filter_chars
    r.append("\\%02x" % ord(c))
                        ^^^^^^
TypeError: ord() expected a character, but string of length 11 found
```
### Impact
If an application relies on the vulnerable method in the `python-ldap` library to escape untrusted user input, an attacker might be able to abuse the vulnerability to launch ldap injection attacks which could potentially disclose or manipulate ldap data meant to be inaccessible to them.

With Python being a dynamically typed language, and the commonly used `JSON` format supporting `list` and `dict`, it is to be expected that Python applications may commonly forward unchecked and potentially malicious `list` and `dict` objects to the vulnerable sanitization method.

The vulnerable `escape_mode=1` configuration does not appear to be widely used.

### Suggested Fix
Add a type check at the start of the `ldap.filter.escape_filter_chars` method to raise an exception when the supplied `assertion_value` parameter is not of type `str`.
GitHub Security Advisory: GHSA-pq5p-34cr-23v9
Package: authlib (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.6.5
Patched in: 1.6.5

Summary: Authlib is vulnerable to Denial of Service via Oversized JOSE Segments

Details:
**Summary**
Authlib’s JOSE implementation accepts unbounded JWS/JWT header and signature segments. A remote attacker can craft a token whose base64url‑encoded header or signature spans hundreds of megabytes. During verification, Authlib decodes and parses the full input before it is rejected, driving CPU and memory consumption to hostile levels and enabling denial of service.

**Impact**

- Attack vector: unauthenticated network attacker submits a malicious JWS/JWT.

- Effect: base64 decode + JSON/crypto processing of huge buffers pegs CPU and allocates large amounts of RAM; a single request can exhaust service capacity.

- Observed behaviour: on a test host, the legacy code verified a 500 MB header, consuming ~4 GB RSS and ~9 s CPU before failing.

- Severity: High. CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5).

Affected Versions
Authlib ≤ 1.6.3 (and earlier) when verifying JWS/JWT tokens. Later snapshots with 256 KB header/signature limits are not affected.

**Proof of concept**

Local demo (do not run against third-party systems):
Download [jws_segment_dos_demo.py](https://github.com/user-attachments/files/22450820/jws_segment_dos_demo.py) the PoC in direcotry authlib/
Run following Command
```
python3 jws_segment_dos_demo.py --variant both --sizes "500MB" --fork-per-case

```
Environment: Python 3.13.6, Authlib 1.6.4, Linux x86_64, CPUs=8 
Sample output: Refined
<img width="1295" height="306" alt="image" src="https://github.com/user-attachments/assets/6dd8410f-bc36-4717-8cee-649bac9bf291" />




The compilation script prints separate “[ATTACKER]” (token construction) and “[SERVER]” (Authlib verification) RSS deltas so defenders can distinguish client-side preparation from server-side amplification. Regression tests authlib/tests/dos/test_jose_dos.py further capture the issue; the saved original_util.py/original_jws.py reproductions still accept the malicious payload.

**Remediation**

- Apply the upstream patch that introduces decoded size limits:

- MAX_HEADER_SEGMENT_BYTES = 256 KB

- MAX_SIGNATURE_SEGMENT_BYTES = 256 KB

- Enforce Limits in authlib/jose/util.extract_segment and _extract_signature.

- Deploy the patched release immediately.

- For additional defence in depth, reject JWS/JWT inputs above a few kilobytes at the proxy or WAF layer, and rate-limit verification endpoints.

**Workarounds (temporary)**

- Enforce input size limits before handing tokens to Authlib.

- Use application-level throttling to reduce amplification risk.

**Resources**

- Demo script: jws_segment_dos_demo.py

- Tests: authlib/tests/dos/test_jose_dos.py

- OWASP JWT Cheat Sheet (DoS guidance)
GitHub Security Advisory: GHSA-h6m2-r6h9-4c44
Package: bbot (PIP)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.7.0
Patched in: 2.7.0

Summary: BBOT's insufficient sanitization issues in gitdumper.py can lead to RCE

Details:
### Summary

bbot's `gitdumper.py` insufficiently sanitises a `.git/config` file, leading to Remote Code Execution (RCE).

bbot's `gitdumper.py` can be made to consume a malicious `.git/index` file, leading to arbitrary file write which can be used to achieve Remote Code Execution (RCE).

### Impact

A user who uses bbot to scan a malicious webserver may have arbitrary code executed on their system.
GitHub Security Advisory: GHSA-63wh-p5fx-h4vc
Package: bbot (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 2.7.0
Patched in: 2.7.0

Summary: BBOT's git_clone.py can expose users' GitHub API keys to an attacker-controlled webserver

Details:
### Summary

Due to unsafe URL handling, bbot's `git_clone.py` can be made to leak a user's github.com API key to an attacker-controlled webserver.

### Impact

A user who has placed their github.com API key in the configuration for any of the following modules:

* `github_codesearch`
* `github_workflows`
* `gitlab`
* `git_clone`
* `github_usersearch`
* `github_org`

may leak it to an untrustworthy server.
GitHub Security Advisory: GHSA-fhw8-8v9p-7jp7
Package: bbot (PIP)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.7.0
Patched in: 2.7.0

Summary: BBOT's various issues in unarchive.py can cause arbitrary file write and RCE

Details:
### Summary

Various issues in bbot's `unarchive.py` allow a malicious site to cause bbot to write arbitrary files to arbitrary locations. This can be used to achieve Remote Code Execution (RCE).

### Impact

A user who uses bbot to scan a malicious webserver may have arbitrary code executed on their system.
GitHub Security Advisory: GHSA-wv4w-6qv2-qqfg
Package: social-auth-app-django (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing, CWE-303: Incorrect Implementation of Authentication Algorithm
Vulnerable versions: < 5.6.0
Patched in: 5.6.0

Summary: Python Social Auth - Django has unsafe account association 

Details:
### Impact

Upon authentication, the user could be associated by e-mail even if the `associate_by_email` pipeline was not included. This could lead to account compromise when a third-party authentication service does not validate provided e-mail addresses or doesn't require unique e-mail addresses.

### Patches

* https://github.com/python-social-auth/social-app-django/pull/803

### Workarounds

Review the authentication service policy on e-mail addresses; many will not allow exploiting this vulnerability.