deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wxj7-3fx5-pp9m
Package: mlflow (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2.22.2
Patched in: 2.22.2

Summary: MLFlow SSRF via gateway_proxy_handler

Details:
gateway_proxy_handler in MLflow before 3.1.0 lacks gateway_path validation.
GitHub Security Advisory: GHSA-wxj7-3fx5-pp9m
Package: mlflow (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 3.0.0rc0, < 3.1.0
Patched in: 3.1.0

Summary: MLFlow SSRF via gateway_proxy_handler

Details:
gateway_proxy_handler in MLflow before 3.1.0 lacks gateway_path validation.
GitHub Security Advisory: GHSA-vcqx-v2mg-7chx
Package: mcp-neo4j-cypher (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: >= 0.2.2, < 0.4.0
Patched in: 0.4.0

Summary:  Neo4j Cypher MCP server is vulnerable to DNS rebinding 

Details:
### Impact
DNS rebinding vulnerability in Neo4j Cypher MCP server allows malicious websites to bypass Same-Origin Policy protections and execute unauthorised tool invocations against locally running Neo4j MCP instances.&nbsp;The attack relies on the user being enticed to visit a malicious website and spend sufficient time there for DNS rebinding to succeed.

### Patches
CORS Middleware added to Cypher MCP server v0.4.0 that blocks all web-based access by default.

### Workarounds
If you cannot upgrade to v0.4.0 and above, use stdio mode.

### References
[Vendor Advisory](https://neo4j.com/security/cve-2025-10193)
https://www.cve.org/CVERecord?id=CVE-2025-10193 

Credits
We want to publicly recognize the contribution of Evan Harris from [mcpsec.dev](https://mcpsec.dev/) for reporting this issue and following the responsible disclosure [policy](https://neo4j.com/trust-center/responsible-disclosure/).
GitHub Security Advisory: GHSA-765j-9r45-w2q2
Package: flask-appbuilder (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 4.8.1
Patched in: 4.8.1

Summary: Flask App Builder has an Authentication Bypass vulnerability when using non AUTH_DB methods

Details:
### Impact
When Flask-AppBuilder is configured to use OAuth, LDAP, or other non-database authentication methods, the password reset endpoint remains registered and accessible, despite not being displayed in the user interface. This allows an enabled user to reset their password and be able to create JWT tokens even after the user is disabled on the authentication provider.

### Patches
Upgrade to Flask-AppBuilder version 4.8.1 or later

### Workarounds
If immediate upgrade is not possible:
- Manually disable password reset routes in the application configuration
- Implement additional access controls at the web server or proxy level to block access to the reset my password URL.
- Monitor for suspicious password reset attempts from disabled accounts
GitHub Security Advisory: GHSA-v2p7-4pv4-3wwh
Package: infrahub-server (PIP)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-298: Improper Validation of Certificate Expiration
Vulnerable versions: >= 1.4.0, < 1.4.5
Patched in: 1.4.5

Summary: Infrahub: Deleted and expired API tokens can still authenticate

Details:
### Impact
A bug in the authentication logic will cause API tokens that were deleted and/or expired to be considered valid. This means that any API token that is associated with an active user account can authenticate successfully.

### Patches
This issue is fixed in versions `1.3.9` and `1.4.5`

### Workarounds
Users can delete or deactivate the account associated with a deleted API token to prevent that token from authenticating.
GitHub Security Advisory: GHSA-v2p7-4pv4-3wwh
Package: infrahub-server (PIP)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-298: Improper Validation of Certificate Expiration
Vulnerable versions: < 1.3.9
Patched in: 1.3.9

Summary: Infrahub: Deleted and expired API tokens can still authenticate

Details:
### Impact
A bug in the authentication logic will cause API tokens that were deleted and/or expired to be considered valid. This means that any API token that is associated with an active user account can authenticate successfully.

### Patches
This issue is fixed in versions `1.3.9` and `1.4.5`

### Workarounds
Users can delete or deactivate the account associated with a deleted API token to prevent that token from authenticating.
GitHub Security Advisory: GHSA-9mv7-3c64-mmqw
Package: xml2rfc (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.30.2
Patched in: 3.30.2

Summary: xml2rfc is vulnerable to arbitrary file reads through prepped files

Details:
### Impact

When generating PDF files, this vulnerability allows an attacker to read arbitrary files from the filesystem by injecting malicious link element into the prepped RFCXML.

### Workarounds

Test untrusted input with `link` elements with `rel="attachment"` before processing.

### References
This is related to [GHSA-cfmv-h8fx-85m7](https://github.com/ietf-tools/xml2rfc/security/advisories/GHSA-cfmv-h8fx-85m7).
GitHub Security Advisory: GHSA-p2xp-xx3r-mffc
Package: pyinstaller (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: PyInstaller has local privilege escalation vulnerability

Details:
### Impact

Due to a special entry being appended to `sys.path` during the bootstrap process of a PyInstaller-frozen application, and due to the bootstrap script attempting to load an optional module for bytecode decryption while this entry is still present in `sys.path`, an application built with PyInstaller < 6.0.0 may be tricked by an unprivileged attacker into executing arbitrary python code when **all** of the following conditions are met:

1. Application is built with PyInstaller < 6.0.0; both onedir and onefile mode are affected.
2. Optional bytecode encryption code feature was **not** enabled during the application build.
3. The attacker can create files/directories in the same directory where the executable is located.
4. The filesystem supports creation of files/directories that contain `?` in their name (i.e., non-Windows systems).
5. The attacker is able to determine the offset at which the PYZ archive is embedded in the executable.

The attacker can create a directory (or a zip archive) next to the executable, with the name that matches the format used by PyInstaller's bootloader to transmit information about the location of PYZ archive to the bootstrap script. If this directory (or zip archive) contains a python module whose name matches the name used by the optional bytecode encryption feature, this module will be loaded and executed by the bootstrap script (in the absence of the real, built-in module that is available when the bytecode-encryption feature is enabled). This results in arbitrary code execution that requires no modification of the executable itself.

If the executable is running with elevated privileges (for example, due to having the `setuid` bit set), the code in the injected module is also executed with the said elevated privileges, resulting in a local privilege escalation.

### Patches

PyInstaller 6.0.0 (f5adf291c8b832d5aff7632844f7e3ddf7ad4923) removed support for bytecode encryption; this effectively removes the described attack vector, due to the bootstrap script not attempting to load the optional module for bytecode-decryption anymore.

PyInstaller 6.10.0 (cfd60b510f95f92cb81fc42735c399bb781a4739) reworked the bootstrap process to avoid (ab)using `sys.path` for transmitting location of the PYZ archive, which further eliminates the possibility of described injection procedure.

### Workarounds

If upgrading PyInstaller is no feasible, this issue can be worked around by ensuring proper permissions on directories containing security-sensitive executables (i.e., executables with `setuid` bit set) should mitigate the issue.
GitHub Security Advisory: GHSA-7cf7-9wrr-vrf4
Package: indico (PIP)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.3.7
Patched in: 3.3.8

Summary: Indico vulnerable to Cross-Site Scripting via LaTeX math code

Details:
### Impact
There is a Cross-Site-Scripting vulnerability when rendering LaTeX math code in contribution or abstract descriptions. 

### Patches
You should to update to [Indico 3.3.8](https://github.com/indico/indico/releases/tag/v3.3.8) as soon as possible.
See [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.

### Workarounds
Only let trustworthy users create content on Indico.

Note that a conference doing a Call for Abstracts actively invites external speakers (who the organizers may not know and thus cannot fully trust) to submit content, hence the need to update to a a fixed version ASAP in particular when using such workflows.

### For more information
If you have any questions or comments about this advisory:

- Open a thread in [our forum](https://talk.getindico.io/)
- Email us privately at [indico-team@cern.ch](mailto:indico-team@cern.ch)
GitHub Security Advisory: GHSA-4269-mcfh-cp7q
Package: indico (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 3.3.7
Patched in: 3.3.8

Summary: Indico may disclose unauthorized user details access via legacy API

Details:
### Impact
A legacy API to retrieve user details could be misused to retrieve profile details of other users without having admin permissions due to a broken access check.

### Patches
You should to update to [Indico 3.3.8](https://github.com/indico/indico/releases/tag/v3.3.8) as soon as possible.
See [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.

### Workarounds
It is possible to restrict access to the affected API (e.g. in the webserver config) which is most likely unused anyway and thus will not break anything.

### For more information
If you have any questions or comments about this advisory:

- Open a thread in [our forum](https://talk.getindico.io/)
- Email us privately at [indico-team@cern.ch](mailto:indico-team@cern.ch)
GitHub Security Advisory: GHSA-f7qq-56ww-84cr
Package: picklescan (PIP)
Severity: CRITICAL (CVSS 8.3)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 0.0.30
Patched in: 0.0.31

Summary: Picklescan is Vulnerable to Unsafe Globals Check Bypass through Subclass Imports

Details:
### Summary
The vulnerability allows malicious actors to bypass PickleScan's unsafe globals check, leading to potential arbitrary code execution. The issue stems from PickleScan's strict check for full module names against its list of unsafe globals. By using subclasses of dangerous imports instead of the exact module names, attackers can circumvent the check and inject malicious payloads.

### PoC
1. Download a model that uses the `asyncio` package: 

```wget https://huggingface.co/iluem/linux_pkl/resolve/main/asyncio_asyncio_unix_events___UnixSubprocessTransport__start.pkl```

2. Check with PickleScan: `picklescan -p asyncio_asyncio_unix_events___UnixSubprocessTransport__start.pkl -g`

**Expected Result:**

PickleScan should identify all `asyncio` import as dangerous and flag the pickle file as malicious as `asyncio` is in `_unsafe_globals` dictionary.

**Actual Result:**
![Screenshot 2025-06-29 at 14 13 38](https://github.com/user-attachments/assets/39467f50-5cdb-4c25-bb37-35c03dc4a626)

PickleScan marked the import as Suspicious, failing to identify it as a dangerous import.

### Impact
**Severity**: High
**Affected Users**: Any organization, like HuggingFace, or individual using PickleScan to analyze PyTorch models or other files distributed as ZIP archives for malicious pickle content.
**Impact Details**: Attackers can craft malicious PyTorch models containing embedded pickle payloads, package them into ZIP archives, and bypass the PickleScan check by using subclasses of dangerous imports. This could lead to arbitrary code execution on the user's system when these malicious files are processed or loaded.

**Recommendations:**

**Replace:**
https://github.com/mmaitre314/picklescan/blob/2a8383cfeb4158567f9770d86597300c9e508d0f/src/picklescan/scanner.py#L309C9-L309C54


  `      unsafe_filter = _unsafe_globals.get(g.module)`

by:
```
      matched_key = None
        if imported_global.module:
            for key_in_globals in unsafe_globals.keys():
                # Check if imported_global.module starts with the key_in_globals AND
                # (it's the first match OR this key is more specific than the previous match)
                # AND imported_global.module is exactly the key or imported_global.module is key + '.' + something
                if imported_global.module.startswith(key_in_globals):
                    if (imported_global.module == key_in_globals or # Exact match
                            (len(imported_global.module) > len(key_in_globals) and imported_global.module[len(key_in_globals)] == '.')): # Submodule match
                        if matched_key is None or len(key_in_globals) > len(matched_key):
                            matched_key = key_in_globals

        if matched_key:
            unsafe_filter = unsafe_globals[matched_key]
```
GitHub Security Advisory: GHSA-6w2r-r2m5-xq5w
Package: Django (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 5.2a1, < 5.2.6
Patched in: 5.2.6

Summary: Django is subject to SQL injection through its column aliases

Details:
An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed QuerySet.annotate() or QuerySet.alias().
GitHub Security Advisory: GHSA-6w2r-r2m5-xq5w
Package: Django (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 5.0a1, < 5.1.12
Patched in: 5.1.12

Summary: Django is subject to SQL injection through its column aliases

Details:
An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed QuerySet.annotate() or QuerySet.alias().
GitHub Security Advisory: GHSA-6w2r-r2m5-xq5w
Package: Django (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.2.24
Patched in: 4.2.24

Summary: Django is subject to SQL injection through its column aliases

Details:
An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed QuerySet.annotate() or QuerySet.alias().
GitHub Security Advisory: GHSA-49mj-x8jp-qvfc
Package: octoprint (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 1.11.3
Patched in: 1.11.3

Summary: OctoPrint is Vulnerable to RCE Attacks via Unsanitized Filename in File Upload

Details:
### Impact

OctoPrint versions up until and including 1.11.2 contain a vulnerability that allows an **authenticated** attacker to upload a file under a specially crafted filename that will allow arbitrary command execution if said filename becomes included in a command defined in a system event handler and said event gets triggered.

If no event handlers executing system commands with uploaded filenames as parameters have been configured, this vulnerability does not have an impact.

### Patches

The vulnerability will be patched in version 1.11.3.

### Workaround

Until the patch has been applied, OctoPrint administrators who have event handlers configured that include any kind of filename based placeholders (i.e. `{__filename}`, `{__filepath}`, `{filename}`, `{path}`, etc -- refer to [the events documentation](https://docs.octoprint.org/en/master/events/index.html#placeholders) for a full list) should disable those by setting their `enabled` property to `False` or unchecking the "Enabled" checkbox in the GUI based Event Manager.

Alternatively, OctoPrint administrators should set `feature.enforceReallyUniversalFilenames` to `true` in `config.yaml` and restart OctoPrint, then vet the existing uploads and make sure to delete any suspicious looking files (e.g. those that contain a `;` in their name followed by a command).

As always, OctoPrint administrators are advised to not expose OctoPrint on hostile networks like the public internet, and to vet who has access to their instance.

### Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by @prabhatverma47.
GitHub Security Advisory: GHSA-pxvw-4w88-6x95
Package: copyparty (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-552: Files or Directories Accessible to External Parties, CWE-862: Missing Authorization
Vulnerable versions: < 1.19.8
Patched in: 1.19.8

Summary: copyparty: Sharing a single file does not fully restrict access to other files in source folder

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

When a share is created for just one file inside a folder, it was possible to access the other files inside that folder by guessing 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.
GitHub Security Advisory: GHSA-hjfh-p8f5-24wr
Package: ethyca-fides (PIP)
Severity: HIGH (CVSS 7.2)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2.69.1
Patched in: 2.69.1

Summary: Fides Webserver API is Vulnerable to OAuth Client Privilege Escalation

Details:
### Summary
The OAuth client creation and update endpoints of the Fides Webserver API do not properly authorize scope assignment. This allows highly privileged users with `client:create` or `client:update` permissions to escalate their privileges to owner-level.

### Details
When creating or updating OAuth clients, the API validates only that requested scopes exist in the system registry. It does not verify that the requester already possesses the scopes they are assigning, allowing these users to assign arbitrary scopes to OAuth clients.

### Impact
This allows contributor-level users to escalate to owner-equivalent privileges, gaining access to user management, system configuration, and permission assignment capabilities they should not possess.

### Patches
The vulnerability has been patched in Fides version `2.69.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.

### Workarounds
There are no workarounds.

### Risk Level
This vulnerability has been assigned a severity of HIGH. Contributor users are already highly privileged, only a handful of scopes are not already available to them, but these scopes can be abused for high impact.
GitHub Security Advisory: GHSA-fq34-xw6c-fphf
Package: ethyca-fides (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts, CWE-770: Allocation of Resources Without Limits or Throttling, CWE-799: Improper Control of Interaction Frequency
Vulnerable versions: < 2.69.1
Patched in: 2.69.1

Summary: Fides Webserver API Rate Limiting Vulnerability in Proxied Environments

Details:
### Summary

The Fides Webserver API's built-in IP-based rate limiting is ineffective in environments with CDNs, proxies or load balancers. The system incorrectly applies rate limits based on directly connected infrastructure IPs rather than client IPs, and stores counters in-memory rather than in a shared store. This allows attackers to bypass intended rate limits and potentially cause denial of service.

This vulnerability only affects deployments relying on Fides's built-in rate limiting for protection. Deployments using external rate limiting solutions (WAFs, API gateways, etc.) are not affected.

### Details

The vulnerability has two components:

1. Rate limiting uses the immediate connection source IP instead of the actual client IP
2. Rate limit counters are maintained in-memory per container rather than in a shared store

In production environments, these issues allow clients to exceed intended rate limits and enable attackers to trigger rate limits on infrastructure IPs, causing legitimate clients to receive 429 responses.

### Impact

This vulnerability affects availability, allowing attackers to:

- Bypass rate limits, potentially leading to resource exhaustion
- Cause a denial of service for legitimate clients by deliberately triggering rate limits on infrastructure IPs

### Patches

The vulnerability has been patched in Fides version `2.69.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.

### Workarounds

There are no application-level workarounds. However, rate limiting may instead be implemented externally at the infrastructure level using a WAF, API Gateway, or similar technology.

### Risk Level

This vulnerability has been assigned a severity of MEDIUM.
GitHub Security Advisory: GHSA-7q62-r88r-j5gw
Package: ethyca-fides (PIP)
Severity: LOW (CVSS 6.5)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts
Vulnerable versions: < 2.69.1
Patched in: 2.69.1

Summary: Fides has a Lack of Brute-Force Protections on Authentication Endpoints

Details:
### Summary

The Fides Admin UI login endpoint relies on a general IP-based rate limit for all API traffic and lacks specific anti-automation controls designed to protect against brute-force attacks. This could allow attackers to conduct credential testing attacks, such as credential stuffing or password spraying, which poses a risk to accounts with weak or previously compromised passwords.

### Details

Fides uses a configurable, system-wide rate limit to control traffic from any single IP address. Because this single limit must be set high enough to accommodate endpoints that receive a large volume of legitimate traffic, it offers only weak protection for the login endpoint. The system is not equipped with more advanced protections tailored specifically for authentication

### Impact

Although password complexity requirements and the global rate limit make a traditional brute-force attack against a single account  difficult, the lack of authentication-specific protections exposes Fides to more targeted attacks. An attacker could use automated tools to test credentials obtained from data breaches or guess common passwords across multiple user accounts. If an attacker successfully compromises an account, they would gain full access to that user's privileges within the Fides Admin UI.

### Patches

The vulnerability has been patched in Fides version `2.69.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.

### Workarounds

For organizations with commercial Fides Enterprise licenses, configuring Single Sign-On (SSO) through an OIDC provider (like Azure, Google, or Okta) is an effective workaround. When OIDC SSO is enabled, username/password authentication can be disabled entirely, which eliminates this attack vector. This functionality is not available for Fides Open Source users.

### Risk Level

This vulnerability has been assigned a severity of **LOW**.

This is fundamentally a security hardening issue. While the lack of authentication-specific rate limiting could enable credential stuffing attacks, several factors limit the risk: existing global rate limits provide baseline protection, password complexity requirements prevent trivial brute-force attacks, and successful exploitation requires attackers to already possess valid credentials from external breaches.