\"@evil.com. PHP's FILTER_VALIDATE_EMAIL accepts this email as valid. The email is stored in the database without HTML sanitization and later rendered in the admin FAQ editor template using Twig's |raw filter, which bypasses auto-escaping entirely.\n\n### Details\n1. PHP FILTER_VALIDATE_EMAIL accepts RFC-valid quoted local parts with dangerous characters\n\nphpmyfaq/src/phpMyFAQ/Controller/Front"}},{"@type":"Question","name":"How severe is GHSA-98gw-w575-h2ph?","acceptedAnswer":{"@type":"Answer","text":"No CVSS score has been assigned to GHSA-98gw-w575-h2ph yet. Review the advisory details and affected package list to assess your exposure."}},{"@type":"Question","name":"Which packages are affected by GHSA-98gw-w575-h2ph?","acceptedAnswer":{"@type":"Answer","text":"GHSA-98gw-w575-h2ph affects the following packages: thorsten/phpmyfaq (Packagist), phpmyfaq/phpmyfaq (Packagist). Ecosystems affected: Packagist."}},{"@type":"Question","name":"How do I fix GHSA-98gw-w575-h2ph?","acceptedAnswer":{"@type":"Answer","text":"Update thorsten/phpmyfaq to 4.1.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-98gw-w575-h2ph is resolved across your whole dependency graph."}},{"@type":"Question","name":"How do I detect GHSA-98gw-w575-h2ph in my Packagist dependencies?","acceptedAnswer":{"@type":"Answer","text":"Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version."}},{"@type":"Question","name":"How do I mitigate GHSA-98gw-w575-h2ph if there is no patch (or I can't update yet)?","acceptedAnswer":{"@type":"Answer","text":"Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page."}},{"@type":"Question","name":"Is GHSA-98gw-w575-h2ph actively exploited in the wild?","acceptedAnswer":{"@type":"Answer","text":"No public exploit code has been indexed for GHSA-98gw-w575-h2ph yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure."}},{"@type":"Question","name":"What is the EPSS score for GHSA-98gw-w575-h2ph?","acceptedAnswer":{"@type":"Answer","text":"GHSA-98gw-w575-h2ph has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 20th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority."}},{"@type":"Question","name":"What type of vulnerability is GHSA-98gw-w575-h2ph?","acceptedAnswer":{"@type":"Answer","text":"GHSA-98gw-w575-h2ph is classified as Improper Input Validation (CWE-20), Cross-site Scripting (XSS) (CWE-79). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure."}},{"@type":"Question","name":"When was GHSA-98gw-w575-h2ph published, and has it been updated?","acceptedAnswer":{"@type":"Answer","text":"GHSA-98gw-w575-h2ph was published on March 31, 2026 and was last updated on April 6, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting."}}]}
NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐘 Packagist
Not in CISA KEV

phpMyFAQ is Vulnerable to Stored XSS via Unsanitized Email Field in Admin FAQ EditorGHSA-98gw-w575-h2ph

GHSA-98gw-w575-h2ph is a Improper Input Validation vulnerability in thorsten/phpmyfaq. A fix is available for thorsten/phpmyfaq — see the affected versions and patch details below.

Also known asCVE-2026-32629
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs20th percentile — riskier than 20% of all scored CVEsHighest risk
0.00%0.27%0.54%0.80%0.2%0.3%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

2 pkgs affected
🐘thorsten/phpmyfaq🐘phpmyfaq/phpmyfaq

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

An unauthenticated attacker can submit a guest FAQ with an email address that is syntactically valid per RFC 5321 (quoted local part) yet contains raw HTML — for example "<script>alert(1)</script>"@evil.com. PHP's FILTER_VALIDATE_EMAIL accepts this email as valid. The email is stored in the database without HTML sanitization and later rendered in the admin FAQ editor template using Twig's |raw filter, which bypasses auto-escaping entirely.

Details

  1. PHP FILTER_VALIDATE_EMAIL accepts RFC-valid quoted local parts with dangerous characters

phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/FaqController.php:99 $email = trim((string) Filter::filterVar($data->email, FILTER_VALIDATE_EMAIL)); PHP accepts "<script>alert(1)</script>"@evil.com as a valid email (RFC 5321 allows <, > inside quoted local parts). Confirmed: "<script>alert(1)</script>"@evil.com => string (valid, not false)

  1. Email stored raw without HTML sanitization

phpmyfaq/src/phpMyFAQ/Faq.php — email retrieved directly as $row->email from the database.

  1. Admin Twig template renders email with |raw

phpmyfaq/assets/templates/admin/content/faq.editor.twig:296 <input type="email" name="email" id="email" value="{{ faqData['email'] | raw }}" class="form-control">

Affected version: 4.2.0-alpha, commit f0dc86c8f

PoC

The reproduction of the vulnerability was implemented with the help of AI while reviewing the source code to generate the proof-of-concept. Please kindly note this for reference. Since the vulnerability has already been confirmed directly in the source code, the proof-of-concept code may be considered as a reference only.

Please extract the attached compressed file and proceed. poc.zip

  1. (docker compose -f docker-compose.yml down -v)
  2. docker compose -f docker-compose.yml up -d mariadb php-fpm nginx
  3. bash exploit.sh

  1. Access http://localhost:8888/admin/
  2. Log in with admin / Admin1234!
  3. After logging in, check whether the URL remains http://localhost:8888/admin/
  4. Go to Content → FAQ Administration → edit "poc" → alert popup should appear If it does not appear, you can also access it directly via: http://localhost:8888/admin/faq/edit/1/en
<img width="1388" height="239" alt="스크린샷 2026-03-12 오후 11 42 52" src="https://github.com/user-attachments/assets/b6d5446f-4eba-4cb2-9284-1bca4855142e" /> <img width="1171" height="92" alt="스크린샷 2026-03-12 오후 11 16 17" src="https://github.com/user-attachments/assets/3578e429-7106-4616-92ed-4167816d40f0" />

Impact

When an administrator opens /admin/faq/edit/{id}/{lang} to review the pending FAQ, the injected script executes in the admin's browser context. This allows an attacker to:

  • Steal the administrator's session cookie → full admin account takeover
  • Perform arbitrary admin actions (create users, modify content, change configuration)
  • Pivot to further attacks on the server

The attack chain requires no authentication. By default, records.allowNewFaqsForGuests=true allows unauthenticated FAQ submission, and records.defaultActivation=false guarantees the administrator must visit the edit page to review it.

Note on captcha: The built-in captcha is enabled by default when the PHP gd extension is present (spam.enableCaptchaCode=true). This prevents fully automated exploitation but does not prevent a targeted manual attack — an attacker can solve the captcha once and submit the payload.

Credits

wooseokdotkim

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistthorsten/phpmyfaqall versions4.1.1composer require thorsten/phpmyfaq:^4.1.1
🐘Packagistphpmyfaq/phpmyfaqall versions4.1.1composer require phpmyfaq/phpmyfaq:^4.1.1

Affected Products

1 product · 1 configurations
Application
phpmyfaqphpmyfaq
< 4.1.1
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update thorsten/phpmyfaq to 4.1.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-98gw-w575-h2ph is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

### Summary An unauthenticated attacker can submit a guest FAQ with an email address that is syntactically valid per RFC 5321 (quoted local part) yet contains raw HTML — for example "<script>alert(1)</script>"@evil.com. PHP's FILTER_VALIDATE_EMAIL accepts this email as valid. The email is stored in the database without HTML sanitization and later rendered in the admin FAQ editor template using Twig's |raw filter, which bypasses auto-escaping entirely. ### Details 1. PHP FILTER_VALIDATE_EMAIL accepts RFC-valid quoted local parts with dangerous characters phpmyfaq/src/phpMyFAQ/Controller/Front
O3 Security · Impact-Aware SCA

Is GHSA-98gw-w575-h2ph in your dependencies?

Find it across Packagist, including transitive dependencies.

phpMyFAQ is Vulnerable to Stored XSS via Unsanitized…