deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4c99-qj7h-p3vg
Package: nbconvert (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-73: External Control of File Name or Path
Vulnerable versions: >= 6.5.0, < 7.17.1
Patched in: 7.17.1

Summary: nbconvert has an Arbitrary File Write via Path Traversal in Cell Attachment Filenames

Details:
# Arbitrary File Write via Path Traversal in Cell Attachment Filenames

## Summary

nbconvert allows arbitrary file writes to locations outside the intended output directory when processing notebooks containing crafted cell attachment filenames. The `ExtractAttachmentsPreprocessor` passes attachment filenames directly to the filesystem without sanitization, enabling path traversal attacks. This vulnerability provides complete control over both the destination path and file extension.


## Impact

This vulnerability allows writing files with arbitrary content to arbitrary filesystem locations, limited only by the permissions of the process running nbconvert. The attacker controls:
- Full destination path (via `../` traversal)
- Filename
- File extension
- File content

## Patches

- upgrade to nbconvert v7.17.1

## Workarounds

disable ExtractAttachmentsPreprocessor by setting:

```python
c. ExtractAttachmentsPreprocessor.enabled = False
```
GitHub Security Advisory: GHSA-grp3-h8m8-45p7
Package: glances (PIP)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.5.4
Patched in: 4.5.4

Summary: Glances has CQL Injection in its Cassandra Export Module via Unsanitized Config Values

Details:
## Summary

The Cassandra export module (`glances/exports/glances_cassandra/__init__.py`) interpolates `keyspace`, `table`, and `replication_factor` configuration values directly into CQL statements without validation. A user with write access to `glances.conf` can redirect all monitoring data to an attacker-controlled Cassandra keyspace.

## Vulnerable Code

```python
# Line 80
f"CREATE KEYSPACE {self.keyspace} WITH "
f"replication = {{ 'class': 'SimpleStrategy', 'replication_factor': '{self.replication_factor}' }}"

# Line 94
f"CREATE TABLE {self.table} (plugin text, time timeuuid, stat map<text,float>, PRIMARY KEY (plugin, time)) WITH CLUSTERING ORDER BY (time DESC)"

# Line 112
stmt = f"INSERT INTO {self.table} (plugin, time, stat) VALUES (?, ?, ?)"
```

## Steps to Reproduce

1. Configure `glances.conf` with malicious `table` value:
```ini
[cassandra]
host = 127.0.0.1
port = 9042
keyspace = glances
table = attacker_ks.captured_stats
```
2. Create attacker keyspace in Cassandra
3. Run `glances --export cassandra`
4. All monitoring data is written to `attacker_ks.captured_stats` instead of the legitimate table

**Confirmed output:**
```
INSERT stmt: INSERT INTO attacker_ks.captured_stats (plugin, time, stat) VALUES (?, ?, ?)
Legitimate table row count: 0
Attacker table row count: 1
[CONFIRMED] plugin=cpu, stat={'user': 50.0}
```

## Impact

All exported monitoring data (CPU, memory, network, disk I/O) is silently redirected to an attacker-controlled Cassandra keyspace — both data exfiltration and data loss.

## Proposed Fix

```python
import re

def _validate_cql_identifier(name: str) -> str:
    if not re.match(r'^[a-zA-Z_][a-zA-Z0-9_.]*$', name):
        raise ValueError(f"Invalid CQL identifier: {name!r}")
    return name

# In __init__(): validate before use
self.keyspace = _validate_cql_identifier(self.keyspace)
self.table = _validate_cql_identifier(self.table)
```

![PoC](https://raw.githubusercontent.com/n0z0/cve-evidence/main/2026-04/20260403_004238_glances_cassandra_cql_injection_poc.png)
GitHub Security Advisory: GHSA-gfc2-9qmw-w7vh
Package: Glances (PIP)
Severity: HIGH (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-306: Missing Authentication for Critical Function, CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains
Vulnerable versions: < 4.5.4
Patched in: 4.5.4

Summary: Glances: Cross-Origin Information Disclosure via Unauthenticated REST API (/api/4) due to Permissive CORS

Details:
### Summary
The Glances web server exposes a REST API (`/api/4/*`) that is accessible without authentication and allows cross-origin requests from any origin due to a permissive CORS policy (`Access-Control-Allow-Origin: *`).

This allows a malicious website to read sensitive system information from a running Glances instance in the victim’s browser, leading to cross-origin data exfiltration.

While a previous advisory exists for XML-RPC CORS issues, this report demonstrates that the REST API (`/api/4/*`) is also affected and exposes significantly more sensitive data.

### Details
When Glances is started in web mode (e.g., `glances -w -B 0.0.0.0`), it exposes a REST API endpoint at:
http://<host>:61208/api/4/all
The server responds with:
Access-Control-Allow-Origin: *

This allows any origin to perform cross-origin requests and read responses.

The `/api/4/all` endpoint returns extensive system information, including:
- Process list (`processlist`)
- System details (hostname, OS, CPU info)
- Memory and disk usage
- Network interfaces and IP address
- Running services and metrics
Because no authentication is required by default, this data is accessible to any web page.

### PoC
1. Start Glances:
glances -w -B 0.0.0.0

2. Create a malicious HTML file:

```
<!DOCTYPE html>
<html>
<body>
<script>
fetch("http://<victim-ip>:61208/api/4/all")
  .then(r => r.json())
  .then(data => {
    console.log("DATA:", data);
  });
</script>
</body>
</html>
```
2. Open the file in a browser while Glances is running.
3. Observe that the browser successfully retrieves sensitive system information from the API.
This works cross-origin (e.g., from file:// or attacker-controlled domains).

### Impact
A remote attacker can host a malicious website that, when visited by a victim running Glances, can:

- Read sensitive system information
- Enumerate running processes
- Identify network configuration and IP addresses
- Fingerprint the host system

This requires no authentication and no user interaction beyond visiting a web page. This represents a cross-origin information disclosure vulnerability and can aid further attacks such as reconnaissance or targeted exploitation.
GitHub Security Advisory: GHSA-h8wq-7xc4-p3qx
Package: nltk (PIP)
Severity: HIGH (CVSS 8.6)
CWE: CWE-36: Absolute Path Traversal
Vulnerable versions: < 3.9.3
Patched in: 3.9.3

Summary: NLTK has Arbitrary File Read via Absolute Path Input in nltk.util.filestring()

Details:
A vulnerability in the `filestring()` function of the `nltk.util` module in nltk version 3.9.2 allows arbitrary file read due to improper validation of input paths. The function directly opens files specified by user input without sanitization, enabling attackers to access sensitive system files by providing absolute paths or traversal paths. This vulnerability can be exploited locally or remotely, particularly in scenarios where the function is used in web APIs or other interfaces that accept user-supplied input.
GitHub Security Advisory: GHSA-cjcx-jfp2-f7m2
Package: pretalx (PIP)
Severity: HIGH (CVSS 8.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2026.1.0
Patched in: 2026.1.0

Summary: pretalx vulnerable to stored cross-site scripting in organizer search typeahead

Details:
The organiser search in the pretalx backend rendered submission titles, speaker display names, and user names/emails into the result dropdown using `innerHTML` string interpolation. Any user who controls one of those fields (which includes any registered user whose display name is looked up by an administrator) could include HTML or JavaScript that would execute in an organiser's browser when the organiser's search query matched the malicious record.

Triggering the vulnerability required:

1. An attacker-controlled field reachable by the search, which included any speaker's or submitter's display name in an event context (submitted a proposal) or any user at all for superusers.
2. An organiser user with more than just review permissions or administrator user performing a typeahead search whose query matched the malicious record. An attacker can make matches likely by placing common substrings in the payload-bearing field.

Once triggered, the injected script executed in the context of the pretalx organiser interface and could read the page's CSRF token, submit authenticated requests on the victim's behalf (including requests modifying data due to access to the CSRF token), or exfiltrate data visible to the victim.

### Patches

Fixed in pretalx v2026.1.0.

### Workarounds

There is no configuration-level workaround. Operators who cannot upgrade immediately can avoid using the organiser search bar, or apply the patch to `src/pretalx/static/orga/js/base.js` manually and re-collect static files.

### Credits

We thank Elad Meged from Novee Security for finding and reporting this vulnerability.
GitHub Security Advisory: GHSA-jm8c-9f3j-4378
Package: pretalx (PIP)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: < 2026.1.0
Patched in: 2026.1.0

Summary: pretalx mail templates vulnerable to email injection via unescaped user-controlled placeholders

Details:
An unauthenticated attacker can send arbitrary HTML-rendered emails from a pretalx instance's configured sender address by embedding malformed HTML or markdown link syntax in a user-controlled template placeholder such as the account display name. The most direct vector is the password-reset flow: the attacker registers an account with a malicious name, enters the victim's email address, and triggers a password reset. The resulting email is delivered from the event's legitimate sender address and passes SPF/DKIM/DMARC validation, making it a ready-made phishing vector.

The same class of bug affects every mail template that interpolates a user-controlled placeholder (speaker name, proposal title, biography, question answers, etc.), including organiser-triggered emails such as acceptance/rejection notifications.

### Credits

Thanks go to Mark Fijneman for finding and reporting a subset of this issue, which alerted us to the wider vulnerability.
GitHub Security Advisory: GHSA-mjw2-v2hm-wj34
Package: dagster-snowflake-polars (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-mjw2-v2hm-wj34
Package: dagster-deltalake (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-mjw2-v2hm-wj34
Package: dagster (PIP)
Severity: HIGH (CVSS 8.3)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 1.13.0
Patched in: 1.13.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-mjw2-v2hm-wj34
Package: dagster-gcp (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-mjw2-v2hm-wj34
Package: dagster-snowflake (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).