How severe is GHSA-xw8c-rrvx-f7xq?

GHSA-xw8c-rrvx-f7xq has a CVSS score of 3.7/10, rated LOW. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-xw8c-rrvx-f7xq?

GHSA-xw8c-rrvx-f7xq affects the following packages: ciguard (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-xw8c-rrvx-f7xq?

Update ciguard to 0.8.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xw8c-rrvx-f7xq is resolved across your whole dependency graph.

How do I detect GHSA-xw8c-rrvx-f7xq in my PyPI dependencies?

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.

How do I mitigate GHSA-xw8c-rrvx-f7xq if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-xw8c-rrvx-f7xq?

O3 pinpoints whether GHSA-xw8c-rrvx-f7xq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xw8c-rrvx-f7xq actively exploited in the wild?

No public exploit code has been indexed for GHSA-xw8c-rrvx-f7xq yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-xw8c-rrvx-f7xq published, and has it been updated?

GHSA-xw8c-rrvx-f7xq was published on May 5, 2026 and was last updated on July 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-xw8c-rrvx-f7xq

LOW

GHSA-xw8c-rrvx-f7xq is a low-severity (CVSS 3.7) remote code execution vulnerability in ciguard. O3 Security confirms whether GHSA-xw8c-rrvx-f7xq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

ciguard: SCA HTTP client reads response body without size cap

Also known asCVE-2026-44219PYSEC-2026-2410

Published

May 5, 2026

Updated

Jul 13, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

🐍ciguard

Real-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

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.

References

Fix released in v0.8.2
CI regression gate added in v0.8.3
https://www.cve.org/CVERecord?id=CVE-2026-44219

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`ciguard`	≥ 0.6.0&&< 0.8.2	0.8.2

Detection & mitigation playbook

Open-source dependency

Detect
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-xw8c-rrvx-f7xq 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-xw8c-rrvx-f7xq 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-xw8c-rrvx-f7xq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 a

O3 Security · Impact-Aware SCA

Is GHSA-xw8c-rrvx-f7xq in your dependencies?

O3 detects GHSA-xw8c-rrvx-f7xq across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works