deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3wq7-rqq7-wx6j
Package: aiohttp (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: AIOHTTP has late size enforcement for non-file multipart fields causes memory DoS

Details:
### Summary

For some multipart form fields, aiohttp read the entire field into memory before checking client_max_size.

### Impact

If an application uses `Request.post()` an attacker can send a specially crafted multipart request to force significant temporary memory allocation even when the request is ultimately rejected.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/cbb774f[PII_REDACTED]2ca0c413a71021d7b944145
GitHub Security Advisory: GHSA-m5qp-6w8w-w647
Package: aiohttp (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: AIOHTTP has a Multipart Header Size Bypass

Details:
### Summary

A response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability.

### Impact

Multipart headers were not subject to the same size restrictions in place for normal headers, potentially allowing substantially more data to be loaded into memory than intended. However, other restrictions in place limit the impact of this vulnerability.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/8a74257b3804c9aac0bf644af93070f68f6c5a6f
GitHub Security Advisory: GHSA-p998-jp59-783m
Package: aiohttp (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-36: Absolute Path Traversal, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: AIOHTTP affected by UNC SSRF/NTLMv2 Credential Theft/Local File Read in static resource handler on Windows

Details:
### Summary

On Windows the static resource handler may expose information about a NTLMv2 remote path.

### Impact

If an application is running on Windows, and using aiohttp's static resource handler (not recommended in production), then it may be possible for an attacker to extract the hash from an NTLMv2 path and then extract the user's credentials from there.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d
GitHub Security Advisory: GHSA-2vrm-gr82-f7m5
Package: aiohttp (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: AIOHTTP has CRLF injection through multipart part content type header construction

Details:
### Summary

An attacker who controls the `content_type` parameter in aiohttp could use this to inject extra headers or similar exploits.

### Impact

If an application allows untrusted data to be used for the multipart `content_type` parameter when constructing a request, an attacker may be able to manipulate the request to send something other than what the developer intended.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/9a6ada97e2c6cf1ce31727c6c9fcea17c21f6f06
GitHub Security Advisory: GHSA-hcc4-c3v8-rx92
Package: aiohttp (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: AIOHTTP Affected by Denial of Service (DoS) via Unbounded DNS Cache in TCPConnector

Details:
### Summary

An unbounded DNS cache could result in excessive memory usage possibly resulting in a DoS situation.

### Impact

If an application makes requests to a very large number of hosts, this could cause the DNS cache to continue growing and slowly use excessive amounts of memory.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/c4d77c3533122be353b8afca8e8675e3b4cbda98
GitHub Security Advisory: GHSA-w828-4qhx-vxx3
Package: anthropic (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 0.86.0, < 0.87.0
Patched in: 0.87.0

Summary: Claude SDK for Python: Memory Tool Path Validation Race Condition Allows Sandbox Escape

Details:
The async local filesystem memory tool in the Anthropic Python SDK validated that model-supplied paths resolved inside the sandboxed memory directory, but then returned the unresolved path for subsequent file operations. A local attacker able to write to the memory directory could retarget a symlink between validation and use, causing reads or writes to escape the sandbox. The synchronous memory tool implementation was not affected.

Users on the affected versions are advised to update to the latest version.

Claude SDK for Python thanks [hackerone.com/kasthelord](https://hackerone.com/kasthelord) for reporting this issue!
GitHub Security Advisory: GHSA-q5f5-3gjm-7mfm
Package: anthropic (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-276: Incorrect Default Permissions, CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: >= 0.86.0, < 0.87.0
Patched in: 0.87.0

Summary: Claude SDK for Python has Insecure Default File Permissions in Local Filesystem Memory Tool

Details:
The local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected.

Users on the affected versions are advised to update to the latest version.

Claude SDK for Python thanks [`lucasfutures`](https://hackerone.com/lucasfutures) on HackerOne for the report.
GitHub Security Advisory: GHSA-cmw6-hcpp-c6jp
Package: onnx (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 1.20.1
Patched in: 1.21.0

Summary: ONNX: Arbitrary File Read via ExternalData Hardlink Bypass in ONNX load

Details:
### Summary
The issue is in `onnx.load` — the code checks for symlinks to prevent path traversal, but completely misses hardlinks, which is the problem, since a hardlink looks exactly like a regular file on the filesystem.

### The Real Problem
The validator in `onnx/checker.cc` only calls `is_symlink()` and never checks the inode or `st_nlink`, so a hardlink walks right through every security check without any issues.

### Impact
Especially dangerous in AI supply chain scenarios like HuggingFace — a single malicious model is enough to silently steal secrets from the victim's machine without them noticing anything.
GitHub Security Advisory: GHSA-c65f-x25w-62jv
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt has CORS wildcard with allow_credentials=True in standalone servers

Details:
### Summary

Both standalone servers configure CORS with `allow_origins=["*"]`, `allow_credentials=True`, `allow_methods=["*"]`, and `allow_headers=["*"]`.

### Affected Code

```python
# server/key-server/app/main.py:86-92
# server/telemetry-server/app/main.py:23-29
app.add_middleware(
    CORSMiddleware,
    allow_origins=settings.cors_origins,  # defaults to ["*"]
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)
```

The docker-compose file (`openssl_encrypt_server/docker-compose.yml:75`) also defaults `CORS_ORIGINS` to `*`, and `.env.example` ships with `CORS_ORIGINS=*`.

### Impact

This is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker's website could make authenticated API calls on behalf of any user who visits it.

### Recommended Fix

- Remove wildcard defaults — require explicit origin configuration
- Never combine `allow_origins=["*"]` with `allow_credentials=True`
- Update `.env.example` with placeholder domains instead of `*`

### Fix

Fixed in commit `809416b` on branch `releases/1.4.x` — changed CORS default from ["*"] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.
GitHub Security Advisory: GHSA-4rh7-jwg9-m28m
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-598: Use of GET Request Method With Sensitive Query Strings
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt accepts refresh tokens as URL query parameters causing token leakage

Details:
### Summary

Refresh tokens are accepted as URL query parameters in the keyserver and telemetry server routes.

### Affected Code

```python
# openssl_encrypt_server/modules/keyserver/routes.py:214-215
# openssl_encrypt_server/modules/telemetry/routes.py:90-91
async def refresh_token(
    request: Request,
    refresh_token: str = Query(..., description="Refresh token")
):
```

### Impact

Tokens in URL query parameters are exposed in:
- Server access logs
- Proxy/CDN logs
- Browser history
- HTTP Referer headers
- Network monitoring tools

This creates significant token leakage risk.

### Recommended Fix

- Accept refresh tokens in the request body (POST) instead of query parameters
- Use `Body(...)` instead of `Query(...)`

### Fix

Fixed in commit `4b2adb0` on branch `releases/1.4.x` — moved refresh token from Query parameter to POST body via RefreshRequest Pydantic model.
GitHub Security Advisory: GHSA-2vhw-q7vh-7xv2
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt's readiness endpoint leaks database error details to unauthenticated callers

Details:
### Summary

The `/ready` endpoint in `openssl_encrypt_server/server.py` at **lines 159-175** catches database errors and returns the full exception string in the response.

### Affected Code

```python
except Exception as e:
    return {"status": "not_ready", "reason": str(e)}
```

### Impact

Database exception messages can leak:
- Database hostnames and IP addresses
- Connection parameters and port numbers
- Driver version information
- Potentially database credentials if included in connection string errors

This information is available to unauthenticated callers.

### Recommended Fix

- Return a generic error message: `{"status": "not_ready", "reason": "database unavailable"}`
- Log the full exception server-side for debugging

### Fix

Fixed in commit `7aa8787` on branch `releases/1.4.x` — replaced str(e) with generic "database check failed" message; full exception logged server-side at WARNING level.
GitHub Security Advisory: GHSA-hvc7-763r-4f3h
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt has no owner verification on key revocation — any client can revoke any key

Details:
### Summary

The `revoke_key` method in `openssl_encrypt_server/modules/keyserver/service.py` at **lines 195-270** accepts a `client_id` parameter but never verifies that the requesting client is the same as `key.owner_client_id`.

### Impact

Any authenticated client can revoke any other client's key, as long as they provide a valid revocation signature. While the signature requirement mitigates this somewhat (you need the private key to sign), the lack of ownership check is a defense-in-depth gap.

### Recommended Fix

- Add an ownership check: verify `client_id == key.owner_client_id` before allowing revocation
- Return 403 Forbidden if the requesting client does not own the key

### Fix

Fixed in commit `05e45f3` on branch `releases/1.4.x` — added documentation that ML-DSA signature verification IS the cryptographic ownership check; added info-level logging on successful verification.
GitHub Security Advisory: GHSA-8h88-gxp3-j7pg
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt's unverified key bundle from_dict() + to_identity() path allows encryption to attacker keys

Details:
### Summary

The `PublicKeyBundle.from_dict()` method in `openssl_encrypt/modules/key_bundle.py` at **lines 329-361** creates bundles from untrusted data without verifying the signature. The docstring warns to call `verify_signature()` after creation, but the `to_identity()` method (line 363-391) can convert an unverified bundle directly to an `Identity` object.

### Affected Code

```python
@classmethod
def from_dict(cls, data: Dict) -> "PublicKeyBundle":
    """
    SECURITY: Does NOT verify signature. Call verify_signature() after creation.
    """
    # Creates bundle without verification
```

### Impact

If `from_dict()` followed by `to_identity()` is called without an intervening `verify_signature()` call, encryption could be performed against an attacker's public key, leaking secrets. While `key_resolver.py` (lines 146-147) does verify before use, the unguarded API path remains directly callable.

### Recommended Fix

- Add a `verified` flag to `PublicKeyBundle` that must be set before `to_identity()` can be called
- Or have `to_identity()` automatically call `verify_signature()` and raise on failure
- Or make `from_dict()` require verification as part of construction

### Fix

Fixed in commit `f4a1ba6` on branch `releases/1.4.x` — from_dict() now verifies self_signature by default (verify=True parameter); raises ValueError on verification failure.
GitHub Security Advisory: GHSA-538c-55jv-c5g9
Package: onnx (PIP)
Severity: HIGH (CVSS 8.6)
CWE: CWE-20: Improper Input Validation, CWE-400: Uncontrolled Resource Consumption, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: <= 1.20.1
Patched in: 1.21.0

Summary: ONNX: Malicious ONNX models can crash servers by exploiting unprotected object settings.

Details:
### Summary
The ExternalDataInfo class in ONNX was using Python’s setattr() function to load metadata (like file paths or data lengths) directly from an ONNX model file. The problem? It didn’t check if the "keys" in the file were valid. Because it blindly trusted the file, an attacker could craft a malicious model that overwrites internal object properties.

### Why its Dangerous
**Instant Crash DoS**: An attacker can set the length property to a massive number like 9 petabytes. When the system tries to load the model, it attempts to allocate all that RAM at once, causing the server to crash or freeze Out of Memory.

**Access Bypass**: By setting a negative offset -1, an attacker can trick the system into reading parts of a file it wasn't supposed to touch.

**Object Corruption**: Attackers can even inject "dunder" attributes like __class__ to change the object's type entirely, which could lead to more complex exploits.

**Fixed**: https://github.com/onnx/onnx/pull/7751 object state corruption and DoS via ExternalDataInfo attribute injection
GitHub Security Advisory: GHSA-5qvp-pr9f-2g2v
Package: poetry-plugin-tweak-dependencies-version (PIP)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-377: Insecure Temporary File
Vulnerable versions: <= 1.5.5
Patched in: 1.5.6

Summary: poetry-plugin-tweak-dependencies-version affected by CVE-2026-25645

Details:
Pin vulnerable version of requests library
GitHub Security Advisory: GHSA-qc22-xmq4-qg46
Package: c2cciutils (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 1.1.66
Patched in: 1.1.67

Summary: c2cciutils affected by CVE-2022-40896 

Details:
Pinned vulnerable version of Pygment [CVE-2022-40896](https://nvd.nist.gov/vuln/detail/CVE-2022-40896)
GitHub Security Advisory: GHSA-w2fm-2cpv-w7v5
Package: aiohttp (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 3.13.3
Patched in: 3.13.4

Summary: aiohttp allows unlimited trailer headers, leading to possible uncapped memory usage

Details:
### Summary

Insufficient restrictions in header/trailer handling could cause uncapped memory usage.

### Impact

An application could cause memory exhaustion when receiving an attacker controlled request or response. A vulnerable web application could mitigate these risks with a typical reverse proxy configuration.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/0c2e9da51126238a421568eb7c5b53e5b5d17b36
GitHub Security Advisory: GHSA-r23q-823p-vmf7
Package: mlflow (PIP)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 3.8.1
Patched in: 3.8.1

Summary: MLflow Command Injection vulnerability

Details:
A command injection vulnerability exists in MLflow's model serving container initialization code, specifically in the `_install_model_dependencies_to_env()` function. When deploying a model with `env_manager=LOCAL`, MLflow reads dependency specifications from the model artifact's `python_env.yaml` file and directly interpolates them into a shell command without sanitization. This allows an attacker to supply a malicious model artifact and achieve arbitrary command execution on systems that deploy the model. The vulnerability affects versions 3.8.0 and is fixed in version 3.8.1.
GitHub Security Advisory: GHSA-vhcx-3pq2-4fvc
Package: mlflow (PIP)
Severity: CRITICAL (CVSS 9.6)
CWE: CWE-29: Path Traversal: '..filename'
Vulnerable versions: < 3.9.0rc0
Patched in: 3.9.0rc0

Summary: MLFlow path traversal vulnerability

Details:
A path traversal vulnerability exists in the `extract_archive_to_dir` function within the `mlflow/pyfunc/dbconnect_artifact_cache.py` file of the mlflow/mlflow repository. This vulnerability, present in versions before v3.7.0, arises due to the lack of validation of tar member paths during extraction. An attacker with control over the tar.gz file can exploit this issue to overwrite arbitrary files or gain elevated privileges, potentially escaping the sandbox directory in multi-tenant or shared cluster environments.
GitHub Security Advisory: GHSA-ghq9-vc6f-8qjf
Package: torchgeo (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: >= 0.4, <= 0.6.0
Patched in: 0.6.1

Summary: TorchGeo Remote Code Execution Vulnerability

Details:
### Impact

TorchGeo 0.4–0.6.0 used an [`eval`](https://docs.python.org/3/library/functions.html#eval) statement in its model weight API that could allow an unauthenticated, remote attacker to execute arbitrary commands. All platforms that expose [`torchgeo.models.get_weight()`](https://torchgeo.readthedocs.io/en/v0.6.0/api/models.html#torchgeo.models.get_weight) or [`torchgeo.trainers`](https://torchgeo.readthedocs.io/en/v0.6.0/api/trainers.html) as an external API could be affected.

### Patches

The `eval` statement was replaced with a fixed enum lookup, preventing arbitrary code injection. All users are encouraged to upgrade to TorchGeo 0.6.1 or newer.

### Workarounds

In unpatched versions, input validation and sanitization can be used to avoid this vulnerability.

### References

#### Bug history

* Introduced: https://github.com/torchgeo/torchgeo/pull/917
* Patched: https://github.com/torchgeo/torchgeo/pull/2323
* Released: [v0.6.1](https://github.com/microsoft/torchgeo/releases/tag/v0.6.1)
GitHub Security Advisory: GHSA-p44q-vqpr-4xmg
Package: Flask-HTTPAuth (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 4.8.0
Patched in: 4.8.1

Summary: Flask-HTTPAuth invokes token verification callback when missing or empty token was given by client

Details:
## Summary

In a situation where the client makes a request to a token protected resource without passing a token, or passing an empty token, Flask-HTTPAuth would invoke the application's token verification callback function with the `token` argument set to an empty string. If the application had any users in its database with an empty string set as their token, then it could potentially authenticate the client request against any of those users.

## Notes

- This issue applies only to token authentication
- This issue applies only when the application verifies tokens by searching for them in a user database.
- This issue applies only if the application stores empty strings as user tokens when the user does not have an assigned token. It does not apply if the application sets those tokens to `NULL` instead.
- Tokens that are verified through cryptographic means (such as JWTs) are not affected by this issue.
- Basic and Digest authentication are not affected by this issue.

## Remediation

To protect against this issue, developers should make sure that no user in the user database has their `token` set to an empty string. If there are such users, change the value of those tokens to `NULL` instead.

Alternatively, developers can upgrade their projects to `Flask-HTTPAuth>=4.8.1`, which fixes this issue.
GitHub Security Advisory: GHSA-425g-fjhq-5h92
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt silently skips schema validation when jsonschema library is not installed

Details:
### Summary

In `openssl_encrypt/modules/json_validator.py` at **lines 234-238**, when the `jsonschema` library is not installed, all schema validation is silently skipped with only a print warning.

### Affected Code

```python
if not JSONSCHEMA_AVAILABLE:
    print(f"Warning: Cannot validate against schema '{schema_name}' - jsonschema library not available")
    return
```

Additionally, unknown metadata format versions (line 288-293) bypass schema validation entirely, and all schemas use `additionalProperties: true` allowing arbitrary extra fields.

### Impact

An attacker who can influence the Python environment (remove the jsonschema package) or craft metadata with an unknown version number can bypass all schema checks. Malformed or malicious metadata will be accepted without validation.

### Recommended Fix

- Make `jsonschema` a required dependency, not optional
- Or fail-closed: refuse to process metadata when validation cannot be performed
- Reject unknown format versions instead of silently skipping validation
- Consider using `additionalProperties: false` in schemas

### Fix

Fixed in commit `6e7f938` on branch `releases/1.4.x` — validate_against_schema() now raises JSONValidationError when jsonschema is unavailable instead of silently passing; changed print() warning to logging.warning().