<?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 08:17:51 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-329549</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-329549</link>
      <description>EUVD-2026-329549</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-329549</guid>
    </item>
    <item>
      <title>fkie_cve-2026-35672</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-35672</link>
      <description>&lt;p&gt;phpMyFAQ before 4.1.3 contains an authentication bypass vulnerability in API v4.0 where the default empty api.apiClientToken allows unauthenticated users to create and modify FAQ entries. Attackers can send an empty x-pmf-token header to bypass token validation and inject malicious content via POST endpoints /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;phpMyFAQ before 4.1.3 contains an authentication bypass vulnerability in API v4.0 where the default empty api.apiClientToken allows unauthenticated users to create and modify FAQ entries. Attackers can send an empty x-pmf-token header to bypass token validation and inject malicious content via POST endpoints /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-35672</guid>
    </item>
    <item>
      <title>GHSA-gp95-j463-vv28 — phpMyFAQ: Default Empty API Token Authentication Bypass</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gp95-j463-vv28</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: thorsten/phpmyfaq, Packagist: phpmyfaq/phpmyfaq&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A default empty API client token allows any unauthenticated user to create and modify FAQ entries, categories, and questions via the REST API. The vulnerability exists in all versions since API v4.0 was introduced because the installation process seeds `api.apiClientToken` with an empty string, and the `hasValidToken()` comparison logic cannot distinguish between &amp;#34;no token configured&amp;#34; and &amp;#34;attacker sent a matching empty token header.&amp;#34;&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The root cause is in two files:&lt;/p&gt;
&lt;p&gt;**1. Installation default** (`src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php`, line 277-278):&lt;/p&gt;
&lt;p&gt;```php
&amp;#39;api.enableAccess&amp;#39;   =&amp;gt; &amp;#39;true&amp;#39;,
&amp;#39;api.apiClientToken&amp;#39; =&amp;gt; &amp;#39;&amp;#39;,       // ← defaults to empty string
```&lt;/p&gt;
&lt;p&gt;**2. Authentication check** (`src/phpMyFAQ/Controller/AbstractController.php`, line 198-204):&lt;/p&gt;
&lt;p&gt;```php
protected function hasValidToken(): void
{
    $request = Request::createFromGlobals();
    if ($this-&amp;gt;configuration-&amp;gt;get(&amp;#39;api.apiClientToken&amp;#39;) !== $request-&amp;gt;headers-&amp;gt;get(&amp;#39;x-pmf-token&amp;#39;)) {
        throw new UnauthorizedHttpException(&amp;#39;&amp;#34;x-pmf-token&amp;#34; is not valid.&amp;#39;);
    }
}
```&lt;/p&gt;
&lt;p&gt;The method uses strict inequality (`!==`). When `api.apiClientToken` is `&amp;#39;&amp;#39;` (default) and the attacker sends `x-pmf-token: ` (empty header value), the comparison becomes `&amp;#39;&amp;#39; !== &amp;#39;&amp;#39;` which evaluates to `false` — no exception is thrown, and authentication is completely bypassed.&lt;/p&gt;
&lt;p&gt;The OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged `&amp;#39;End…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: thorsten/phpmyfaq, Packagist: phpmyfaq/phpmyfaq&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A default empty API client token allows any unauthenticated user to create and modify FAQ entries, categories, and questions via the REST API. The vulnerability exists in all versions since API v4.0 was introduced because the installation process seeds `api.apiClientToken` with an empty string, and the `hasValidToken()` comparison logic cannot distinguish between &amp;#34;no token configured&amp;#34; and &amp;#34;attacker sent a matching empty token header.&amp;#34;&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The root cause is in two files:&lt;/p&gt;
&lt;p&gt;**1. Installation default** (`src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php`, line 277-278):&lt;/p&gt;
&lt;p&gt;```php
&amp;#39;api.enableAccess&amp;#39;   =&amp;gt; &amp;#39;true&amp;#39;,
&amp;#39;api.apiClientToken&amp;#39; =&amp;gt; &amp;#39;&amp;#39;,       // ← defaults to empty string
```&lt;/p&gt;
&lt;p&gt;**2. Authentication check** (`src/phpMyFAQ/Controller/AbstractController.php`, line 198-204):&lt;/p&gt;
&lt;p&gt;```php
protected function hasValidToken(): void
{
    $request = Request::createFromGlobals();
    if ($this-&amp;gt;configuration-&amp;gt;get(&amp;#39;api.apiClientToken&amp;#39;) !== $request-&amp;gt;headers-&amp;gt;get(&amp;#39;x-pmf-token&amp;#39;)) {
        throw new UnauthorizedHttpException(&amp;#39;&amp;#34;x-pmf-token&amp;#34; is not valid.&amp;#39;);
    }
}
```&lt;/p&gt;
&lt;p&gt;The method uses strict inequality (`!==`). When `api.apiClientToken` is `&amp;#39;&amp;#39;` (default) and the attacker sends `x-pmf-token: ` (empty header value), the comparison becomes `&amp;#39;&amp;#39; !== &amp;#39;&amp;#39;` which evaluates to `false` — no exception is thrown, and authentication is completely bypassed.&lt;/p&gt;
&lt;p&gt;The OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged `&amp;#39;End…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gp95-j463-vv28</guid>
    </item>
  </channel>
</rss>
