deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9g7v-8wxv-mwxp
Package: Keras (PIP)
Severity: HIGH (CVSS 8.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.12.0
Patched in: 3.12.0

Summary: Duplicate Advisory: Keras keras.utils.get_file API is vulnerable to a path traversal attack

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-hjqc-jx6g-rwp9. This link is maintained to preserve external references.

### Original Description
Keras version 3.11.3 is affected by a path traversal vulnerability in the keras.utils.get_file() function when extracting tar archives. The vulnerability arises because the function uses Python's tarfile.extractall() method without the security-critical filter='data' parameter. Although Keras attempts to filter unsafe paths using filter_safe_paths(), this filtering occurs before extraction, and a PATH_MAX symlink resolution bug triggers during extraction. This bug causes symlink resolution to fail due to path length limits, resulting in a security bypass that allows files to be written outside the intended extraction directory. This can lead to arbitrary file writes outside the cache directory, enabling potential system compromise or malicious code execution. The vulnerability affects Keras installations that process tar archives with get_file() and does not affect versions where this extraction method is secured with the appropriate filter parameter.
GitHub Security Advisory: GHSA-24hm-wm2h-h8w7
Package: peppol_py (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: Peppol-py is vulnerable to XXE attacks due to Saxon configuration

Details:
Peppol-py before 1.1.1 allows XXE attacks because of the Saxon configuration. When validating XML-based invoices, the XML parser could read files from the filesystem and expose their content to a remote host.
GitHub Security Advisory: GHSA-gq25-78jf-v78c
Package: tutor (PIP)
Severity: LOW (CVSS 3.3)
CWE: CWE-384: Session Fixation
Vulnerable versions: <= 20.0.2
Patched in: unpatched

Summary: Overhang Tutor Discloses Sensitive Information due to Improper Cache-Control

Details:
An issue was discovered in Overhang.IO (tutor-open-edx) (overhangio/tutor) 20.0.2 allowing local unauthorized attackers to gain access to sensitive information due to the absence of proper cache-control HTTP headers and client-side session checks.
GitHub Security Advisory: GHSA-gx77-xgc2-4888
Package: ray (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-304: Missing Critical Step in Authentication, CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: <= 2.52.0
Patched in: unpatched

Summary: Ray's New Token Authentication is Disabled By Default

Details:
Anyscale Ray 2.52.0 contains an insecure default configuration in which token-based authentication for Ray management interfaces (including the dashboard and Jobs API) is disabled unless explicitly enabled by setting RAY_AUTH_MODE=token. In the default unauthenticated state, a remote attacker with network access to these interfaces can submit jobs and execute arbitrary code on the Ray cluster. NOTE: The vendor plans to enable token authentication by default in a future release. They recommend enabling token authentication to protect your cluster from unauthorized access.
GitHub Security Advisory: GHSA-75hx-6r6j-hw56
Package: python-mistralclient (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: < 4.3.0
Patched in: 4.3.0

Summary: OpenStack's Mistral Client has a local file inclusion vulnerability

Details:
The mistral-dashboard plugin for openstack has a local file inclusion vulnerability through the 'Create Workbook' feature that may result in disclosure of arbitrary local files content.
GitHub Security Advisory: GHSA-2j58-pwwv-x666
Package: sqlite-web (PIP)
Severity: HIGH (CVSS 7.4)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 0.6.5
Patched in: unpatched

Summary: Cross-Site Request Forgery in sqlite-web

Details:
This affects all versions of package sqlite-web. The SQL dashboard area allows sensitive actions to be performed without validating that the request originated from the application. This could enable an attacker to trick a user into performing these actions unknowingly through a Cross Site Request Forgery (CSRF) attack.
GitHub Security Advisory: GHSA-xh5w-g8gq-r3v9
Package: keylime (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-694: Use of Multiple Resources with Duplicate Identifier
Vulnerable versions: < 7.13.0
Patched in: 7.13.0

Summary: Keylime allows users to register new agents by recycling existing UUIDs when using different TPM devices

Details:
A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent's unique identifier (UUID). This action overwrites the legitimate agent's identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.
GitHub Security Advisory: GHSA-j4gv-6x9v-v23g
Package: omero-web (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 5.29.3
Patched in: 5.29.3

Summary: OMERO.web uses jquery-form library, which may be vulnerable to XSS attack

Details:
### Impact
OMERO.web uses the jquery-form library throughout to handle form submission and response processing. Due to some unpatched potential vulnerabilities in jquery-form, OMERO.web 5.29.2 and earlier may be susceptible to XSS attacks.

### Patches
User should upgrade OMERO.web to 5.29.3 or higher.

### Workarounds
None.

### Resources
https://github.com/jquery-form/form/issues/604
GitHub Security Advisory: GHSA-m449-cwjh-6pw7
Package: pypdf (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Vulnerable versions: < 6.4.0
Patched in: 6.4.0

Summary: pypdf's LZWDecode streams be manipulated to exhaust RAM

Details:
### Impact

An attacker who uses this vulnerability can craft a PDF which leads to a memory usage of up to 1 GB per stream. This requires parsing the content stream of a page using the LZWDecode filter.

This is a follow up to [GHSA-jfx9-29x2-rv3j](https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j) to align the default limit with the one for *zlib*.

### Patches
This has been fixed in [pypdf==6.4.0](https://github.com/py-pdf/pypdf/releases/tag/6.4.0).

### Workarounds
If users cannot upgrade yet, use the line below to overwrite the default in their code:

```python
pypdf.filters.LZW_MAX_OUTPUT_LENGTH = 75_000_000
```
GitHub Security Advisory: GHSA-69j4-grxj-j64p
Package: vllm (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.5.5, < 0.11.1
Patched in: 0.11.1

Summary: vLLM vulnerable to DoS via large Chat Completion or Tokenization requests with specially crafted `chat_template_kwargs`

Details:
### Summary
The /v1/chat/completions and /tokenize endpoints allow a `chat_template_kwargs` request parameter that is used in the code before it is properly validated against the chat template. With the right `chat_template_kwargs` parameters, it is possible to block processing of the API server for long periods of time, delaying all other requests 

### Details
In serving_engine.py, the chat_template_kwargs are unpacked into kwargs passed to chat_utils.py `apply_hf_chat_template` with no validation on the keys or values in that chat_template_kwargs dict. This means they can be used to override optional parameters in the `apply_hf_chat_template` method, such as `tokenize`, changing its default from False to True.

https://github.com/vllm-project/vllm/blob/2a6dc67eb520ddb9c4138d8b35ed6fe6226997fb/vllm/entrypoints/openai/serving_engine.py#L809-L814

https://github.com/vllm-project/vllm/blob/2a6dc67eb520ddb9c4138d8b35ed6fe6226997fb/vllm/entrypoints/chat_utils.py#L1602-L1610

Both serving_chat.py and serving_tokenization.py call into this `_preprocess_chat` method of `serving_engine.py` and they both pass in `chat_template_kwargs`.

So, a `chat_template_kwargs` like `{"tokenize": True}` makes tokenization happen as part of applying the chat template, even though that is not expected. Tokenization is a blocking operation, and with sufficiently large input can block the API server's event loop, which blocks handling of all other requests until this tokenization is complete.

This optional `tokenize` parameter to `apply_hf_chat_template` does not appear to be used, so one option would be to just hard-code that to always be False instead of allowing it to be optionally overridden by callers. A better option may be to not pass `chat_template_kwargs` as unpacked kwargs but instead as a dict, and only unpack them after the logic in `apply_hf_chat_template` that resolves the kwargs against the chat template.

### Impact

Any authenticated user can cause a denial of service to a vLLM server with Chat Completion or Tokenize requests.

### Fix

https://github.com/vllm-project/vllm/pull/27205
GitHub Security Advisory: GHSA-pmqf-x6x8-p7qw
Package: vllm (PIP)
Severity: HIGH (CVSS 6.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: >= 0.5.5, < 0.11.1
Patched in: 0.11.1

Summary: vLLM vulnerable to DoS with incorrect shape of multimodal embedding inputs

Details:
### Summary

Users can crash the vLLM engine serving multimodal models by passing multimodal embedding inputs with correct `ndim` but incorrect `shape` (e.g. hidden dimension is wrong), regardless of whether the model is intended to support such inputs (as defined in the Supported Models page).

The issue has existed ever since we added support for image embedding inputs, i.e. #6613 (released in v0.5.5)

### Details

Using image embeddings as an example:

- For models that support image embedding inputs, the engine crashes when scattering the embeddings to `inputs_embeds` (mismatched shape)
- For models that don't support image embedding inputs, the engine crashes when validating the inputs inside `get_input_embeddings` (validation fails).

This happens because we only validate `ndim` of the tensor, but not the full shape, in input processor (via `MultiModalDataParser`).

### Impact

- Denial of service by crashing the engine

### Mitigation

- Use API key to limit access to trusted users.
- Set `--limit-mm-per-prompt` to 0 for all non-text modalities to ban multimodal inputs, which includes multimodal embedding inputs. However, the model would then only accept text, defeating the purpose of using a multi-modal model.

### Resolution

- https://github.com/vllm-project/vllm/pull/27204
GitHub Security Advisory: GHSA-mrw7-hf4f-83pf
Package: vllm (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-123: Write-what-where Condition, CWE-502: Deserialization of Untrusted Data, CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.10.2, < 0.11.1
Patched in: 0.11.1

Summary: vLLM deserialization vulnerability leading to DoS and potential RCE

Details:
### Summary
A memory corruption vulnerability that leading to a crash (denial-of-service) and potentially remote code execution (RCE) exists in vLLM versions 0.10.2 and later, in the Completions API endpoint. When processing user-supplied prompt embeddings, the endpoint loads serialized tensors using torch.load() without sufficient validation.

Due to a change introduced in PyTorch 2.8.0, sparse tensor integrity checks are disabled by default. As a result, maliciously crafted tensors can bypass internal bounds checks and trigger an out-of-bounds memory write during the call to to_dense(). This memory corruption can crash vLLM and potentially lead to code execution on the server hosting vLLM.

### Details
A vulnerability that can lead to RCE from the completions API endpoint exists in vllm, where due to missing checks when loading user-provided tensors, an out-of-bounds write can be triggered. This happens because the default behavior of `torch.load(tensor, weights_only=True)`  since pytorch 2.8.0 is to not perform validity checks for sparse tensors, and this needs to be enabled explicitly using the [torch.sparse.check_sparse_tensor_invariants](https://docs.pytorch.org/docs/stable/generated/torch.sparse.check_sparse_tensor_invariants.html) context manager.

The vulnerability is in the following code in [vllm/entrypoints/renderer.py:148](https://github.com/vllm-project/vllm/blob/a332b84578cdc0706e040f6a765954c8a289904f/vllm/entrypoints/renderer.py#L148)

```python
    def _load_and_validate_embed(embed: bytes) -> EngineEmbedsPrompt:
        tensor = torch.load(
            io.BytesIO(pybase64.b64decode(embed, validate=True)),
            weights_only=True,
            map_location=torch.device("cpu"),
        )
        assert isinstance(tensor, torch.Tensor) and tensor.dtype in (
            torch.float32,
            torch.bfloat16,
            torch.float16,
        )
        tensor = tensor.to_dense()
```

Because of the missing checks, loading invalid prompt embedding tensors provided by the user can cause an out-of-bounds write in the call to `to_dense` .

### Impact
All users with access to this API are able to exploit this vulnerability. Unsafe deserialization of untrusted input can be abused to achieve DoS and potentially remote code execution (RCE) in the vLLM server process. This impacts deployments running vLLM as a server or any instance that deserializes untrusted/model-provided payloads.

## Fix

https://github.com/vllm-project/vllm/pull/27204

## Acknowledgements

Finder: AXION Security Research Team (Omri Fainaro, Bary Levy): discovery and coordinated disclosure.
GitHub Security Advisory: GHSA-xjv7-6w92-42r7
Package: marimo (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
Vulnerable versions: >= 0.9.20, < 0.16.4
Patched in: 0.16.4

Summary: marimo vulnerable to proxy abuse of /mpl/{port}/

Details:
### Summary
The  `/mpl/<port>/<route>` endpoint, which is accessible without authentication on default Marimo installations allows for external attackers to reach internal services and arbitrary ports. 

### Details
From our understanding, this route is used internally to provide access to interactive matplotlib visualizations.
[marimo/marimo/_server/main.py at main · marimo-team/marimo](https://github.com/marimo-team/marimo/blob/main/marimo/_server/main.py) 
This endpoint functions as an unauthenticated proxy, allowing an attacker to connect to any service running on the local machine via the specified `<port>` and `<route>`.

The existence of this proxy is visible in the application's code (marimo/_server/main.py), but there's no official documentation or warning about its behavior or potential risks.


### Impact
CWE-441: Proxying Without Authentication

This vulnerability, as it can be used to bypass firewalls and access internal services that are intended to be local-only. The level of impact depends entirely on what services are running and accessible on the local machine.

Full Local Access: An attacker can use this proxy to connect to local services that answer to web sockets, HTTP or ASGI protocol, effectively gaining a foothold on the machine. Depending on the service, this can lead to remote code execution, data exfiltration, or further network penetration.

Exposure of Sensitive Services: Our scans of public-facing Marimo servers have shown that many are exposing sensitive internal services, including:

Old CUPS Servers: Could allow an attacker to view print jobs or configuration or depending on old vulnerabilities, allow RCE.

phpMyAdmin: Provides a web interface to a MySQL database, potentially exposing sensitive data.

RPCMapper: Can be used for network reconnaissance and enumerating services.

While you’d hope people wouldn’t expose marimo instances to the internet, we found numerous public Marimo instances using tools like Shodan. Many of these servers, some even hosted on cloud platforms like AWS GovCloud, were found to be vulnerable. This means the vulnerability isn't limited to a few isolated cases but is a widespread issue affecting production environments.

===

Notes, this was discovered by [devgi](https://github.com/devgi). I ([acepace](https://github.com/acepace)) followed up and also created this report.
GitHub Security Advisory: GHSA-7xcv-9j6c-2fmc
Package: modular (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 25.6.0
Patched in: 25.6.0

Summary: Modular Max Serve has Unsafe Deserialization vulnerability

Details:
Unsafe Deserialization vulnerability in Modular Max Serve before 25.6, specifically when the "--experimental-enable-kvcache-agent" feature is used allowing attackers to execute arbitrary code.
GitHub Security Advisory: GHSA-hcqg-5g63-7j9h
Package: keystone (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: = 28.0.0.0rc1
Patched in: 28.0.0

Summary: OpenStack Keystone allows /v3/ec2tokens or /v3/s3tokens request with valid AWS Signature to provide Keystone authorization.

Details:
OpenStack Keystone before 26.0.1, 27.0.0, and 28.0.0 allows a /v3/ec2tokens or /v3/s3tokens request with a valid AWS Signature to provide Keystone authorization.
GitHub Security Advisory: GHSA-hcqg-5g63-7j9h
Package: keystone (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: = 27.0.0.0rc1
Patched in: 27.0.0

Summary: OpenStack Keystone allows /v3/ec2tokens or /v3/s3tokens request with valid AWS Signature to provide Keystone authorization.

Details:
OpenStack Keystone before 26.0.1, 27.0.0, and 28.0.0 allows a /v3/ec2tokens or /v3/s3tokens request with a valid AWS Signature to provide Keystone authorization.
GitHub Security Advisory: GHSA-hcqg-5g63-7j9h
Package: keystone (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 26.0.1
Patched in: 26.0.1

Summary: OpenStack Keystone allows /v3/ec2tokens or /v3/s3tokens request with valid AWS Signature to provide Keystone authorization.

Details:
OpenStack Keystone before 26.0.1, 27.0.0, and 28.0.0 allows a /v3/ec2tokens or /v3/s3tokens request with a valid AWS Signature to provide Keystone authorization.
GitHub Security Advisory: GHSA-2qfp-q593-8484
Package: Scrapy (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 2.13.3
Patched in: 2.13.4

Summary: Scrapy is vulnerable to a denial of service (DoS) attack due to flaws in brotli decompression implementation

Details:
Scrapy versions up to 2.13.3 are vulnerable to a denial of service (DoS) attack due to a flaw in its brotli decompression implementation. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression. Mitigation for this vulnerability needs security enhancement added in brotli v1.2.0.
GitHub Security Advisory: GHSA-f3f8-vx3w-hp5q
Package: codechecker (PIP)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: < 6.24.2
Patched in: 6.24.2

Summary: codechecker vulnerable to authentication bypass when using specifically crafted URLs

Details:
### Summary
Authentication bypass occurs when the API URL ends with Authentication, Configuration or ServerInfo. This bypass allows superuser access to all API endpoints other than Authentication. These endpoints include the ability to add, edit, and remove products, among others.

### Details
All endpoints, apart from the /Authentication is affected by the vulnerability.

The vulnerability allows unauthenticated users to access all API functionality.
You can look for the following pattern in the logs to check if the vulnerabilty was exploited:
![image](https://github.com/user-attachments/assets/6ba02231-a3d8-4832-aee6-f96462b7441e)

Note that the url starts with v and contains a valid CodeChecker endpoint, but it ends in `Authentication`, `Configuration` or `ServerInfo` and it was made by an `Anonymous` user.

### Impact
This authentication bypass allows querying, adding, changing, and deleting Products contained on the CodeChecker server, without authentication, by an anonymous user.
GitHub Security Advisory: GHSA-4m32-cjv7-f425
Package: astrbot (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-798: Use of Hard-coded Credentials
Vulnerable versions: < 3.5.18
Patched in: 3.5.18

Summary: AstrBot is vulnerable to RCE with hard-coded JWT signing keys

Details:
### Summary
AstrBot uses a hard-coded JWT signing key, allowing attackers to execute arbitrary commands by installing a malicious plugin.

### Details

AstrBot uses a [hard-coded JWT signing key](https://github.com/AstrBotDevs/AstrBot/blob/v3.5.16/astrbot/core/__init__.py), which allows attackers to bypass the authentication mechanism. Once bypassed, the attacker can install a Python plugin that will be imported [here](https://github.com/AstrBotDevs/AstrBot/blob/master/astrbot/dashboard/routes/plugin.py), enabling arbitrary command execution on the target host.

### Impact

All publicly accessible AstrBot instances are vulnerable.

For more information, please see: [CVE-2025-55449-AstrBot-RCE](https://github.com/Marven11/CVE-2025-55449-AstrBot-RCE)

### Patch

This vulnerability was first reported on **2025-06-21** and was patched on the **same day** (2025-06-21).

The vulnerability was publicly disclosed on **2025-11-14**. Prior to public disclosure, monitoring from AstrBot Cloud indicated that fewer than 2% of deployed instances were still running the affected version. Therefore, this disclosure is not expected to have a significant impact on existing active instances.
GitHub Security Advisory: GHSA-g4r8-3qmh-pmch
Package: pgadmin4 (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 9.9
Patched in: 9.10

Summary: pgAdmin has vulnerability in LDAP authentication mechanism that allows bypassing TLS certificate verification

Details:
pgAdmin <= 9.9 is affected by a vulnerability in the LDAP authentication mechanism allows bypassing TLS certificate verification.
GitHub Security Advisory: GHSA-cvf4-f829-762v
Package: pgadmin4 (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: <= 9.9
Patched in: 9.10

Summary: pgAdmin is affected by an LDAP injection vulnerability

Details:
pgAdmin <= 9.9 is affected by an LDAP injection vulnerability in the LDAP authentication flow that allows an attacker to inject special LDAP characters in the username, causing the DC/LDAP server and the client to process an unusual amount of data DOS.
GitHub Security Advisory: GHSA-rm79-x4g6-hvg5
Package: pgadmin4 (PIP)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 9.9
Patched in: 9.10

Summary: pgAdmin 4 has command injection vulnerability on Windows systems

Details:
pgAdmin 4 versions up to 9.9 are affected by a command injection vulnerability on Windows systems. This issue is caused by the use of shell=True during backup and restore operations, enabling attackers to execute arbitrary system commands by providing specially crafted file path input.