deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-42cr-w2gr-m54q
Package: wger (PIP)
Severity: LOW (CVSS 3.1)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2.1
Patched in: unpatched

Summary: wger: IDOR via user-unscoped cache keys on routine API actions exposes workout data

Details:
### Summary

Five routine detail action endpoints check a cache before calling `self.get_object()`. Cache keys are scoped only by `pk` — no user ID is included. When a victim has previously accessed their routine via the API, an attacker can retrieve the cached response for the same PK without any ownership check.

### Details

`wger/manager/api/views.py` — five actions follow this pattern (lines 134–201):

```python
@action(detail=True)
def date_sequence_display_mode(self, request, pk=None):
    cache_key = make_routine_api_date_sequence_display_cache_key(pk)
    cached = cache.get(cache_key)
    if cached:
        return Response(cached)   # returned WITHOUT calling self.get_object()
    # only reaches ownership check on cache miss
    routine = self.get_object()
    ...
```

Cache key construction in `wger/utils/cache.py:89–106`:

```python
def make_routine_api_date_sequence_display_cache_key(routine_id):
    return f"routine-api-date-sequence-display-{routine_id}"
    # No user ID in key
```

Cache TTL: 1 month (`4 * 604800` seconds, `settings_global.py:461`).

Affected endpoints:
```
GET /api/v2/routine/{pk}/date-sequence-display/
GET /api/v2/routine/{pk}/date-sequence-gym/
GET /api/v2/routine/{pk}/structure/
GET /api/v2/routine/{pk}/logs/
GET /api/v2/routine/{pk}/stats/
```

### PoC

```
1. Victim (user A) visits GET /api/v2/routine/5/structure/ → response cached under key "routine-api-structure-5"
2. Attacker (user B) visits GET /api/v2/routine/5/structure/ → cache hit → returns user A's routine structure without any ownership check
```

Requires the victim to have previously accessed the endpoint (cache must be populated). Once populated, the cache entry is valid for 1 month.

### Impact

An attacker with a registered account can retrieve another user's routine details — workout day sequences, exercise structure, training logs, and statistics — from cache without ownership verification.

**Fix**: Include the user ID in the cache key:
```python
def make_routine_api_date_sequence_display_cache_key(routine_id, user_id):
    return f"routine-api-date-sequence-display-{user_id}-{routine_id}"
```

