<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 12 Oct 2026 04:28:17 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-317996</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-317996</link>
      <description>EUVD-2026-317996</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-317996</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44219</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44219</link>
      <description>&lt;p&gt;ciguard is a static security auditor for CI/CD pipelines. From 0.6.0 to 0.8.1, both SCA HTTP clients (src/ciguard/analyzer/sca/osv.py and src/ciguard/analyzer/sca/endoflife.py) call payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;)) 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&amp;#39;s memory. This vulnerability is fixed in 0.8.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;ciguard is a static security auditor for CI/CD pipelines. From 0.6.0 to 0.8.1, both SCA HTTP clients (src/ciguard/analyzer/sca/osv.py and src/ciguard/analyzer/sca/endoflife.py) call payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;)) 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&amp;#39;s memory. This vulnerability is fixed in 0.8.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44219</guid>
    </item>
    <item>
      <title>GHSA-xw8c-rrvx-f7xq — ciguard: SCA HTTP client reads response body without size cap</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xw8c-rrvx-f7xq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ciguard&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Both SCA HTTP clients (`src/ciguard/analyzer/sca/osv.py` and `src/ciguard/analyzer/sca/endoflife.py`) call `payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;))` 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&amp;#39;s memory.&lt;/p&gt;
&lt;p&gt;## Threat scenario&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;t trigger cert validation). The unbounded read is structural defence-in-depth, not a directly exploitable bug today.&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;- 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`.&lt;/p&gt;
&lt;p&gt;## Discovery&lt;/p&gt;
&lt;p&gt;Found during ciguard&amp;#39;s first self-conducted pentest cycle, 2026-04-26.&lt;/p&gt;
&lt;p&gt;## CVSS Scoring&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;s calc 6.3 (Medium). Vector is correct — choosing v3.1 as the…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ciguard&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Both SCA HTTP clients (`src/ciguard/analyzer/sca/osv.py` and `src/ciguard/analyzer/sca/endoflife.py`) call `payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;))` 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&amp;#39;s memory.&lt;/p&gt;
&lt;p&gt;## Threat scenario&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;t trigger cert validation). The unbounded read is structural defence-in-depth, not a directly exploitable bug today.&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;- 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`.&lt;/p&gt;
&lt;p&gt;## Discovery&lt;/p&gt;
&lt;p&gt;Found during ciguard&amp;#39;s first self-conducted pentest cycle, 2026-04-26.&lt;/p&gt;
&lt;p&gt;## CVSS Scoring&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;s calc 6.3 (Medium). Vector is correct — choosing v3.1 as the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xw8c-rrvx-f7xq</guid>
    </item>
    <item>
      <title>PYSEC-2026-2410 — ciguard: SCA HTTP client reads response body without size cap</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-2410</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ciguard&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Both SCA HTTP clients (`src/ciguard/analyzer/sca/osv.py` and `src/ciguard/analyzer/sca/endoflife.py`) call `payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;))` 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&amp;#39;s memory.&lt;/p&gt;
&lt;p&gt;## Threat scenario&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;t trigger cert validation). The unbounded read is structural defence-in-depth, not a directly exploitable bug today.&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;- 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`.&lt;/p&gt;
&lt;p&gt;## Discovery&lt;/p&gt;
&lt;p&gt;Found during ciguard&amp;#39;s first self-conducted pentest cycle, 2026-04-26.&lt;/p&gt;
&lt;p&gt;## CVSS Scoring&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;s calc 6.3 (Medium). Vector is correct — choosing v3.1 as the…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: ciguard&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Both SCA HTTP clients (`src/ciguard/analyzer/sca/osv.py` and `src/ciguard/analyzer/sca/endoflife.py`) call `payload = json.loads(resp.read().decode(&amp;#39;utf-8&amp;#39;))` 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&amp;#39;s memory.&lt;/p&gt;
&lt;p&gt;## Threat scenario&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;t trigger cert validation). The unbounded read is structural defence-in-depth, not a directly exploitable bug today.&lt;/p&gt;
&lt;p&gt;## Patch&lt;/p&gt;
&lt;p&gt;- 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`.&lt;/p&gt;
&lt;p&gt;## Discovery&lt;/p&gt;
&lt;p&gt;Found during ciguard&amp;#39;s first self-conducted pentest cycle, 2026-04-26.&lt;/p&gt;
&lt;p&gt;## CVSS Scoring&lt;/p&gt;
&lt;p&gt;- 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&amp;#39;s calc 6.3 (Medium). Vector is correct — choosing v3.1 as the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-2410</guid>
    </item>
  </channel>
</rss>
