deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mjw2-v2hm-wj34
Package: dagster-duckdb (PIP)
Severity: HIGH (CVSS 8.3)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 0.29.0
Patched in: 0.29.1

Summary: Dagster Vulnerable to SQL Injection via Dynamic Partition Keys in Database I/O Manager Integrations

Details:
### Summary

The DuckDB, Snowflake, BigQuery, and DeltaLake I/O managers constructed SQL WHERE clauses by interpolating dynamic partition key values into queries without escaping. A user with the `Add Dynamic Partitions` permission could create a partition key that injects arbitrary SQL, which would execute against the target database backend under the I/O manager's credentials.

Only deployments that use dynamic partitions are affected. Pipelines using static or time-window partitions are not impacted.

### Impact

**Dagster OSS**: Any user with access to the Dagster API can create dynamic partition keys. Organizations should assess exposure based on who has API access in their deployment. Dagster is typically deployed in trusted environments where users who can manage partitions already have equivalent database access through other means. 

**Dagster+**: In most Dagster+ deployments using default permission sets, the `Add Dynamic Partitions` permission is granted to users with an Editor role or above, who typically already have the ability to modify the affected tables and the asset code that accesses them.

The vulnerability is most relevant in deployments where this permission has been granted independently of broader database access, such as certain multi-tenant or custom RBAC configurations. In those cases, an affected user could read or modify data within the databases accessible to the I/O manager, beyond what their role would otherwise permit. Organizations should review which users hold this permission and assess their exposure accordingly.

### Remediation

**Update to the patched versions listed above.** No configuration changes or workarounds are required alongside the update. Only your Dagster code version needs to be updated; the Dagster+ agent/Dagster OSS daemon/webserver do not need to be updated.

The fix ensures that partition key values are properly escaped before inclusion in SQL queries across all affected I/O managers.