Or move `self.get_object()` before the cache lookup so ownership is always verified first.
GitHub Security Advisory: GHSA-xf68-8hjw-7mpm
Package: wger (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2.1
Patched in: unpatched

Summary: wger: IDOR in RepetitionsConfig and MaxRepetitionsConfig API leak other users' workout data

Details:
### Summary

`RepetitionsConfigViewSet` and `MaxRepetitionsConfigViewSet` return all users' repetition config data because their `get_queryset()` calls `.all()` instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

### Details

`wger/manager/api/views.py:499` and `:518`:

```python
# VULNERABLE
class RepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return MaxRepetitionsConfig.objects.all()
```

Every sibling viewset in the same file correctly filters by user. For example, `WeightConfigViewSet` at line 459:

```python
# CORRECT — how it should work
def get_queryset(self):
    return WeightConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )
```

The same user filter is present on `SetsConfig`, `RestConfig`, `RiRConfig`, and their Max variants — only `RepetitionsConfig` and `MaxRepetitionsConfig` are missing it.

### PoC

```python
import requests

BASE = "http://localhost"
headers = {"Authorization": "Token YOUR_TOKEN"}  # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers)
print(r.json())  # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers)
print(r.json())  # same — all users' max repetition configs
```

Registration is open by default. Sequential IDs allow full enumeration.

### Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

**Fix**: Add the same user filter used by every other config viewset:
```python
def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )
```
GitHub Security Advisory: GHSA-x7hp-r3qg-r3cj
Package: pypdf (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 6.7.3
Patched in: 6.7.3

Summary: pypdf: Manipulated FlateDecode XFA streams 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 the `xfa` property of a reader or writer and the corresponding stream being compressed using `/FlateDecode`.

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

### Workarounds
If projects cannot upgrade yet, consider applying the changes from PR [#3658](https://github.com/py-pdf/pypdf/pull/3658).
GitHub Security Advisory: GHSA-wppc-7cq7-cgfv
Package: weblate (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-862: Missing Authorization
Vulnerable versions: < 5.16.1
Patched in: 5.16.1

Summary: Weblate: Missing access control for the AddonViewSet API exposes all addon configurations

Details:
### Impact

Users were able to obtain add-on configuration via API.

### Patches

* https://github.com/WeblateOrg/weblate/pull/18107
* https://github.com/WeblateOrg/weblate/pull/18164


### References

Weblate thanks @lighthousekeeper1212 for responsible disclosure.
GitHub Security Advisory: GHSA-mwf2-qr4v-94h2
Package: apache-superset (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-863: Incorrect Authorization
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: Apache Superset: Read-Only Bypass via Improper Input Validation on PostgreSQL Connections

Details:
An Improper Input Validation vulnerability exists in Apache Superset that allows an authenticated user with SQLLab access to bypass the read-only verification check when using a PostgreSQL database connection.
While the system effectively blocks standard Data Manipulation Language (DML) statements (e.g., INSERT, UPDATE, DELETE) on read-only connections, it fails to detect them in specially crafted SQL statements.

This issue affects Apache Superset: before 6.0.0.

Users are recommended to upgrade to version 6.0.0, which fixes the issue.
GitHub Security Advisory: GHSA-h294-8fxm-m2pj
Package: apache-superset (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: Apache Superset allows authenticated users to view sensitive data without explicit permissions

Details:
A Sensitive Data Exposure vulnerability exists in Apache Superset allowing authenticated users to retrieve sensitive user information. The Tag endpoint (disabled by default) allows users to retrieve a list of objects associated with a specific tag.
When these associated objects include Users, the API response improperly serializes and returns sensitive fields, including password hashes (pbkdf2), email addresses, and login statistics. This vulnerability allows authenticated users with low privileges (e.g., Gamma role) to view sensitive authentication data 

This issue affects Apache Superset: before 6.0.0.

Users are recommended to upgrade to version 6.0.0, which fixes the issue or make sure TAGGING_SYSTEM is False (Apache Superset current default)
GitHub Security Advisory: GHSA-3m2g-v7jf-7fxc
Package: apache-superset (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: Apache Superset Improper Authorization allows low-privileged users to bypass access controls 

Details:
An Improper Authorization vulnerability exists in Apache Superset that allows a low-privileged user to bypass data access controls. When creating a dataset, Superset enforces permission checks to prevent users from querying unauthorized data. However, an authenticated attacker with permissions to write datasets and read charts can bypass these checks by overwriting the SQL query of an existing dataset.

This issue affects Apache Superset: before 6.0.0.

Users are recommended to upgrade to version 6.0.0, which fixes the issue.
GitHub Security Advisory: GHSA-gvxg-9hqx-f4rg
Package: apache-superset (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 6.0.0
Patched in: 6.0.0

Summary: Apache Superset allows privileged users to conduct error-based SQL Injection

Details:
Improper Neutralization of Special Elements used in a SQL Command ('SQL Injection') vulnerability in Apache Superset allows an authenticated user with read access to conduct error-based SQL injection via the sqlExpression or where parameters.

This issue affects Apache Superset: before 6.0.0.

Users are recommended to upgrade to version 6.0.0, which fixes the issue.
GitHub Security Advisory: GHSA-48m2-v2r8-h23m
Package: apache-superset (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.1.2
Patched in: 4.1.2

Summary: Apache Superset: Incomplete DISALLOWED_SQL_FUNCTIONS default list for ClickHouse engine

Details:
Apache Superset utilizes a configurable dictionary, DISALLOWED_SQL_FUNCTIONS, to restrict the execution of potentially sensitive SQL functions within SQL Lab and charts. While this feature included restrictions for engines like PostgreSQL, a vulnerability was reported where the default list for the ClickHouse engine was incomplete.

This issue affects Apache Superset: before 4.1.2.

Users are recommended to upgrade to version 4.1.2, which fixes the issue.
GitHub Security Advisory: GHSA-vjqx-cfc4-9h6v
Package: mcp-server-git (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2026.1.14
Patched in: 2026.1.14

Summary: mcp-server-git : Path traversal in git_add allows staging files outside repository boundaries

Details:
In `mcp-server-git` versions prior to 2026.1.14, the `git_add` tool did not validate that file paths provided in the files argument were within the repository boundaries. The tool used GitPython's `repo.index.add(`, which did not enforce working-tree boundary checks for relative paths. As a result, relative paths containing `../` sequences that resolved outside the repository were accepted and staged into the Git index, potentially allowing sensitive files to be exfiltrated via subsequent commit and push operations. The fix in PR #3164 switches to `repo.git.add()`, which delegates to the Git CLI and properly rejects out-of-tree paths. Users are advised to upgrade to 2026.1.14 or newer to remediate this issue.

mcp-server-git thanks https://hackerone.com/0dd-g for reporting and contributing the fix.
GitHub Security Advisory: GHSA-76rv-2r9v-c5m6
Package: zae-limiter (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.10.0
Patched in: 0.10.1

Summary: zae-limiter: DynamoDB hot partition throttling enables per-entity Denial of Service

Details:
## Summary

All rate limit buckets for a single entity share the same DynamoDB partition key (`namespace/ENTITY#{id}`). A high-traffic entity can exceed DynamoDB's per-partition throughput limits (~1,000 WCU/sec), causing throttling that degrades service for that entity — and potentially co-located entities in the same partition.

## Details

Each `acquire()` call performs a `TransactWriteItems` (or `UpdateItem` in speculative mode) against items sharing the same partition key. For cascade entities, this doubles to 2-4 writes per request (child + parent). At sustained rates above ~500 req/sec for a single entity, DynamoDB's adaptive capacity may not redistribute fast enough, causing `ProvisionedThroughputExceededException`.

The library has no built-in mitigation:
- No partition key sharding/salting
- No write coalescing or batching
- No client-side admission control before hitting DynamoDB
- `RateLimiterUnavailable` is raised but the caller has already been delayed

## Impact

- **Availability**: High-traffic entities experience elevated latency and rejected requests beyond what their rate limits specify
- **Fairness**: Other entities sharing the same DynamoDB partition may experience collateral throttling
- **Multi-tenant risk**: In a shared LLM proxy scenario, one tenant's burst traffic could degrade service for others

## Reproduction

1. Create an entity with high rate limits (e.g., 100,000 rpm)
2. Send sustained traffic at 1,000+ req/sec to a single entity
3. Observe DynamoDB `ThrottledRequests` CloudWatch metric increasing
4. Observe `acquire()` latency spikes and `RateLimiterUnavailable` exceptions

## Remediation Design: Pre-Shard Buckets

- Move buckets to `PK={ns}/BUCKET#{entity}#{resource}#{shard}, SK=#STATE` — one partition per (entity, resource, shard)
- Auto-inject `wcu:1000` reserved limit on every bucket — tracks DynamoDB partition write pressure in-band (name may change during implementation)
- Shard doubling (1→2→4→8) triggered by client on `wcu` exhaustion or proactively by aggregator
- Shard 0 at suffix `#0` is source of truth for `shard_count`. Aggregator propagates to other shards
- Original limits stored on bucket, effective limits derived: `original / shard_count`. Infrastructure limits (`wcu`) not divided
- Shard selection: random/round-robin. On application limit exhaustion, retry on another shard (max 2 retries)
- Lazy shard creation on first access
- Bucket discovery via GSI3 (KEYS_ONLY) + BatchGetItem. GSI2 for resource aggregation unchanged
- Cascade: parent unaware, protected by own `wcu`
- Aggregator: parse new PK format, key by shard_id, effective limits for refill, filter `wcu` from snapshots
- Clean break migration: schema version bump, old buckets ignored, new buckets created on first access
- **$0.625/M preserved on hot path**
GitHub Security Advisory: GHSA-7p94-766c-hgjp
Package: nltk (PIP)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 3.9.2
Patched in: 3.9.3

Summary: NLTK has a Zip Slip Vulnerability

Details:
A critical vulnerability exists in the NLTK downloader component of nltk/nltk, affecting all versions. The _unzip_iter function in nltk/downloader.py uses zipfile.extractall() without performing path validation or security checks. This allows attackers to craft malicious zip packages that, when downloaded and extracted by NLTK, can execute arbitrary code. The vulnerability arises because NLTK assumes all downloaded packages are trusted and extracts them without validation. If a malicious package contains Python files, such as __init__.py, these files are executed automatically upon import, leading to remote code execution. This issue can result in full system compromise, including file system access, network access, and potential persistence mechanisms.
GitHub Security Advisory: GHSA-8r55-rv5w-6pfm
Package: apache-airflow (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data, CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 2.11.1
Patched in: 2.11.1

Summary: Apache Airflow exposes sensitive information in its log files

Details:
Airflow versions before 2.11.1 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive connection parameters were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.11.1 or a later version, which addresses this issue. Users who previously used the CLI to set connections should manually delete entries with those connection sensitive values from the log table. This is similar but not the same issue as CVE-2024-50378
GitHub Security Advisory: GHSA-r837-hpv7-pc2f
Package: apache-airflow (PIP)
Severity: HIGH (CVSS 8.4)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 2.11.1
Patched in: 2.11.1

Summary: Apache Airflow vulnerable to Code Injection in the web-server context via LogTemplate table

Details:
DAG Author (who already has quite a lot of permissions) could manipulate database of Airflow 2 in the way to execute arbitrary code in the web-server context, which they should normally not be able to do, leading to potentially remote code execution in the context of web-server (server-side) as a result of a user viewing historical task information.

The functionality responsible for that (log template history) has been disabled by default in 2.11.1 and users should upgrade to Airflow 3 if they want to continue to use log template history. They can also manually modify historical log file names if they want to see historical logs that were generated before the last log template change.
GitHub Security Advisory: GHSA-65mp-fq8v-56jr
Package: flask-reuploaded (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 1.5.0
Patched in: 1.5.0

Summary: Flask-Reuploaded vulnerable to Remote Code Execution via Server-Side Template Injection

Details:
### Impact
A critical path traversal and extension bypass vulnerability in Flask-Reuploaded allows remote attackers to achieve arbitrary file write and remote code execution through Server-Side Template Injection (SSTI).

### Patches
Flask-Reuploaded has been patched in version 1.5.0

### Workarounds

1. **Do not pass user input to the `name` parameter**
2. Use auto-generated filenames only
3. Implement strict input validation if `name` must be used

```python
from werkzeug.utils import secure_filename
import os

# Sanitize user input before passing to save()
safe_name = secure_filename(request.form.get('custom_name'))
# Remove path separators
safe_name = os.path.basename(safe_name)
# Validate extension matches policy
if not photos.extension_allowed(photos.get_extension(safe_name)):
    abort(400)
    
filename = photos.save(file, name=safe_name)
```

### Resources
The fix is documented in the pull request, see https://github.com/jugmac00/flask-reuploaded/pull/180.

A proper write-up was created by the reporter of the vulnerability, Jaron Cabral (https://www.linkedin.com/in/jaron-cabral-751994357/), but is not yet available as of time of this publication.
GitHub Security Advisory: GHSA-38wq-6q2w-hcf9
Package: rucio-webui (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 39.0.0rc1, < 39.3.1
Patched in: 39.3.1

Summary: Rucio WebUI has Username Enumeration via Login Error Message

Details:
### Summary
The WebUI login endpoint returns distinct error messages depending on whether a supplied username exists, allowing unauthenticated attackers to enumerate valid usernames.

### Details
When submitting invalid credentials to `/ui/login`, the WebUI responds with different error messages based on the existence of the provided username (identity). A non-existent username results in an error indicating that no account is associated with the identity, while an existing username with an incorrect password produces a different authentication-related error.

This behavioral difference allows an attacker to distinguish valid usernames from invalid ones by observing the response content.

### Proof of Concept
**Bogus Login (Non-existent Username "15251087")**  
Response contains:
```
Cannot get find any account associated with 15251087 identity.
```

**Bogus Login (Existing Username "root", Wrong Password)**  
Response contains:
```
Cannot get auth token. It is possible that the presented identity root is not mapped to any Rucio account root.
```

The difference in error messages confirms whether a username exists.

### Impact
An unauthenticated attacker can enumerate valid usernames, which may be leveraged for targeted password guessing, credential stuffing, or social engineering attacks.

### Remediation / Mitigation
Return a generic authentication failure message for all login errors, regardless of whether the username exists. Avoid disclosing account or identity existence through error responses. Consider implementing rate limiting or additional login throttling to further reduce abuse.

#### Reources:
- OWASP Authentication Cheat Sheet -  Authentication and Error Messages: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages
GitHub Security Advisory: GHSA-38wq-6q2w-hcf9
Package: rucio-webui (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 36.0.0rc1, < 38.5.4
Patched in: 38.5.4

Summary: Rucio WebUI has Username Enumeration via Login Error Message

Details:
### Summary
The WebUI login endpoint returns distinct error messages depending on whether a supplied username exists, allowing unauthenticated attackers to enumerate valid usernames.

### Details
When submitting invalid credentials to `/ui/login`, the WebUI responds with different error messages based on the existence of the provided username (identity). A non-existent username results in an error indicating that no account is associated with the identity, while an existing username with an incorrect password produces a different authentication-related error.

This behavioral difference allows an attacker to distinguish valid usernames from invalid ones by observing the response content.

### Proof of Concept
**Bogus Login (Non-existent Username "15251087")**  
Response contains:
```
Cannot get find any account associated with 15251087 identity.
```

**Bogus Login (Existing Username "root", Wrong Password)**  
Response contains:
```
Cannot get auth token. It is possible that the presented identity root is not mapped to any Rucio account root.
```

The difference in error messages confirms whether a username exists.

### Impact
An unauthenticated attacker can enumerate valid usernames, which may be leveraged for targeted password guessing, credential stuffing, or social engineering attacks.

### Remediation / Mitigation
Return a generic authentication failure message for all login errors, regardless of whether the username exists. Avoid disclosing account or identity existence through error responses. Consider implementing rate limiting or additional login throttling to further reduce abuse.

#### Reources:
- OWASP Authentication Cheat Sheet -  Authentication and Error Messages: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages