deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-85q9-7467-r53q
Package: inventree (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.7.3
Patched in: 0.7.3

Summary: XSS Vulnerability in Markdown Editor

Details:
### Impact

InvenTree uses [EasyMDE](https://github.com/Ionaru/easy-markdown-editor) for displaying markdown text in various places (e.g. for the various "notes" fields associated with various models).

By default, EasyMDE does not sanitize input data, and it is possible for malicious code to be injected into the markdown editor, and executed in the users browser.

*Note: This malicious data must be first uploaded to the database by an authorized user, so the risk here is limited to trusted users*

### Solution

The solution here is two-fold:

- Enable data sanitization for the EasyMDE renderer - [#3205](https://github.com/inventree/InvenTree/pull/3205)
- Enforce cleaning of all data uploaded to the database via the API - [#3204](https://github.com/inventree/InvenTree/pull/3204) *(This will be ready for the 0.8.0 release)*

### Patches

- The issue is addressed in the 0.8.0 release
- This fix was back-ported to the 0.7.x branch, applied to the 0.7.3 release

### Workarounds

There is no workaround for this issue without upgrading InvenTree to the specified version.

### References

- https://huntr.dev/bounties/ab296cf5-7a3e-4f49-8f63-5b35fc707f03/

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [github](http://github.com/inventree/inventree)
* Email us at [security@inventree.org](mailto:security@inventree.org)
GitHub Security Advisory: GHSA-rg7c-g689-fr3x
Package: google-adk (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 1.7.0, < 1.28.1
Patched in: 1.28.1

Summary: Google Agent Development Kit (ADK) has a Code Injection and Missing Authentication vulnerability

Details:
A Code Injection and Missing Authentication vulnerability in Google Agent Development Kit (ADK) versions 1.7.0 (and 2.0.0a1) through 1.28.1 (and 2.0.0a2) on Python (OSS), Cloud Run, and GKE allows an unauthenticated remote attacker to execute arbitrary code on the server hosting the ADK instance.

This vulnerability was patched in versions 1.28.1 and 2.0.0a2.


Customers need to redeploy the upgraded ADK to their production environments. In addition, if they are running ADK Web locally, they also need to upgrade their local instance.
GitHub Security Advisory: GHSA-887w-45rq-vxgf
Package: SQLAlchemy (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.3.0b3
Patched in: 1.3.0b3

Summary: SQLAlchemy vulnerable to SQL Injection via order_by parameter

Details:
SQLAlchemy before 1.3.0b3 allows SQL Injection via the order_by parameter. The fix (commit 30307c4) was applied only to the main branch and was never backported to the 1.2.x release line; all 1.2.x versions remain vulnerable.
GitHub Security Advisory: GHSA-r75f-5x8p-qvmc
Package: litellm (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 1.81.16, < 1.83.7
Patched in: 1.83.7

Summary: LiteLLM has SQL Injection in Proxy API key verification

Details:
### Impact

A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted `Authorization` header to any LLM API route (for example `POST /chat/completions`) and reach this query through the proxy's error-handling path.

An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages.

### Patches

Fixed in **`1.83.7`**. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to `1.83.7` or later.

### Workarounds

If upgrading is not immediately possible, set `disable_error_logs: true` under `general_settings`. This removes the path through which unauthenticated input reaches the vulnerable query.

### References

- Patched release: [`v1.83.7-stable`](https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable)

**Discovery Credit**: Tencent YunDing Security Lab
GitHub Security Advisory: GHSA-mw35-8rx3-xf9r
Package: ray (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 2.49.0, < 2.55.0
Patched in: 2.55.0

Summary: Ray: Remote Code Execution via Parquet Arrow Extension Type Deserialization

Details:
Ray Data registers custom Arrow extension types (`ray.data.arrow_tensor`, `ray.data.arrow_tensor_v2`, `ray.data.arrow_variable_shaped_tensor`) globally in PyArrow. When PyArrow reads a Parquet file containing one of these extension types, it calls `__arrow_ext_deserialize__` on the field's metadata bytes. Ray's implementation passes these bytes directly to `cloudpickle.loads()`, achieving arbitrary code execution during schema parsing, before any row data is read.

In May 2024, Ray fixed a related vulnerability in `PyExtensionType`-based extension types ([issue #41314](https://github.com/ray-project/ray/issues/41314), [PR #45084](https://github.com/ray-project/ray/pull/45084)). In July 2025, [PR #54831](https://github.com/ray-project/ray/pull/54831) introduced `cloudpickle.loads()` into the replacement extension types' deserialization path, reintroducing the same class of vulnerability.

## Impact

- **Affected versions**: Ray 2.49.0 through 2.54.0 (latest release as of March 2026). The vulnerable `_deserialize_with_fallback` function with `cloudpickle.loads()` was introduced in commit `f6d21db1a4` ([PR #54831](https://github.com/ray-project/ray/pull/54831), July 2025), first released in Ray 2.49.0.
- **Affected configurations**: Any process that uses Ray Data and reads Parquet files. The extension types are registered globally in PyArrow, so all Parquet reads in the process are affected, including `ray.data.read_parquet()`, `pyarrow.parquet.read_table()`, `pandas.read_parquet()`, etc.
- **Attacker prerequisites**: The attacker must place a crafted Parquet file where a Ray Data pipeline reads it. No authentication or cluster access is required. The Parquet file must contain a column with a `ray.data.arrow_tensor` (or v2, or variable-shaped) extension type name, which makes this a targeted attack against Ray Data users.
GitHub Security Advisory: GHSA-xqmj-j6mv-4862
Package: litellm (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 1.80.5, < 1.83.7
Patched in: 1.83.7

Summary: LiteLLM: Server-Side Template Injection in /prompts/test endpoint

Details:
### Impact
The `POST /prompts/test` endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process.

The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host.

Proxy deployments running an affected version are in scope.

### Patches
The issue is fixed in **`1.83.7-stable`**. The fix switches the prompt template renderer to a sandboxed environment that blocks the attributes this attack relies on.

LiteLLM recommends upgrading to `1.83.7-stable` or later.

### Workarounds
If upgrading is not immediately possible:

1. Block `POST /prompts/test` at your reverse proxy or API gateway.
2. Review and rotate API keys that should not have access to prompt management routes.
GitHub Security Advisory: GHSA-v638-38fc-rhfv
Package: aws-encryption-sdk (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
Vulnerable versions: >= 4.0.0, < 4.0.4
Patched in: 4.0.5

Summary: AWS Encryption SDK for Python: Key commitment policy bypass via shared key cache

Details:
## Summary
AWS Encryption SDK (ESDK) for Python is a client-side encryption library. An issue exists where, under certain circumstances, a specific cryptographic algorithm downgrade in the caching layer might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts.

## Impact
This issue requires all of the following conditions to be true: (1) Two ESDK for Python clients with different commitment policies share a single CachingCryptoMaterialsManager instance within the same process. (2) The client with the weaker commitment policy encrypts first, warming the cache. (3) Both clients use matching encryption contexts. (4) Both clients use the pre-configured default algorithm suite.

These conditions may occur during a migration from ESDK for Python v1 to newer versions, as v1 did not support key commitment.

When the weaker-policy client encrypts first, the cache stores encryption materials that do not enforce key commitment. Subsequent callers — including those configured to require key commitment — are served these cached materials instead of generating new ones that satisfy their policy. This results in encryption without key commitment, meaning the same ciphertext can be validly decrypted to different plaintexts under different keys (the "Invisible Salamanders" issue; see https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf). A threat actor who controls ciphertext can cause a recipient to decrypt a message different from what the sender encrypted, breaking message integrity.

## Impacted versions
- From 2.0 to 2.5.1
- From 3.0 to 3.3.0
- From 4.0 to 4.0.4

## Patches
This issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

## Workarounds
If a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache.

References
If there are any questions or comments about this advisory, contact AWS Security through the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

## Acknowledgement
Thanks to [1seal.org](http://1seal.org/) for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-v638-38fc-rhfv
Package: aws-encryption-sdk (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
Vulnerable versions: >= 2.0.0, < 3.3.0
Patched in: 3.3.1

Summary: AWS Encryption SDK for Python: Key commitment policy bypass via shared key cache

Details:
## Summary
AWS Encryption SDK (ESDK) for Python is a client-side encryption library. An issue exists where, under certain circumstances, a specific cryptographic algorithm downgrade in the caching layer might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts.

## Impact
This issue requires all of the following conditions to be true: (1) Two ESDK for Python clients with different commitment policies share a single CachingCryptoMaterialsManager instance within the same process. (2) The client with the weaker commitment policy encrypts first, warming the cache. (3) Both clients use matching encryption contexts. (4) Both clients use the pre-configured default algorithm suite.

These conditions may occur during a migration from ESDK for Python v1 to newer versions, as v1 did not support key commitment.

When the weaker-policy client encrypts first, the cache stores encryption materials that do not enforce key commitment. Subsequent callers — including those configured to require key commitment — are served these cached materials instead of generating new ones that satisfy their policy. This results in encryption without key commitment, meaning the same ciphertext can be validly decrypted to different plaintexts under different keys (the "Invisible Salamanders" issue; see https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf). A threat actor who controls ciphertext can cause a recipient to decrypt a message different from what the sender encrypted, breaking message integrity.

## Impacted versions
- From 2.0 to 2.5.1
- From 3.0 to 3.3.0
- From 4.0 to 4.0.4

## Patches
This issue has been addressed in ESDK for Python versions 3.3.1 and 4.0.5. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

## Workarounds
If a customer requires operating multiple instances of the Python ESDK each with differently configured key commitment policies, they must not share a key cache.

References
If there are any questions or comments about this advisory, contact AWS Security through the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

## Acknowledgement
Thanks to [1seal.org](http://1seal.org/) for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-58qw-9mgm-455v
Package: pip (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 26.0.1
Patched in: unpatched

Summary: pip has an interpretation conflict due to handling both concatenated tar and ZIP files as ZIP files

Details:
pip handles concatenated tar and ZIP files as ZIP files regardless of filename or whether a file is both a tar and ZIP file. This behavior could result in confusing installation behavior, such as installing "incorrect" files according to the filename of the archive. New behavior only proceeds with installation if the file identifies uniquely as a ZIP or tar archive, not as both.
GitHub Security Advisory: GHSA-qhfq-gvvc-5q6q
Package: doris-mcp-server (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 0.1.0, < 0.6.1
Patched in: 0.6.1

Summary: Apache Doris MCP Server vulnerable to SQL Injection via improper query context neutralization

Details:
Apache Doris MCP Server versions prior to 0.6.1 are affected by an improper neutralization flaw in query context handling that may allow execution of unintended SQL statements and bypass of intended query validation and access restrictions through the MCP query execution interface. Versions 0.6.1 and later are not affected.
GitHub Security Advisory: GHSA-5h65-jx66-j7p5
Package: fschat (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.2.26
Patched in: unpatched

Summary: FastChat has Denial of Service Through Blocking Event Loop in Model Workers (Incomplete Fix for ff66426)

Details:
A security vulnerability has been detected in lm-sys fastchat up to 0.2.36. This issue affects the function api_generate of the component Worker API Endpoint. The manipulation leads to resource consumption. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. The identifier of the patch is c9e84b89c91d45191dc24466888de526fa04cf33. It is suggested to install a patch to address this issue. Commit ff66426 patched this issue in api_generate of base_model_worker.py but missed other entry points.
GitHub Security Advisory: GHSA-f3q6-69f3-vwch
Package: fschat (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: <= 0.2.36
Patched in: unpatched

Summary: FastChat has a Content Moderation Bypass via Arena Side-by-Side Views

Details:
A vulnerability was detected in lm-sys fastchat up to 0.2.36. Impacted is the function add_text of the component Arena Side-by-Side View Handler. The manipulation results in incorrect control flow. The attack can be launched remotely. The exploit is now public and may be used. The root cause was fixed in commit 34eca62 for gradio_block_arena_named.py, but three other files were missed.
GitHub Security Advisory: GHSA-95ww-475f-pr4f
Package: ragas (PIP)
Severity: LOW (CVSS 6.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.2.3, <= 0.4.3
Patched in: unpatched

Summary: RAGAS has SSRF via Multi-Modal Faithfulness Collections Module

Details:
A security flaw has been discovered in vibrantlabsai RAGAS up to 0.4.3. The affected element is the function _try_process_local_file/_try_process_url of the file src/ragas/metrics/collections/multi_modal_faithfulness/util.py of the component Collections Module. Performing a manipulation of the argument retrieved_contexts results in server-side request forgery. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The security patch for CVE-2025-45691 was applied to a different module only. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-5w6h-pjw6-wvc6
Package: apache-airflow-providers-keycloak (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 0.0.1, < 0.7.0
Patched in: 0.7.0

Summary: apache-airflow-providers-keycloak: Missing OAuth 2.0 State and PKCE Enables Login CSRF and Session Fixation

Details:
The Keycloak authentication manager in `apache-airflow-providers-keycloak` did not generate or validate the OAuth 2.0 `state` parameter on the login / login-callback flow, and did not use PKCE. An attacker with a Keycloak account in the same realm could deliver a crafted callback URL to a victim's browser and cause the victim to be logged into the attacker's Airflow session (login-CSRF / session fixation), where any credentials the victim subsequently stored in Airflow Connections would be harvestable by the attacker. Users are advised to upgrade `apache-airflow-providers-keycloak` to 0.7.0 or later.
GitHub Security Advisory: GHSA-w9r4-94fj-xp69
Package: apache-airflow-core (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: >= 3.0.0, < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow Exposes Secrets in Variables Saved as JSON Dictionaries

Details:
Secrets in Variables saved as JSON dictionaries were not properly redacted - in case the variables were retrieved by the user the secrets stored as nested fields were not masked.

If developers do not store variables with sensitive values in JSON form, their projects are not affected. Otherwise upgrade to the fixed version, Apache Airflow 3.2.0.
GitHub Security Advisory: GHSA-h97w-pm3w-mwmc
Package: apache-airflow-core (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.0.0, < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow allows users with asset materialize permissions to trigger DAGs outside of their permissions

Details:
UI / API User with asset materialize permission could trigger dags they had no access to. Users are advised to migrate to Airflow version 3.2.0 that fixes the issue.
GitHub Security Advisory: GHSA-w7cf-2pmc-5m4c
Package: apache-airflow-core (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow exposes SQL stack trace despite "api/expose_stack_traces" set to false

Details:
In case of SQL errors, exception/stack trace of errors was exposed in API even if "api/expose_stack_traces" was set to false. That could lead to exposing additional information to potential attacker. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue.
GitHub Security Advisory: GHSA-6ffj-2wg2-w45j
Package: apache-airflow-core (PIP)
Severity: HIGH (CVSS 7.2)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow allows code execution through crafted XCom payloads

Details:
Dag Authors, who normally should not be able to execute code in the webserver context could craft XCom payload causing the webserver to execute arbitrary code. Since Dag Authors are already highly trusted, severity of this issue is Low. Users are recommended to upgrade to Apache Airflow 3.2.0, which fixes the issue.
GitHub Security Advisory: GHSA-vfmq-68hx-4jfw
Package: lxml (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: < 6.1.0
Patched in: 6.1.0

Summary: lxml: Default configuration of iterparse() and ETCompatXMLParser() allows XXE to local files

Details:
### Impact
Using either of the two parsers in the default configuration (with `resolve_entities=True`) allows untrusted XML input to read local files.

### Patches
lxml 6.1.0 changes the default to `resolve_entities='internal'`, thus disallowing local file access by default.

### Workarounds
Setting the `resolve_entities` option explicitly to `resolve_entities='internal'` or `resolve_entities=False` disables the local file access.

### Resources
Original report: https://bugs.launchpad.net/lxml/+bug/2146291

The default option was changed to `resolve_entities='internal'` for the normal XML and HTML parsers in lxml 5.0. The default was not changed for `iterparse()` and `ETCompatXMLParser()` at the time. lxml 6.1 makes the safe option the default for all parsers.
GitHub Security Advisory: GHSA-7jqv-fw35-gmx9
Package: nbconvert (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-23: Relative Path Traversal
Vulnerable versions: >= 6.5.0, < 7.17.1
Patched in: 7.17.1

Summary: nbconvert has an Arbitrary File Read via Path Traversal in HTMLExporter Image Embedding

Details:
## Summary

When `HTMLExporter.embed_images=True`, nbconvert's markdown renderer allows arbitrary file read via path traversal in image references. A malicious notebook can exfiltrate sensitive files from the conversion host by embedding them as base64 data URIs in the output HTML.

## Patches

Upgrade to nbconvert 7.17.1

## Workarounds

Do not enable `HTMLExporter.embed_images` (it is not enabled by default).