If you are unable to apply the update, manual workarounds are described [here](https://gist.github.com/gibsondan/6d0c483f8499a8b1cd460cddc9fd8f72).
GitHub Security Advisory: GHSA-x3cv-r3g3-fpg9
Package: mcp-neo4j-cypher (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: Neo4j Labs MCP Servers: SSRF and Data Modification via read_only Mode Bypass Through CALL Procedures

Details:
### Summary
The `read_only` mode in `mcp-neo4j-cypher` versions prior to 0.6.0 can be bypassed using `CALL` procedures. 
### Details

#### Impact
The enforcing of `read_only` mode in vulnerable versions could be bypassed by certain APOC procedures.

#### Patches
v0.6.0 release hardened the checks around the mode. The only way to guarantee the server actions is to limit the permissions of the db credentials available to the server.

### Notes
Impacts for server-side request forgery vulnerabilities may depend on both the configuration of the vulnerable system as well as the presence of other systems in the environment that could be accessed as part of exploitation.
#### Recommended hardening

- Limit the apoc procedures to what's required
- [Manage data loading privileges](https://neo4j.com/docs/operations-manual/current/authentication-authorization/load-privileges/ )
- Don't relax the default settings without compensating controls
    - `apoc.import.file.enabled` is `false` by default
    - `apoc.import.file.use_neo4j_config` is `true` by default to restrict file imports to the import folder

### Credits
We want to publicly recognise the contribution of [Yotam Perkal](https://github.com/yotampe-pluto) from [Pluto Security](https://pluto.security/).
GitHub Security Advisory: GHSA-ggmg-cqg6-j45g
Package: sentry (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 21.12.0, < 26.2.0
Patched in: unpatched

Summary: Sentry: Improper authentication on SAML SSO process allows user identity linking

Details:
### Impact
A critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via our private bug bounty program.

The vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.

For self-hosted users, you are only vulnerable if the following conditions are met:
- You have more than one organization configured (SENTRY_SINGLE_ORGANIZATION = False).
- A malicious user has existing access and permissions to modify SSO settings for another organization in your multo-organization instance. 

### Patches
- [Sentry SaaS](https://sentry.io/): The fix was deployed on February 18, 2026. No action is required.
- [Self-Hosted Sentry](https://github.com/getsentry/self-hosted): If only a single organization is allowed (SENTRY_SINGLE_ORGANIZATION = True), then no action is needed. We recommend upgrading to version 26.2.0 or higher.

### Workarounds
User account-based two-factor authentication prevents an attacker from being able to complete authentication with a victim's user account. Organization administrators cannot do this on a user's behalf, this requires individual users to ensure 2FA has been enabled for their account.

You can manage your two-factor authentication settings on your Account Settings > [Security](https://sentry.io/settings/account/security/) page. For step-by-step details, please see our [helpdesk article](https://sentry.zendesk.com/hc/en-us/articles/[PII_REDACTED]4235-How-do-I-enable-two-factor-authentication-2FA-on-my-Sentry-account).
GitHub Security Advisory: GHSA-r7w7-9xr2-qq2r
Package: langchain-openai (PIP)
Severity: LOW (CVSS 3.1)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.1.14
Patched in: 1.1.14

Summary: langchain-openai: Image token counting SSRF protection can be bypassed via DNS rebinding

Details:
## Summary

`langchain-openai`'s `_url_to_size()` helper (used by `get_num_tokens_from_messages` for image token counting) validated URLs for SSRF protection and then fetched them in a separate network operation with independent DNS resolution. This left a TOCTOU / DNS rebinding window: an attacker-controlled hostname could resolve to a public IP during validation and then to a private/localhost IP during the actual fetch.

The practical impact is limited because the fetched response body is passed directly to Pillow's `Image.open()` to extract dimensions — the response content is never returned, logged, or otherwise exposed to the caller. An attacker cannot exfiltrate data from internal services through this path. A potential risk is blind probing (inferring whether an internal host/port is open based on timing or error behavior).

## Affected versions

- `langchain-openai` < 1.1.14

## Patched versions

- `langchain-openai` >= 1.1.14 (requires `langchain-core` >= 1.2.31)

## Affected code

**File:** `libs/partners/openai/langchain_openai/chat_models/base.py` — `_url_to_size()`

The vulnerable pattern was a validate-then-fetch with separate DNS resolution:

```python
validate_safe_url(image_source, allow_private=False, allow_http=True)
# ... separate network operation with independent DNS resolution ...
response = httpx.get(image_source, timeout=timeout)
```

## Fix

The fix replaces the validate-then-fetch pattern with an SSRF-safe httpx transport (`SSRFSafeSyncTransport` from `langchain-core`) that:

- Resolves DNS once and validates all returned IPs against a policy (private ranges, cloud metadata, localhost, k8s internal DNS)
- Pins the connection to the validated IP, eliminating the DNS rebinding window
- Disables redirect following to prevent redirect-based SSRF bypasses

This fix was released in langchain-openai 1.1.14.
GitHub Security Advisory: GHSA-phv5-vq5p-qhp7
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 3.0.0, < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow: JWT token appearing in logs

Details:
JWT Tokens used by tasks were exposed in logs. This could allow UI users to act as Dag Authors. 
Users are advised to upgrade to Airflow version that contains fix.

Users are recommended to upgrade to version 3.2.0, which fixes this issue.
GitHub Security Advisory: GHSA-q2hg-643c-gw8h
Package: apache-airflow (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: Apache Airflow: RCE by race condition in example_xcom dag

Details:
The example example_xcom that was included in airflow documentation implemented unsafe pattern of reading value
from xcom in the way that could be exploited to allow UI user who had access to modify XComs to perform arbitrary
execution of code on the worker. Since the UI users are already highly trusted, this is a Low severity vulnerability.

It does not affect Airflow release - example_dags are not supposed to be enabled in production environment, however
users following the example could replicate the bad pattern. Documentation of Airflow 3.2.0 contains version of
the example with improved resiliance for that case.

Users who followed that pattern are advised to adjust their implementations accordingly.
GitHub Security Advisory: GHSA-jj8c-mmj3-mmgv
Package: authlib (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 1.6.11
Patched in: 1.6.11

Summary: Authlib: Cross-site request forging when using cache

Details:
### Summary

There is no CSRF protection on the cache feature on most integrations clients.

### Details
In `authlib.integrations.starlette_client.OAuth`, no CSRF protection is set up when using the cache parameter. When _not_ using the cache parameter, the use of SessionMiddleware ties the client to the auth state, preventing CSRF attacks. With the cache, there is no such mechanism. Other integratons have the same issue, it's not just starlette.

The state parameter is taken from the callback URL and the state is fetched from the cache without checking that it is the same client calling the redirect endpoint as was the one that initiated the auth flow.

This issue is documented in RFC 6749 section 10.12:
https://datatracker.ietf.org/doc/html/rfc6749#section-10.12

### PoC
- Set up a Starlette integration with a cache
- The attacker starts the auth flow up until before the callback URL is followed.
- The attacked sends the redirect URL to the victim
- The victim now completes the authorisation

### Impact
This impacts all users that use the cache to store auth state.

All users will be vulnerable to CSRF attacks and may have an attacker's account tied to their own. In our specific scenario, this allowed attackers to push invoices into a victim's account, ready to be paid. Very serious.
GitHub Security Advisory: GHSA-cw73-5f7h-m4gv
Package: upsonic (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 0.72.0
Patched in: 0.72.0

Summary: Upsonic: remote code execution vulnerability in its MCP server/task creation functionality

Details:
Upsonic 0.71.6 contains a remote code execution vulnerability in its MCP server/task creation functionality. The application allows users to define MCP tasks with arbitrary command and args values. Although an allowlist exists, certain allowed commands (npm, npx) accept argument flags that enable execution of arbitrary OS commands. Maliciously crafted MCP tasks may lead to remote code execution with the privileges of the Upsonic process. In version 0.72.0 Upsonic added a warning about using Stdio servers being able to execute commands directly on the machine.
GitHub Security Advisory: GHSA-x284-j5p8-9c5p
Package: pypdf (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 6.10.2
Patched in: 6.10.2

Summary: pypdf: Manipulated FlateDecode image dimensions can exhaust RAM

Details:
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing an image using `/FlateDecode` with large size values.

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

### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734).
GitHub Security Advisory: GHSA-4pxv-j86v-mhcw
Package: pypdf (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-834: Excessive Iteration
Vulnerable versions: < 6.10.2
Patched in: 6.10.2

Summary: pypdf: Possible long runtimes for wrong size values in incremental mode

Details:
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires loading a PDF with a large trailer `/Size` value in incremental mode.

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

### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3735](https://github.com/py-pdf/pypdf/pull/3735).
GitHub Security Advisory: GHSA-7gw9-cf7v-778f
Package: pypdf (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 6.10.2
Patched in: 6.10.2

Summary: pypdf: Manipulated FlateDecode predictor parameters can exhaust RAM

Details:
### Impact
An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing a stream compressed using `/FlateDecode` with a `/Predictor` unequal 1 and large predictor parameters.

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

### Workarounds
If you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734).
GitHub Security Advisory: GHSA-33qf-q99x-wpm8
Package: homeassistant-cli (PIP)
Severity: MODERATE (CVSS 5.6)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Home Assistant Command-line Interface: Handling of user-supplied Jinja2 templates

Details:
### Impact

Up to 1.0.0 of `home-assitant-cli` (or `hass-cli` for short) an unrestricted environment was used to handle Jninja2 templates instead of a sandboxed one. The user-supplied input within Jinja2 templates was rendered locally with no restrictions. This gave users access to Python's internals and extended the scope of templating beyond the intended usage.

E. g., it was possible to render a template with `hass-cli template bad-template.j2 --local` that contained entries like

````j2
{%- set b   = environ.__globals__['__builtins__'] -%}
{%- set os  = b['__import__']('os') -%}
{%- set bio = b['__import__']('builtins') -%}
...
````

or other malicious Jinja2 expressions. This can lead to arbitrary code execution on the local machine.

In a two step process an adversary could trick/convince an user to download third-party templates which contain harmful code (e. g., perform data manipulation or establish a remote shell)  then to render those templates unchecked/reviewed/verified with `--local`. 

The issue only affect the local machine and not a remote Home Assistant instance. It also requires user interventions.

### Patches

1.0.0 uses `ImmutableSandboxedEnvironment` and restricts the usage of environment variables.

### Workarounds

Evaluate the Jninja2 templates manually or  tool-based before rendering with `hass-cli`.
GitHub Security Advisory: GHSA-4g48-54q2-fg7q
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 3.1.8
Patched in: 3.1.8

Summary: Apache Airlfow: Sensitive Azure Service Bus connection string (and possibly other providers) exposed to users with view access

Details:
The `access_key` and `connection_string` connection properties were not marked as sensitive names in secrets masker. This means that user with read permission could see the values in Connection UI, as well as when Connection was accidently logged to logs, those values could be seen in the logs. Azure Service Bus used those properties to store sensitive values. Possibly other providers could be also affected if they used the same fields to store sensitive data.

If you used Azure Service Bus connection with those values set or if you have other connections with those values storing senesitve values, you should upgrade Airflow to 3.1.8.
GitHub Security Advisory: GHSA-v92g-xgxw-vvmm
Package: Mako (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.3.10
Patched in: 1.3.11

Summary: Mako: Path traversal via double-slash URI prefix in TemplateLookup

Details:
### Summary

`TemplateLookup.get_template()` is vulnerable to path traversal when a URI starts with `//` (e.g., `//../../../secret.txt`). The root cause is an inconsistency between two slash-stripping implementations:

- `Template.__init__` strips **one** leading `/` using `if`/slice
- `TemplateLookup.get_template()` strips **all** leading `/` using `re.sub(r"^\/+", "")`

When a URI like `//../../../../etc/passwd` is passed:
1. `get_template()` strips all `/` → `../../../../etc/passwd` → file found via `posixpath.join(dir_, u)`
2. `Template.__init__` strips one `/` → `/../../../../etc/passwd` → `normpath` → `/etc/passwd`
3. `/etc/passwd`.startswith(`..`) → `False` → **check bypassed**

### Impact

Arbitrary file read: any file readable by the process can be returned as rendered template content when an application passes untrusted input directly to `TemplateLookup.get_template()`.

Note: this is exploitable at the library API level. HTTP-based exploitation is mitigated by Python's `BaseHTTPRequestHandler` which normalizes double-slash prefixes since CPython gh-87389. Applications using other HTTP servers that do not normalize paths may be affected.

### Fix

Changed `Template.__init__` to use `lstrip("/")` instead of stripping only a single leading slash, so both code paths handle leading slashes consistently.
GitHub Security Advisory: GHSA-ffgh-3jrf-8wvh
Package: weblate (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Prefix-Based Repository Boundary Check Bypass via Symlink/Junction Path Prefix Collision

Details:
### Impact
Weblate repository-boundary validation relies on string prefix checks on resolved absolute paths. In multiple code paths, the check uses startswith against the repository root path. This is not path-segment aware and can be bypassed when the external path shares the same string prefix as the repository path (for example, repo and repo_outside).

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

### References
Thanks to [m9nx4u](https://hackerone.com/m9nx4u) for reporting this issue via HackerOne.
GitHub Security Advisory: GHSA-f8hv-g549-hwg2
Package: weblate (PIP)
Severity: MODERATE (CVSS 4.1)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: SSRF via the webhook add-on using unprotected fetch_url()

Details:
### Impact
The webhook add-on did not utilize existing SSRF protection.

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

### Workarounds
Disabling the add-on would avoid misusing this.

### References
Thanks to @Lihfdgjr for reporting this via GitHub.
GitHub Security Advisory: GHSA-3382-gw9x-477v
Package: weblate (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Privilege escalation in the user API endpoint

Details:
### Impact

The user patching API endpoint didn't properly limit the scope of edits.

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


### References
Thanks to @tikket1 and @DavidCarliez for reporting this via GitHub. We received two individual reports for this.
GitHub Security Advisory: GHSA-xrwr-fcw6-fmq8
Package: weblate (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: SSRF via Project-Level Machinery Configuration 

Details:
### Impact
A user with the `project.edit` permission (granted by the per-project "Administration" role) can configure machine translation service URLs pointing to arbitrary internal network addresses. During configuration validation, Weblate makes an HTTP request to the attacker-controlled URL and reflects up to 200 characters of the response body back to the user in an error message. This constitutes a Server-Side Request Forgery (SSRF) with partial response read.

### Patches

* https://github.com/WeblateOrg/weblate/pull/18684
* The solution then has been cleaned up in followup patches

### Workarounds
Limiting available machinery services via WEBLATE_MACHINERY setting can avoid this.

### References

Thanks to @DavidCarliez for disclosing this via GitHub private vulnerability reporting.
GitHub Security Advisory: GHSA-hv99-mxm5-q397
Package: weblate (PIP)
Severity: HIGH (CVSS 7.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Arbitrary File Read via Symlink

Details:
### Impact

The ZIP download feature didn't verify downloaded file and it could follow symlinks outside the repository.

### Patches

* https://github.com/WeblateOrg/weblate/pull/18683

### References

Thanks to @DavidCarliez for reporting this vulnerability via GitHub.
GitHub Security Advisory: GHSA-5fhx-9jwj-867m
Package: weblate (PIP)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Authenticated SSRF via redirect bypass of ALLOWED_ASSET_DOMAINS in screenshot URL uploads

Details:
### Impact
The ALLOWED_ASSET_DOMAINS setting applied only to the first issued requests and didn't restrict possible redirects.

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

### References
This issue was reported by @spbavarva via GitHub.
GitHub Security Advisory: GHSA-558g-h753-6m33
Package: weblate (PIP)
Severity: HIGH (CVSS 8.0)
CWE: CWE-23: Relative Path Traversal, CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 5.17
Patched in: 5.17

Summary: Weblate: Remote code execution during backup restoration

Details:
### Impact
The project backup didn't filter Git and Mercurial configuration files and this could lead to remote code execution under certain circumstances.

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

### Workarounds
The project backup is only accessible to users who can create projects. Restricting access to this limits scope of the vulnerability.

### References
This issue was reported by [ggamno](https://hackerone.com/ggamno) via HackerOne.