deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mqph-7h49-hqfm
Package: weblate (PIP)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: JavaScript localization CDN add-on allows arbitrary local file read outside the repository

Details:
### Impact
The translation memory API exposed unintended endpoints, which in turn didn't do proper access control.

### Patches
* https://github.com/WeblateOrg/weblate/pull/18516

### Workarounds
The CDN add-on is not enabled by default.

### References
Thanks to @spbavarva for reporting this responsibly via GitHub.
GitHub Security Advisory: GHSA-mpf5-3vph-q75r
Package: weblate (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Improper access control for the translation memory in API

Details:
### Impact
The translation memory API exposed unintended endpoints, which in turn didn't do proper access control.

### Patches
* https://github.com/WeblateOrg/weblate/pull/18513

### Workarounds
Blocking access to `/api/memory/` in the HTTP server removes access to this feature.

### References
This issue was reported by [ggamno](https://hackerone.com/ggamno) via HackerOne.
GitHub Security Advisory: GHSA-vj45-x3pj-f4w4
Package: weblate (PIP)
Severity: LOW (CVSS 3.1)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Improper access control for pending tasks in API

Details:
### Impact
The API for tasks didn't verify user access for pending tasks. This could expose logs of in-progress operations to users who don't have access to given scope.

### Patches
* https://github.com/WeblateOrg/weblate/pull/18515

### Workarounds
The attacker needs to guess the random UUID of the task, so exploiting this is unlikely with the default API rate limits.

### References
This issue was identified by Michal Čihař.
GitHub Security Advisory: GHSA-hm2w-vr2p-hq7w
Package: uefi-firmware (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: <= 1.12
Patched in: unpatched

Summary: UEFI Firmware Parser has a heap out-of-bounds write in tiano decompressor ReadCLen

Details:
`uefi-firmware` contains a heap out-of-bounds write vulnerability in the native tiano/EFI decompressor. in `uefi_firmware/compression/Tiano/Decompress.c`, `ReadCLen()` reads `Number = GetBits(Sd, CBIT)` with `CBIT = 9`, so `Number` can be as large as `511`, while the destination array `Sd->mCLen` has `NC = 510` elements. the loop writes while `Index < Number` without enforcing `Index < NC`. additionally, the `CharC == 2` run-length path performs `GetBits(Sd, 9) + 20`, allowing up to `531` zero writes through `Sd->mCLen[Index++] = 0`.

Reachability is through the normal parsing path: `CompressedSection.process()` -> `efi_compressor.TianoDecompress()` -> `TianoDecompress()` -> `DecodeC()` -> `ReadCLen()`.

Minimum impact is a deterministic crash; depending on build/runtime details, the heap memory corruption may be exploitable for code execution in the context of the parsing process. this project shipped its own copy of the decompressor without the upstream EDK2 hardening for this bug class.

- PR: <https://github.com/theopolis/uefi-firmware-parser/pull/145>
- fix commit: <https://github.com/theopolis/uefi-firmware-parser/commit/bf3dfaa8a05675bae6ea0cbfa082ddcebfcde23e>
- upstream related fixes: CVE-2017-5731, CVE-2017-5732, CVE-2017-5733, CVE-2017-5734, CVE-2017-5735
GitHub Security Advisory: GHSA-2689-5p89-6j3j
Package: uefi-firmware (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: <= 1.12
Patched in: unpatched

Summary: UEFI Firmware Parser has a stack out-of-bounds write in tiano decompressor MakeTable

Details:
`uefi-firmware` contains a stack out-of-bounds write vulnerability in the native tiano/EFI decompressor. in `uefi_firmware/compression/Tiano/Decompress.c`, `MakeTable()` does not validate that bit-length values read from the compressed bitstream are within the expected range (`0..16`). a crafted firmware blob can supply bit lengths greater than `16`, causing out-of-bounds writes to the stack-allocated `Count[17]` array and related decode tables.

reachability is through the normal parsing path: `CompressedSection.process()` -> `efi_compressor.TianoDecompress()` -> `TianoDecompress()` -> `ReadPTLen()` -> `MakeTable()`.

Minimum impact is a deterministic crash; depending on build/runtime details, the stack memory corruption may be exploitable for code execution in the context of the parsing process. this project shipped its own copy of the decompressor without the upstream EDK2 hardening for this bug class.

References:

- PR: <https://github.com/theopolis/uefi-firmware-parser/pull/145>
- fix commit: <https://github.com/theopolis/uefi-firmware-parser/commit/bf3dfaa8a05675bae6ea0cbfa082ddcebfcde23e>
- upstream related fixes: CVE-2017-5731, CVE-2017-5732, CVE-2017-5733, CVE-2017-5734, CVE-2017-5735
GitHub Security Advisory: GHSA-rr7j-v2q5-chgv
Package: langsmith (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-359: Exposure of Private Personal Information to an Unauthorized Actor, CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 0.7.30
Patched in: 0.7.31

Summary: LangSmith SDK: Streaming token events bypass output redaction

Details:
## Summary

The LangSmith SDK's output redaction controls (hideOutputs in JS, hide_outputs in Python) do not apply to streaming token events. When an LLM run produces streaming output, each chunk is recorded as a new_token event containing the raw token value. These events bypass the redaction pipeline entirely — prepareRunCreateOrUpdateInputs (JS) and _hide_run_outputs (Python) only process the inputs and outputs fields on a run, never the events array. As a result, applications relying on output redaction to prevent sensitive LLM output from being stored in LangSmith will still leak the full streamed content via run events.

## Details

**Both JS and Python SDKs are affected.** The same pattern exists in both:

- **JS SDK**: `traceable.ts:997-1003` and `traceable.ts:1044-1050`
- **Python SDK**: `run_helpers.py:1924` and `run_helpers.py:1996`

In both SDKs, `new_token` events with raw `kwargs.token` values are added during streaming, and the redaction pipeline (`hideOutputs` in JS, `hide_outputs` in Python) only processes `inputs`/`outputs` — never `events`.
GitHub Security Advisory: GHSA-pfx2-9x9m-7ghx
Package: keystone (PIP)
Severity: HIGH (CVSS 7.7)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 28.0.1
Patched in: 28.0.1

Summary: OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean

Details:
In OpenStack Keystone before 28.0.1, the LDAP identity backend does not convert the user enabled attribute to a boolean when the user_enabled_invert configuration option is False (the default). The _ldap_res_to_model method in the UserApi class only performed string-to-boolean conversion when user_enabled_invert was True. When False, the raw string value from LDAP (e.g., "FALSE") was used directly. Since non-empty strings are truthy in Python, users marked as disabled in LDAP were treated as enabled by Keystone, allowing them to authenticate and perform actions. All deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected.
GitHub Security Advisory: GHSA-mj87-hwqh-73pj
Package: python-multipart (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-834: Excessive Iteration
Vulnerable versions: < 0.0.26
Patched in: 0.0.26

Summary: python-multipart affected by Denial of Service via large multipart preamble or epilogue data

Details:
### Summary

A denial of service vulnerability exists when parsing crafted `multipart/form-data` requests with large preamble or epilogue sections.

### Details

Two inefficient multipart parsing paths could be abused with attacker-controlled input.

Before the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary.

### Impact

An attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application.

### Mitigation

Upgrade to version `0.0.26` or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.
GitHub Security Advisory: GHSA-jj6c-8h6c-hppx
Package: pypdf (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-834: Excessive Iteration
Vulnerable versions: < 6.10.1
Patched in: 6.10.1

Summary: pypdf has long runtimes for wrong size values in cross-reference and object streams

Details:
### Impact

An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with wrong large `/Size` values or object streams with wrong large `/N` values.

### Patches

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

### Workarounds

If you cannot upgrade yet, consider applying the changes from PR [#3733](https://github.com/py-pdf/pypdf/pull/3733).
GitHub Security Advisory: GHSA-gqrq-j6pm-98c2
Package: h2o (PIP)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-73: External Control of File Name or Path, CWE-610: Externally Controlled Reference to a Resource in Another Sphere
Vulnerable versions: < 3.46.0.1
Patched in: 3.46.0.1

Summary: External Control of File Name or Path in h2oai/h2o-3

Details:
Remote unauthenticated attackers can overwrite arbitrary server files with attacker-controllable data. The data that the attacker can control is not entirely arbitrary. h2o writes a CSV/XLS/etc file to disk, so the attacker data is wrapped in quotations and starts with "C1", if they're exporting as CSV.
GitHub Security Advisory: GHSA-fgmx-xfp3-w28p
Package: aws-mcp (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 1.7.0
Patched in: unpatched

Summary: aws-mcp has a Command Injection Remote Code Execution Vulnerability

Details:
aws-mcp-server AWS CLI Command Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of aws-mcp-server. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the handling of the allowed commands list. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the MCP server. Was ZDI-CAN-27969.
GitHub Security Advisory: GHSA-fj52-5g4h-gmq8
Package: pyload-ng (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: <= 0.5.0b3.dev97
Patched in: unpatched

Summary: pyLoad's Session Not Invalidated After Permission Changes

Details:
### Summary
The `pyload` application does not properly invalidate or modify sessions upon changes made to a user's permissions.

### Details
Whenever an administrator changes the permissions a specific account has, they do not expect that account still being able to access data that their new permissions do not allow. This is not the case for the `pyload` application, as a user with a valid session can still perform the actions.

### PoC
Take a user with all the permissions, as shown below.
![image](https://user-images.githubusercontent.com/44903767/294956335-0e4da84f-bf9a-42c8-87f1-f5ff35967c63.png)

We now log in as this user.
![image](https://user-images.githubusercontent.com/44903767/294956539-ac6805fe-957d-4289-8ca9-2f3b6b2878a3.png)

Let us now take away all the permissions.
![image](https://user-images.githubusercontent.com/44903767/294956689-757e6e08-03fd-42eb-b4a5-1ceefa6c24ed.png)

The logged in session can still be used to access everything in the application.
![image](https://user-images.githubusercontent.com/44903767/294956943-fa0f23c0-a28c-4eed-89d6-1cc074feda6d.png)

### Impact
Should permissions be taken away, then the user is expected not to be able to execute the actions belonging to those actions anymore.
GitHub Security Advisory: GHSA-mc4f-r875-v87w
Package: apache-airflow (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.1.8, < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow: Unsafe Deserialization via Legacy Serialization Keys (__type/__var) Bypass in XCom API

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 resolves this issue.
GitHub Security Advisory: GHSA-4f3f-g24h-fr8m
Package: keras (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.13.2
Patched in: 3.13.2

Summary: Keras has an untrusted deserialization vulnerability

Details:
A vulnerability in the `TFSMLayer` class of the `keras` package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of `.keras` models, even when `safe_mode=True`. This bypasses the security guarantees of `safe_mode` and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the `from_config()` method.
GitHub Security Advisory: GHSA-j86x-fwp2-qh7v
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow: Secrets from Airflow config file logged in plain text in DAG run logs UI

Details:
Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow's intentions and security model of Airflow did not suggest different assumptions. The overall security model, workload isolation, and JWT authentication details are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement.

Users are recommended to upgrade to version 3.2.0, which fixes this issue.
GitHub Security Advisory: GHSA-7xjm-g8f4-rp26
Package: giskard-checks (PIP)
Severity: MODERATE (CVSS 7.8)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 1.0.1b1
Patched in: 1.0.2b1

Summary: Giskard has Unsandboxed Jinja2 Template Rendering in ConformityCheck

Details:
## Summary
 
The `ConformityCheck` class in `giskard-checks` rendered the `rule` parameter through Jinja2's default `Template()` constructor. Because the `rule` string is silently interpreted as a Jinja2 template, a developer may not realize that template expressions embedded in rule definitions are evaluated at runtime. In a scenario where check definitions are loaded from an untrusted source (e.g. a shared project file or externally contributed configuration), this could lead to arbitrary code execution.

`giskard-checks` is a local developer testing library with no network-facing service. Check definitions, including the `rule` parameter, are provided in application code or project configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite by a developer.

However, the implicit template evaluation of the `rule` parameter is not obvious from the API surface. This hidden behavior increases the likelihood of a developer inadvertently passing untrusted input to it when integrating the library into a larger system. 

## Affected Component
 
`conformity.py`, line 59:
```python
from jinja2 import Template
...
formatted_rule = Template(self.rule).render(trace=trace)
```
 
## Affected Versions
 
`giskard-checks` < 1.0.2b1
 
## Patched Version
 
`giskard-checks` >= **1.0.2b1** (template parsing removed from rule evaluation entirely)
 
## Remediation
 
Upgrade to `giskard-checks` >= 1.0.2b1. The template rendering has been removed from rule evaluation.
 
## Credit
 
Giskard-AI thanks @dhabaleshwar for identifying the unsandboxed template usage.
GitHub Security Advisory: GHSA-rq2q-4r55-9877
Package: giskard-checks (PIP)
Severity: LOW (CVSS 5.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: <= 1.0.1b1
Patched in: 1.0.2b1

Summary: Giskard has a Regular Expression Denial of Service (ReDoS) in RegexMatching Check

Details:
## Summary
The RegexMatching check in the `giskard-checks` package passes a user-supplied regular expression pattern directly to Python's re.search() without any timeout, complexity guard, or pattern validation. An attacker who can control the regex pattern or the text being matched can craft inputs that trigger catastrophic backtracking in the regex engine, causing the process to hang indefinitely and denying service to all other operations. 

`giskard-checks` is a local developer testing library. Check definitions, including the pattern parameter, are provided in application code or configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite. The absence of a regex timeout could cause availability issues in automated environments such as CI/CD pipelines.

## Affected component
 
`text_matching.py`, line 457: `re.search(pattern, text)`
 
## Remediation
 
Upgrade to `giskard-checks` >= 1.0.2b1.
 
## Credit
 
Giskard-AI thanks @dhabaleshwar for identifying the missing timeout on regex evaluation.
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: >= 2.0.0a1, < 2.0.0a2
Patched in: 2.0.0a2

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-4p64-v8f5-r2gx
Package: justhtml (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-178: Improper Handling of Case Sensitivity, CWE-436: Interpretation Conflict, CWE-471: Modification of Assumed-Immutable Data (MAID)
Vulnerable versions: <= 1.15.0
Patched in: 1.16.0

Summary: Multiple security fixes in justhtml

Details:
## Summary

`justhtml` `1.16.0` fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

- programmatic DOM input to `sanitize()` or `sanitize_dom()`
- reused or mutated sanitization policy objects
- custom policies that preserve foreign namespaces such as SVG or MathML

## Affected versions

- `justhtml` `<= 1.15.0`

## Fixed version

- `justhtml` `1.16.0` released on April 12, 2026

## Impact

### Policy reuse and mutation
Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

### In-memory sanitization gaps
Programmatic DOM sanitization could miss dangerous mixed-case tag names such as `ScRiPt` or `StYlE`, and custom `drop_content_tags` values such as `{"SCRIPT"}` could silently fail to drop dangerous subtrees.

### Serialization injection
Crafted programmatic doctype names could serialize into active markup before the document body.

### Foreign-namespace policy bypasses
Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

- animation elements such as `<set>` and `<animate>` that mutate already-sanitized attributes after sanitization
- presentation attributes such as `fill`, `clip-path`, `mask`, `marker-start`, and `cursor` containing external `url(...)` references
- programmatic DOM trees that claim `namespace="html"` but serialize as `<svg>` or `<math>`, bypassing foreign-content checks

### Rawtext hardening gap
Mixed-case programmatic `style` or `script` nodes could bypass rawtext hardening and preserve active stylesheet content such as remote `@import` rules.

## Default configuration

Most of these issues did **not** affect the normal `JustHTML(..., sanitize=True)` path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

## Recommended action

Upgrade to `justhtml` `1.16.0`.

If you cannot upgrade immediately:

- do not mutate `DEFAULT_POLICY`, `DEFAULT_DOCUMENT_POLICY`, or nested policy internals
- avoid reusing policy objects after mutating nested state
- avoid preserving SVG or MathML for untrusted input
- avoid preserving `style` or `script` in custom policies for untrusted input
- avoid serializing untrusted programmatic doctypes or DOM trees

## Credit

Discovered during an internal security review of `justhtml`.
GitHub Security Advisory: GHSA-r5v8-c28h-f8r8
Package: metagpt (PIP)
Severity: LOW (CVSS 6.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.8.2
Patched in: unpatched

Summary: MetaGPT affected by server-side request forgery in metagpt/utils/common.py

Details:
A security flaw has been discovered in FoundationAgents MetaGPT up to 0.8.2. This impacts the function decode_image of the file metagpt/utils/common.py. The manipulation of the argument img_url_or_b64 results in server-side request forgery. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.