<?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>Sat, 10 Oct 2026 19:26:24 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-361335</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-361335</link>
      <description>EUVD-2026-361335</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-361335</guid>
    </item>
    <item>
      <title>fkie_cve-2026-72702</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72702</link>
      <description>&lt;p&gt;Grav CMS before 2.0.16 contains an origin validation bypass in the Uri::referrer() and Pages::referrerRoute() methods, which validate the Referer header using an unanchored string prefix match (str_starts_with($referrer, $base)) with no trailing delimiter. An attacker who controls a domain that begins with the victim site&amp;#39;s origin (e.g. https://example.com.attacker.tld) can send a request with such a Referer to be treated as same-origin, bypassing the Referer-based origin check.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Grav CMS before 2.0.16 contains an origin validation bypass in the Uri::referrer() and Pages::referrerRoute() methods, which validate the Referer header using an unanchored string prefix match (str_starts_with($referrer, $base)) with no trailing delimiter. An attacker who controls a domain that begins with the victim site&amp;#39;s origin (e.g. https://example.com.attacker.tld) can send a request with such a Referer to be treated as same-origin, bypassing the Referer-based origin check.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-72702</guid>
    </item>
    <item>
      <title>GHSA-9ccq-2jfg-qw33 — Grav: Origin validation bypass in Uri::referrer() and Pages::referrerRoute() via unanchored prefix match</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9ccq-2jfg-qw33</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: getgrav/grav&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`Grav\Common\Uri::referrer()` and `Grav\Common\Page\Pages::referrerRoute()` both check whether an incoming request&amp;#39;s `Referer` header &amp;#34;came from our site&amp;#34; using `str_starts_with($referrer, $base)`, where `$base` is the site&amp;#39;s own absolute root URL (for example `https://example.com`, no trailing slash). Because the comparison has no boundary character after the prefix, any `Referer` value that merely starts with that string is accepted, including a `Referer` from a completely different host such as `https://example.com.attacker.tld`.&lt;/p&gt;
&lt;p&gt;This is the same class of bug already fixed once in 2.0.15 for the fast static asset server (GHSA-4v9q-p283-qc2m, &amp;#34;also allowing any neighbouring directory whose name starts with the same letters&amp;#34;). The identical pattern is still present in both places that trust the `Referer` header, and neither is covered by that fix.&lt;/p&gt;
&lt;p&gt;## Affected product and version&lt;/p&gt;
&lt;p&gt;Product: Grav CMS, getgrav/grav
Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3
The pattern is not touched by any of the 2.0.15 security fixes, so earlier 2.x releases are likely affected too. I have not checked how far back it goes.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;`system/src/Grav/Common/Uri.php`, method `referrer()`:
```php
$referrer = $_SERVER[&amp;#39;HTTP_REFERER&amp;#39;] ?? null;
...
$base = $this-&amp;gt;rootUrl(true);   // e.g. &amp;#34;https://example.com&amp;#34;, no trailing slash
// Referrer should always have host set and it should come from the same base address.
if (!is_string($referrer) ||…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: getgrav/grav&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`Grav\Common\Uri::referrer()` and `Grav\Common\Page\Pages::referrerRoute()` both check whether an incoming request&amp;#39;s `Referer` header &amp;#34;came from our site&amp;#34; using `str_starts_with($referrer, $base)`, where `$base` is the site&amp;#39;s own absolute root URL (for example `https://example.com`, no trailing slash). Because the comparison has no boundary character after the prefix, any `Referer` value that merely starts with that string is accepted, including a `Referer` from a completely different host such as `https://example.com.attacker.tld`.&lt;/p&gt;
&lt;p&gt;This is the same class of bug already fixed once in 2.0.15 for the fast static asset server (GHSA-4v9q-p283-qc2m, &amp;#34;also allowing any neighbouring directory whose name starts with the same letters&amp;#34;). The identical pattern is still present in both places that trust the `Referer` header, and neither is covered by that fix.&lt;/p&gt;
&lt;p&gt;## Affected product and version&lt;/p&gt;
&lt;p&gt;Product: Grav CMS, getgrav/grav
Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3
The pattern is not touched by any of the 2.0.15 security fixes, so earlier 2.x releases are likely affected too. I have not checked how far back it goes.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;`system/src/Grav/Common/Uri.php`, method `referrer()`:
```php
$referrer = $_SERVER[&amp;#39;HTTP_REFERER&amp;#39;] ?? null;
...
$base = $this-&amp;gt;rootUrl(true);   // e.g. &amp;#34;https://example.com&amp;#34;, no trailing slash
// Referrer should always have host set and it should come from the same base address.
if (!is_string($referrer) ||…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9ccq-2jfg-qw33</guid>
    </item>
  </channel>
</rss>
