GHSA-7ww3-xvf5-cxwm
MEDIUMciguard: Web UI is missing HTTP defence-in-depth headers
Blast Radius
ciguardReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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
SecurityHeadersMiddlewareatsrc/ciguard/web/security_headers.pyinjecting: X-Content-Type-Options nosniff, X-Frame-Options DENY, Referrer-Policy no-referrer, Permissions-Policyinterest-cohort=(), Cross-Origin-Opener-Policy same-origin, Cross-Origin-Resource-Policy same-origin, plus per-path CSP with/api/docs+/api/redoccarve-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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | ciguard | ≥ 0.1.0&&< 0.8.2 | 0.8.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ciguard. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update ciguard to 0.8.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7ww3-xvf5-cxwm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7ww3-xvf5-cxwm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7ww3-xvf5-cxwm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7ww3-xvf5-cxwm in your dependencies?
O3 detects GHSA-7ww3-xvf5-cxwm across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.