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.

Affected: Packagist: thorsten/phpmyfaq, Packagist: phpmyfaq/phpmyfaq

### Summary

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 "no token configured" and "attacker sent a matching empty token header."

### Details

The root cause is in two files:

**1. Installation default** (`src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php`, line 277-278):

```php 'api.enableAccess' => 'true', 'api.apiClientToken' => '', // ← defaults to empty string ```

**2. Authentication check** (`src/phpMyFAQ/Controller/AbstractController.php`, line 198-204):

```php protected function hasValidToken(): void { $request = Request::createFromGlobals(); if ($this->configuration->get('api.apiClientToken') !== $request->headers->get('x-pmf-token')) { throw new UnauthorizedHttpException('"x-pmf-token" is not valid.'); } } ```

The method uses strict inequality (`!==`). When `api.apiClientToken` is `''` (default) and the attacker sends `x-pmf-token: ` (empty header value), the comparison becomes `'' !== ''` which evaluates to `false` — no exception is thrown, and authentication is completely bypassed.

The OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged `'End…