deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-rpw8-82v9-3q87
Package: ethyca-fides (PIP)
Severity: LOW (CVSS 4.8)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 2.69.1
Patched in: 2.69.1

Summary: Fides' Admin UI User Password Change Does Not Invalidate Current Session

Details:
### Summary

Admin UI user password changes in Fides do not invalidate active user sessions, creating a vulnerability chaining opportunity where attackers who have obtained session tokens through other attack vectors (such as XSS) can maintain access even after password reset. This issue is not directly exploitable on its own and requires a prerequisite vulnerability to obtain valid session tokens in the first place.

### Details

Fides uses encrypted authentication tokens with extended expiration periods. When a password is changed via password reset endpoints, the system updates the password hash in the database but does not invalidate existing client sessions or tokens. The authentication system validates tokens based on their cryptographic integrity and expiration time, not against the current password state.

The frontend application stores authentication state in browser local storage, which persists across browser sessions until explicit logout or natural token expiration.

This behavior alone does not constitute a directly exploitable vulnerability. The security issue only becomes exploitable when chained with other vulnerabilities or conditions that allow attackers to obtain valid session tokens, such as:

- Cross-Site Scripting (XSS) attacks that can access browser storage where tokens are stored
- Session hijacking through network interception
- Malware on the user's device that can read browser storage
- Physical device access where attackers can access browser storage directly

### Impact

This vulnerability serves as a persistence mechanism in attack chains rather than a primary attack vector. When chained with token theft vulnerabilities, it allows attackers to:

- Maintain access beyond the remediation window when users change passwords in response to suspected compromise
- Extend the impact timeframe of client-side attacks from minutes/hours to potentially an extended period
- Defeat common incident response procedures that rely on password changes to secure compromised accounts

Stored tokens persist across browser sessions until explicit logout or natural expiration.

### 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.

### Severity

This vulnerability has been assigned a severity of **LOW** because:

- No direct exploitability - requires chaining with other vulnerabilities
- High attack complexity - multiple successful exploits needed
- Limited standalone impact - only extends existing compromises
- Aligns with industry standard classifications of LOW severity for session invalidation failures

This is fundamentally a defense-in-depth issue rather than a primary security vulnerability.
GitHub Security Advisory: GHSA-6859-2qxq-ffv2
Package: pgadmin4 (PIP)
Severity: HIGH (CVSS 7.9)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: < 9.8
Patched in: 9.8

Summary: pgadmin4 is affected by a Cross-Origin Opener Policy (COOP) vulnerability

