<?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>Tue, 06 Oct 2026 16:15:37 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-326634</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-326634</link>
      <description>EUVD-2026-326634</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-326634</guid>
    </item>
    <item>
      <title>fkie_cve-2026-50131</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-50131</link>
      <description>&lt;p&gt;Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the IPv4 validation logic present starting in version 0.11.2 and prior to versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 appears incomplete. The `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations. Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue. Versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 contain an updated patch.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Fedify is a TypeScript library for building federated server apps powered by ActivityPub. Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the IPv4 validation logic present starting in version 0.11.2 and prior to versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 appears incomplete. The `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations. Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue. Versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 contain an updated patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-50131</guid>
    </item>
    <item>
      <title>GHSA-xw9q-2mv6-9fr8 — Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xw9q-2mv6-9fr8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @fedify/fedify, npm: @fedify/vocab-runtime&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.&lt;/p&gt;
&lt;p&gt;The `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.&lt;/p&gt;
&lt;p&gt;Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.&lt;/p&gt;
&lt;p&gt;I tested this against the current repository code at unreleased version 2.3.0. I used `&amp;gt;=0.11.2, &amp;lt;=2.2.3` as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.&lt;/p&gt;
&lt;p&gt;### Why this is not a duplicate of GHSA-p9cg-vqcc-grcx&lt;/p&gt;
&lt;p&gt;GHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.&lt;/p&gt;
&lt;p&gt;This report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classif…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @fedify/fedify, npm: @fedify/vocab-runtime&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.&lt;/p&gt;
&lt;p&gt;The `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.&lt;/p&gt;
&lt;p&gt;Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.&lt;/p&gt;
&lt;p&gt;I tested this against the current repository code at unreleased version 2.3.0. I used `&amp;gt;=0.11.2, &amp;lt;=2.2.3` as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.&lt;/p&gt;
&lt;p&gt;### Why this is not a duplicate of GHSA-p9cg-vqcc-grcx&lt;/p&gt;
&lt;p&gt;GHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.&lt;/p&gt;
&lt;p&gt;This report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classif…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xw9q-2mv6-9fr8</guid>
    </item>
  </channel>
</rss>
