deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2p94-8669-xg86
Package: vyper (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: <= 0.4.0
Patched in: 0.4.1

Summary: Vyper's sqrt doesn't define rounding behavior

Details:
Vyper's `sqrt()` builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results.

the fix is tracked in https://github.com/vyperlang/vyper/pull/4486

### Vulnerability Details

Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user.
```python
assert x >= 0.0
z: decimal = 0.0

if x == 0.0:
    z = 0.0
else:
    z = x / 2.0 + 0.5
    y: decimal = x

    for i: uint256 in range(256):
        if z == y:
            break
        y = z
        z = (x / z + z) / 2.0
```
Notably, the terminal condition of the algorithm is either `z_cur == z_prev`, or the algorithm runs for 256 rounds.

However, for certain inputs, `z` might actually oscillate between `N` and `N + epsilon`, where `N ** 2 <= x < (N + epsilon) ** 2`. This means that the current behavior does not define whether it will round up or down to the nearest epsilon.

The example snippet here returns 0[PII_REDACTED], the rounded up result for sqrt(0[PII_REDACTED]). This is due to the oscillation ending in N + epsilon instead of N.
```vyper
@external
def test():
    d: decimal = 0[PII_REDACTED]
    r: decimal = sqrt(d)    #this will be 0[PII_REDACTED]
```

Note that `sqrt()` diverges from `isqrt()` here -- `isqrt()` consistently rounds down, so it is not subject to the same issue.

### Impact Details

Since `sqrt()` can be used for determining boundary conditions, rounding down is preferred. However, since `sqrt()` is used very rarely in the wild, this advisory has been assigned an impact of `low`.
GitHub Security Advisory: GHSA-6c5p-j8vq-pqhj
Package: python-jose (PIP)
Severity: CRITICAL (CVSS 7.4)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 3.4.0
Patched in: 3.4.0

Summary: python-jose algorithm confusion with OpenSSH ECDSA keys

Details:
python-jose through 3.3.0 has algorithm confusion with OpenSSH ECDSA keys and other key formats. This is similar to CVE-2022-29217.
GitHub Security Advisory: GHSA-cjwg-qfpm-7377
Package: python-jose (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 3.4.0
Patched in: 3.4.0

Summary: python-jose denial of service via compressed JWE content

Details:
python-jose through 3.3.0 allows attackers to cause a denial of service (resource consumption) during a decode via a crafted JSON Web Encryption (JWE) token with a high compression ratio, aka a "JWT bomb." This is similar to CVE-2024-21319.
GitHub Security Advisory: GHSA-2586-f3p4-hq84
Package: lightgbm (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: >= 1.0.0, < 4.6.0
Patched in: 4.6.0

Summary: LightGBM Remote Code Execution Vulnerability

Details:
LightGBM Remote Code Execution Vulnerability
GitHub Security Advisory: GHSA-9jxq-5x44-gx23
Package: keylime (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-704: Incorrect Type Conversion or Cast, CWE-1287: Improper Validation of Specified Type of Input
Vulnerable versions: = 7.12.0
Patched in: 7.12.1

Summary: Keylime registrar is vulnerable to Denial-of-Service attack when updated to version 7.12.0

Details:
### Impact
The Keylime `registrar` implemented more strict type checking on version 7.12.0. As a result, when updated to version 7.12.0, the `registrar` will not accept the format of the data previously stored in the database by versions  >= 7.8.0, raising an exception.

This makes the Keylime `registrar` vulnerable to a Denial-of-Service attack in an update scenario, as an attacker could populate the `registrar` database by creating multiple valid agent registrations with different UUIDs while the version is still < 7.12.0. Then, when the Keylime `registrar` is updated to the 7.12.0 version, any query to the database matching any of the entries populated by the attacker will result in failure.

### Patches
Users should upgrade to versions >= 7.12.1

### Workarounds
- Remove the registrar database and re-register all agents

### Credit

Reported by: Anderson Toshiyuki Sasaki/@ansasaki
Patched by: Anderson Toshiyuki Sasaki/@ansasaki
GitHub Security Advisory: GHSA-m238-fmcw-wh58
Package: label-studio (PIP)
Severity: HIGH (CVSS 8.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.16.0
Patched in: 1.16.0

Summary: Label Studio allows Server-Side Request Forgery in the S3 Storage Endpoint

Details:
## Description
Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination.

The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages.

This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services.

## Steps to reproduce
1. Create an account in Label Studio

2. Create a new project with basic configuration

3. Create an S3 storage connection with the following configuration:
   ```json
   {
     "project": 1,
     "title": "Test Storage",
     "bucket": "<filename>",
     "s3_endpoint": "http://internal-web",
     "use_blob_urls": true,
     "aws_access_key_id": "test",
     "aws_secret_access_key": "test"
   }
   ```
4. Trigger a storage sync operation by sending a POST request to `/api/storages/s3/[storage_id]/sync`

The application will attempt to connect to the specified endpoint URL as if it were an S3 service. When the request fails due to invalid S3 API responses, the error message will contain the raw response from the internal service, allowing access to internal resources.
   
## Mitigations
- Implement strict validation of S3 endpoint URLs to allow only valid S3service endpoints
- Add an allowlist of endpoint domains and protocols
- Sanitize error messages to prevent leakage of sensitive information from failed requests
- Consider implementing network-level controls to restrict outbound connections from the application server

## Impact
This vulnerability has high severity as it allows authenticated users to make requests to arbitrary internal services from the application server, potentially exposing sensitive internal resources and bypassing network segmentation. The inclusion of response data in error messages makes this particularly effective for data exfiltration.
GitHub Security Advisory: GHSA-wpq5-3366-mqw4
Package: label-studio (PIP)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.16.0
Patched in: 1.16.0

Summary: Label Studio allows Cross-Site Scripting (XSS) via GET request to `/projects/upload-example` endpoint

Details:
## Description
Label Studio's `/projects/upload-example` endpoint allows injection of arbitrary HTML through a `GET` request with an appropriately crafted `label_config` query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

## Steps to reproduce
1. Create a malicious label config that includes an XSS payload in embedded task data:

```xml
<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>
```


2. URL encode the payload and access the following URL:

- http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(`YWxlcnQoIlhTUyIp`))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.
   
## Mitigations
- Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
- Deprecate the `GET` behavior at the `example-config` endpoint since it's not used 

## Impact
The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.
GitHub Security Advisory: GHSA-6q97-8v3g-rpxw
Package: apache-submarine (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: = 0.8.0
Patched in: unpatched

Summary: Apache Submarine Server Core Incorrect Authorization vulnerability

Details:
Incorrect Authorization vulnerability in Apache Submarine Server Core.

This issue affects Apache Submarine Server Core: from 0.8.0.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
GitHub Security Advisory: GHSA-ph86-g9r3-5qw4
Package: fastecdsa (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-457: Use of Uninitialized Variable, CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 2.3.2
Patched in: 2.3.2

Summary: Uninitialized Variable in fastecdsa

Details:
Versions of the package fastecdsa before 2.3.2 use an Uninitialized Variable on the stack, via the curvemath_mul function in src/curveMath.c, due to being used and interpreted as user-defined type. Depending on the variable's actual value it could be arbitrary free(), arbitrary realloc(), null pointer dereference and other. Since the stack can be controlled by the attacker, the vulnerability could be used to corrupt allocator structure, leading to possible heap exploitation. The attacker could cause denial of service by exploiting this vulnerability.
GitHub Security Advisory: GHSA-xg2h-7cxj-3gvh
Package: ray (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.9.3, <= 2.40.0
Patched in: unpatched

Summary: Withdrawn Advisory: Command injection in Ray

Details:
# Withdrawn Advisory
This advisory is a duplicate of GHSA-6wgj-66m2-xxp2 / CVE-2023-48022.

# Original Description
An issue in Anyscale Inc Ray between v.2.9.3 and v.2.40.0 allows a remote attacker to execute arbitrary code via a crafted script.
GitHub Security Advisory: GHSA-vm8q-m57g-pff3
Package: django (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 5.0, < 5.0.3
Patched in: 5.0.3

Summary: Regular expression denial-of-service in Django

Details:
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
GitHub Security Advisory: GHSA-vm8q-m57g-pff3
Package: django (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 4.2, < 4.2.11
Patched in: 4.2.11

Summary: Regular expression denial-of-service in Django

Details:
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
GitHub Security Advisory: GHSA-vm8q-m57g-pff3
Package: django (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.2, < 3.2.25
Patched in: 3.2.25

Summary: Regular expression denial-of-service in Django

Details:
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
GitHub Security Advisory: GHSA-248v-346w-9cwc
Package: certifi (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 2021.5.30, < 2024.7.4
Patched in: 2024.7.4

Summary: Certifi removes GLOBALTRUST root certificate

Details:
Certifi 2024.07.04 removes root certificates from "GLOBALTRUST" from the root store. These are in the process of being removed from Mozilla's trust store.

GLOBALTRUST's root certificates are being removed pursuant to an investigation which identified "long-running and unresolved compliance issues". Conclusions of Mozilla's investigation can be found [here]( https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI).
GitHub Security Advisory: GHSA-79v4-65xg-pq4g
Package: cryptography (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-392: Missing Report of Error Condition, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: >= 42.0.0, < 44.0.1
Patched in: 44.0.1

Summary: Vulnerable OpenSSL included in cryptography wheels

Details:
pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt.

If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
GitHub Security Advisory: GHSA-vv2h-2w3q-3fx7
Package: pandasai (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 2.4.2
Patched in: unpatched

Summary: PandasAI interactive prompt function Remote Code Execution (RCE)

Details:
PandasAI uses an interactive prompt function that is vulnerable to prompt injection and run arbitrary Python code that can lead to Remote Code Execution (RCE) instead of the intended explanation of the natural language processing by the LLM. The security controls of PandasAI (2.4.3 and earlier) fail to distinguish between legitimate and malicious inputs, allowing the attackers to manipulate the system into executing untrusted code, leading to untrusted code execution (RCE), system compromise, or pivoting attacks on connected services.
GitHub Security Advisory: GHSA-wrfc-pvp9-mr9g
Package: transformers (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 0, < 4.48.0
Patched in: 4.48.0

Summary: Deserialization of Untrusted Data in Hugging Face Transformers

Details:
Hugging Face Transformers MaskFormer Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25191.
GitHub Security Advisory: GHSA-hxxf-235m-72v3
Package: transformers (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 0, < 4.48.0
Patched in: 4.48.0

Summary: Deserialization of Untrusted Data in Hugging Face Transformers

Details:
Hugging Face Transformers Trax Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the handling of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25012.
GitHub Security Advisory: GHSA-qxrp-vhvm-j765
Package: transformers (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 0, < 4.48.0
Patched in: 4.48.0

Summary: Deserialization of Untrusted Data in Hugging Face Transformers

Details:
Hugging Face Transformers MobileViTV2 Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the handling of configuration files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-24322.
GitHub Security Advisory: GHSA-432c-wxpg-m4q3
Package: xml2rfc (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 3.12.0, < 3.27.0
Patched in: 3.27.0

Summary: xml2rfc has file inclusion irregularities

Details:
Version [3.12.0](https://github.com/ietf-tools/xml2rfc/blob/main/CHANGELOG.md#3120---2021-12-08) changed `xml2rfc` so that it would not access local files without the presence of its new `--allow-local-file-access` flag.
This prevented XML External Entity (XXE) injection attacks with `xinclude` and XML entity references.

It was discovered that `xml2rfc` does not respect `--allow-local-file-access` when a local file is specified as `src` in `artwork` or `sourcecode` elements. Furthermore, XML entity references can include any file inside the source dir and below without using the `--allow-local-file-access` flag. 

The `xml2rfc <= 3.26.0` behaviour:

|  | `xinclude` | XML entity reference | `artwork src=` | `sourcecode src=` |
|---|---|---|---|---|
| without `--allow-local-file-access` flag | No filesystem access | Any file in xml2rfc templates dir and below, any file in source directory and below | Access source directory and below | Access source directory and below |
| with `--allow-local-file-access` flag | Access any file on filesystem[^1] | Access any file on filesystem[^1] | Access source directory and below | Access source directory and below | Access source directory and below |

  [^1]: Access any file of the filesystem with the permissions of the user running `xml2rfc` can access.

### Impact

Anyone running `xml2rfc` as a service that accepts input from external users is impacted by this issue.
Specifying a file in `src` attribute in `artwork` or `sourcecode` elements will cause the contents of that file to appear in xml2rfc’s output results.
But that file has to be inside the same directory as the XML input source file.
For `artwork` and `sourcecode`, `xml2rfc` will not look above the source file directory.

### The proposed new behaviour
- Generalize file access checks.
- Only allow access to files within src dir and below. (xml entity include can access templates dir).
- Always allow access to `templates_dir` for XML entity includes.

New behaviour:

|  | `xinclude` | XML entity reference | `artwork src=` | `sourcecode src=` |
|---|---|---|---|---|
| without `--allow-local-file-access` flag | No filesystem access | No filesystem access _(except for `templates_dir`)_ | No filesystem access | No filesystem access |
| with `--allow-local-file-access` flag | Access source directory and below | Access source directory and below _(Can access`templates_dir`)._ | Access source directory and below | Access source directory and below |

### Workarounds

Use a secure temporary directory to process un-trusted XML files, and do not reuse it for processing other XML documents.
GitHub Security Advisory: GHSA-rm76-4mrf-v9r8
Package: vllm (PIP)
Severity: LOW (CVSS 2.6)
CWE: CWE-354: Improper Validation of Integrity Check Value
Vulnerable versions: < 0.7.2
Patched in: 0.7.2

Summary: vLLM uses Python 3.12 built-in hash() which leads to predictable hash collisions in prefix cache

Details:
### Summary

Maliciously constructed prompts can lead to hash collisions, resulting in prefix cache reuse, which can interfere with subsequent responses and cause unintended behavior.

### Details

vLLM's prefix caching makes use of Python's built-in hash() function. As of Python 3.12, the behavior of hash(None) has changed to be a predictable constant value. This makes it more feasible that someone could try exploit hash collisions.

### Impact

The impact of a collision would be using cache that was generated using different content. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use. 

### Solution

We address this problem by initializing hashes in vllm with a value that is no longer constant and predictable. It will be different each time vllm runs. This restores behavior we got in Python versions prior to 3.12.

Using a hashing algorithm that is less prone to collision (like sha256, for example) would be the best way to avoid the possibility of a collision. However, it would have an impact to both performance and memory footprint. Hash collisions may still occur, though they are no longer straight forward to predict.

To give an idea of the likelihood of a collision, for randomly generated hash values (assuming the hash generation built into Python is uniformly distributed), with a cache capacity of 50,000 messages and an average prompt length of 300, a collision will occur on average once every 1 trillion requests.

### References

* https://github.com/vllm-project/vllm/pull/12621
* https://github.com/python/cpython/commit/432117cd1f59c76d97da2eaff55a7d758301dbc7
* https://github.com/python/cpython/pull/99541