Details:
pgAdmin <= 9.7 is affected by a Cross-Origin Opener Policy (COOP) vulnerability. This vulnerability allows an attacker to manipulate the OAuth flow, potentially leading to unauthorised account access, account takeover, data breaches, and privilege escalation.
GitHub Security Advisory: GHSA-9q5r-wfvf-rr7f
Package: xgrammar (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 0.1.23
Patched in: 0.1.24

Summary: xgrammar vulnerable to denial of service by huge enum grammar

Details:
### Summary
Provided grammar, would fit in a context window of most of the models, but takes minutes to process in 0.1.23. In testing with 0.1.16 the parser worked fine so this seems to be a regression caused by Earley parser.

### Details

Full reproducer provider in the POC section. The resulting grammar is around 70k tokens, and the grammar parsing itself (with the models I checked) was significantly longer than LLM processing itself, meaning this can be used to DOS model providers.

### Patch

This problem is caused by the grammar optimizer introduced in v0.1.23 being too slow. It only happens for very large grammars (>100k characters), like the below one. v0.1.24 solved this problem by optimizing the speed of the grammar optimizer and disable some slow optimization for large grammars. 

Thanks to @Seven-Streams 

### PoC
```
import string
import random

def enum_schema(size=10000,str_len=10):
    enum =  {"enum": ["".join(random.choices(string.ascii_uppercase, k=str_len)) for _ in range(size)]}
    schema = {
        "definitions": {
            "colorEnum": enum
        },
        "type": "object",
        "properties": {
            "color1": {
                "$ref": "#/definitions/colorEnum"
            },
            "color2": {
                "$ref": "#/definitions/colorEnum"
            },
            "color3": {
                "$ref": "#/definitions/colorEnum"
            },
            "color4": {
                "$ref": "#/definitions/colorEnum"
            },
            "color5": {
                "$ref": "#/definitions/colorEnum"
            },
            "color6": {
                "$ref": "#/definitions/colorEnum"
            },
            "color7": {
                "$ref": "#/definitions/colorEnum"
            },
            "color8": {
                "$ref": "#/definitions/colorEnum"
            }
        },
        "required": [
                "color1",
                "color2"
         ]
    }
    return schema

schema_enum = enum_schema()
print(schema_enum)
print(test_schema(schema_enum, {}))
```

where:
```
def test_schema(schema, instance):
    grammar = xgr.Grammar.from_json_schema(
        json.dumps(schema),
        strict_mode=True
    )
    return _is_grammar_accept_string(grammar, json.dumps(instance))
```

### Impact
DOS
GitHub Security Advisory: GHSA-ph2w-cx28-vhrq
Package: TkEasyGUI (PIP)
Severity: HIGH (CVSS 7.8)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: < 1.0.22
Patched in: 1.0.22

Summary: TkEasyGUI Affected by Uncontrolled Search Path Element Issue

Details:
Uncontrolled search path element issue exists in TkEasyGUI versions prior to v1.0.22. If this vulnerability is exploited, arbitrary code may be executed with the privilege of running the program.
GitHub Security Advisory: GHSA-hfrj-3w3g-jv32
Package: TkEasyGUI (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 1.0.22
Patched in: 1.0.22

Summary: TkEasyGUI Vulnerable to OS Command Injection

Details:
Improper neutralization of special elements used in an OS command ('OS Command Injection') issue exists in TkEasyGUI versions prior to v1.0.22. If this vulnerability is exploited, an arbitrary OS command may be executed by a remote unauthenticated attacker if the settings are configured to construct messages from external sources.
GitHub Security Advisory: GHSA-wx3r-v6h7-frjp
Package: internetarchive (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 5.5.0
Patched in: 5.5.1

Summary: internetarchive Vulnerable to Directory Traversal in File.download()

Details:
### Impact
**What kind of vulnerability is it?**
This is a **Critical** severity directory traversal (path traversal) vulnerability in the `File.download()` method of the `internetarchive` library.

**Who is impacted?**
All users of the `internetarchive` library versions `< 5.5.1` are impacted. The vulnerability is particularly critical for users on **Windows systems**, but all operating systems are affected.

**Description of the vulnerability:**
The vulnerability existed because the `file.download()` method did not properly sanitize user-supplied filenames or validate the final download path. A maliciously crafted filename could contain path traversal sequences (e.g., `../../../../windows/system32/file.txt`) or illegal characters that, when processed, would cause the file to be written outside of the intended target directory.

**Potential Impact:**
An attacker could potentially overwrite critical system files or application configuration files, leading to a denial of service, privilege escalation, or remote code execution, depending on the context in which the library is used.

### Patches
**Has the problem been patched?**
Yes, the problem has been patched.

**What versions should users upgrade to?**
Users must upgrade to version **5.5.1** or later.

### Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
There is no direct workaround that does not involve upgrading the library. The vulnerability is in the core logic of the file download process.

The only alternative for users who absolutely cannot upgrade is to implement their own custom download function that:

1. Manually sanitizes all filenames using a robust method.
2. Validates that the resolved absolute path of the download target is within the intended directory before writing any files.

However, this essentially re-implements the fix and is not recommended. Upgrading to the patched version is the only safe and supported solution.

### References

- [Release Notes for v5.5.1](https://github.com/jjjake/internetarchive/releases/tag/v5.5.1)
- [Commit with the fix](https://github.com/jjjake/internetarchive/commit/cba2d459e10a9489fb35caeba0b03e80f5f5d7c2)
- **CVE Identifier:**  CVE-2025-58438
GitHub Security Advisory: GHSA-pc6w-59fv-rh23
Package: langchain-community (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: < 0.3.27
Patched in: 0.3.27

Summary: Langchain Community Vulnerable to XML External Entity (XXE) Attacks

Details:
The langchain-ai/langchain project, specifically the EverNoteLoader component, is vulnerable to XML External Entity (XXE) attacks due to insecure XML parsing. The vulnerability arises from the use of etree.iterparse() without disabling external entity references, which can lead to sensitive information disclosure. An attacker could exploit this by crafting a malicious XML payload that references local files, potentially exposing sensitive data such as /etc/passwd. This issue has been fixed in 0.3.27 of langchain-community.
GitHub Security Advisory: GHSA-377j-wj38-4728
Package: Weblate (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 5.13.1
Patched in: 5.13.1

Summary: Weblate has a long session expiry when verifying second factor

Details:
### Impact
The verification of the second factor had too long a session expiry. The long session expiry could be used to circumvent rate limiting of the second factor.


### Patches
This issue has been addressed in Weblate 5.13.1 via https://github.com/WeblateOrg/weblate/pull/16002.

### References
Thanks to Nahid Hasan Limon for reporting this issue responsibly.
GitHub Security Advisory: GHSA-ccc3-fvfx-mw3v
Package: mobsf (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 4.4.0
Patched in: 4.4.1

Summary: MobSF Path Traversal in GET /download/<filename> using absolute filenames

Details:
### Summary
The GET /download/<filename> route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

### Details
```
def is_safe_path(safe_root, check_path):
    safe_root  = os.path.realpath(os.path.normpath(safe_root))
    check_path = os.path.realpath(os.path.normpath(check_path))
    return os.path.commonprefix([check_path, safe_root]) == safe_root
```
commonprefix compares raw strings, not path components. For:
```
safe_root  = /home/mobsf/.MobSF/downloads
check_path = /home/mobsf/.MobSF/downloads_bak/test.txt
```
the function returns True, incorrectly treating downloads_bak as inside downloads.
Download handler:
```
# MobSF/views/home.py
@login_required
def download(request):
    root = settings.DWD_DIR
    filename = request.path.replace('/download/', '', 1)
    dwd_file = Path(root) / filename  # absolute 'filename' ignores 'root'
    if '../' in filename or not is_safe_path(root, dwd_file):
        return HttpResponseForbidden(...)
    ext = dwd_file.suffix
    if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file():
        return file_download(dwd_file, ...)
```
If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path then accepts any sibling directory whose absolute path shares the same string prefix. The ../ check does not catch this.

Which file types are retrievable: Whatever is allowed by settings.ALLOWED_EXTENSIONS

### PoC
Prereqs: authenticated user; standard install.
Assume:
```
settings.DWD_DIR = /home/mobsf/.MobSF/downloads
```
Prepare a sibling directory with the same string prefix and a test file:
```
mkdir -p /home/mobsf/.MobSF/downloads_bak
echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt
```
As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it):
```
GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1
Host: <HOST>
Cookie: sessionid=<YOUR_SESSION>
```
Other working sibling directory names (if present):
```
…/downloads.old/...
…/downloads_backup/...
…/downloads1/...
…/downloads-archive/...
…/downloads 2024/... (URL-encoded space: downloads%202024)
```
### Impact
Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.
GitHub Security Advisory: GHSA-mxh2-ccgj-8635
Package: esphome (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-187: Partial String Comparison, CWE-303: Incorrect Implementation of Authentication Algorithm
Vulnerable versions: <= 2025.8.0
Patched in: 2025.8.1

Summary: ESP-IDF web_server basic auth bypass using empty or incomplete Authorization header

Details:
### Summary
On the ESP-IDF platform, ESPHome's [`web_server` authentication](https://esphome.io/components/web_server.html#configuration-variables) check can pass incorrectly when the client-supplied base64-encoded `Authorization` value is empty or is a substring of the correct value (e.g., correct username with partial password). This allows access to `web_server` functionality (including OTA, if enabled) without knowing any information about the correct username or password.

### Details
The HTTP basic auth check in `web_server_idf`'s [`AsyncWebServerRequest::authenticate`](https://github.com/esphome/esphome/blob/ef2121a215890d46dc1d25ad363611ecadc9e25e/esphome/components/web_server_idf/web_server_idf.cpp#L256) only compares up to `auth.value().size() - auth_prefix_len` bytes of the base64-encoded `user:pass` string. This means a client-provided valuer like `dXNlcjpz` (`user:s`) will pass the check when the correct value is much longer, e.g., `dXNlcjpzb21lcmVhbGx5bG9uZ3Bhc3M=` (`user:somereallylongpass`).

Furthermore, the check will also pass when the supplied value is the empty string, which removes the need to know (or brute force) the username. A browser won't generally issue such a request, but it can easily be done by manually constructing the `Authorizaztion` request header (e.g., via `curl`).

### PoC
Configure ESPHome as follows:

```yaml
esp32:
  board: ...
  framework:
    type: esp-idf
web_server:
  auth:
    username: user
    [CREDENTIAL_REDACTED]
```

In a browser, you can correctly log in by supplying username `user` and password `somereallylongpass`... but you can _also_ incorrectly log in by supplying _substrings_ of the password whose base64-encoded digest matches a _prefix_ of the correct digest. (For example, I was able to log into an ESPHome device so configured by supplying password `some`... or even just `s`.)

You can also use a tool like `curl` to manually set an `Authorization` request header that _always_ passes the check without any knowledge of the username:

```
$ curl -D- http://example.local/
HTTP/1.1 401 Unauthorized
...

$ curl -D- -H 'Authorization: Basic ' http://example.local/
HTTP/1.1 200 OK
...
```

### Impact
This vulnerability effectively nullifies basic auth support for the ESP-IDF `web_server`, allowing auth bypass from another device on the local network with no knowledge of the correct username or password required.

### Remediation
This vulnerability is fixed in 2025.8.1 and later.

For older versions, disabling the `web_server` component on ESP-IDF devices may be prudent, particularly if OTA updates through `web_server` are enabled.
GitHub Security Advisory: GHSA-4h8c-qrcq-cv5c
Package: local-deep-research (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: > 0.2.0, < 1.0.0
Patched in: 1.0.0

Summary: Local Deep Research's API keys are stored in plain text

Details:
**Affected Versions:** > 0.2.0 and < 1.0.0 
**Patched Versions:** >= 1.0.0

**Description:**
The library stored confidential information, including API keys, in a local SQLite database without encryption. This behavior was not clearly documented outside of the database architecture page. Users were not given the ability to configure the database location. As a result, anyone with access to the container or host filesystem could retrieve sensitive data in plaintext by accessing the `.db` file.

**Impact:**
Unauthorized access to API keys and other confidential data if the SQLite database file was exposed.

**Fixed in Version 1.0.0:**
- Database is fully encrypted
- Database location is configurable  
- API keys can be set via environment variables (this capability existed in earlier versions)
GitHub Security Advisory: GHSA-5vcc-86wm-547q
Package: djangorestframework-simplejwt (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 5.5.1
Patched in: 5.5.1

Summary: Improper Privilege Management in djangorestframework-simplejwt

Details:
djangorestframework-simplejwt before version 5.5.1 is vulnerable to information disclosure. A user can access web application resources even after their account has been disabled due to missing user validation checks via the for_user method.
GitHub Security Advisory: GHSA-887c-mr87-cxwp
Package: torch (PIP)
Severity: MODERATE (CVSS 3.3)
CWE: CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: <= 2.7.1
Patched in: 2.8.0

Summary: PyTorch Improper Resource Shutdown or Release vulnerability

Details:
A vulnerability, which was classified as problematic, was found in PyTorch 2.6.0. Affected is the function torch.nn.functional.ctc_loss of the file aten/src/ATen/native/LossCTC.cpp. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The name of the patch is 46fc5d8e[PII_REDACTED]11cb237d5f9eef0223e567. It is recommended to apply a patch to fix this issue.
GitHub Security Advisory: GHSA-hw6f-rjfj-j7j7
Package: eventlet (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 0.40.3
Patched in: 0.40.3

Summary: Eventlet affected by HTTP request smuggling in unparsed trailers

Details:
### Impact
The Eventlet WSGI parser is vulnerable to HTTP Request Smuggling due to improper handling of HTTP trailer sections.

This vulnerability could enable attackers to:
- Bypass front-end security controls
- Launch targeted attacks against active site users
- Poison web caches

### Patches
Problem has been patched in eventlet 0.40.3.

The patch just drops trailers. If a backend behind eventlet.wsgi proxy requires trailers, then this patch BREAKS your setup.

### Workarounds
Do not use eventlet.wsgi facing untrusted clients.

### References
- Patch https://github.com/eventlet/eventlet/pull/1062
- This issue is similar to https://github.com/advisories/GHSA-9548-qrrj-x5pj
GitHub Security Advisory: GHSA-53q9-r3pm-6pq6
Package: torch (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 2.6.0
Patched in: 2.6.0

Summary: PyTorch: `torch.load` with `weights_only=True` leads to remote code execution

Details:
# Description
I found a Remote Command Execution (RCE) vulnerability in PyTorch. When loading model using torch.load with weights_only=True, it can still achieve RCE.  

# Background knowledge
https://github.com/pytorch/pytorch/security 
 As you can see, the PyTorch official documentation considers using `torch.load()` with `weights_only=True` to be safe.
![image](https://github.com/user-attachments/assets/fdaa8520-d66a-473a-ab1f-163d793de298)
Since everyone knows that weights_only=False is unsafe, so they will use the  weights_only=True to mitigate the seucirty issue.
But now, I just proved that even if you use weights_only=True, it can still achieve RCE.

# Credit
This vulnerability was found by Ji'an Zhou.
GitHub Security Advisory: GHSA-m54q-mm9w-fp6g
Package: Exiv2 (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: <= 0.17.3
Patched in: unpatched

Summary: Exiv2 has quadratic performance in ICC profile parsing in JpegBase::readMetadata

Details:
### Impact
A denial-of-service was found in Exiv2 version v0.28.5: a quadratic algorithm in the ICC profile parsing code in `jpegBase::readMetadata()` can cause Exiv2 to run for a long time. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted jpg image file.

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

### References
Issue: https://github.com/Exiv2/exiv2/issues/3333
Fixes: https://github.com/Exiv2/exiv2/pull/3335 (main branch), https://github.com/Exiv2/exiv2/pull/3345 (0.28.x branch)

### For more information
Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.