Phpmyfaq

Weak cryptographic hashing of attachment passwords in phpMyFAQ prior to 4.1.4 exposes protected attachment credentials to offline cracking or collision-based forgery. The application stored SHA-1 hashes of per-attachment passwords in the database column `password_hash`, computed via `sha1((string) $key)` in `AbstractAttachment::setKey()`. Because SHA-1 has been cryptographically broken since the 2017 SHAttered collision attack, an attacker who obtains these database-stored hashes faces significantly weakened resistance compared to a modern algorithm. No active exploitation is confirmed (CISA KEV: no; exploit status E:U per CVSS 4.0), and the CVSS 4.0 base score of 2.7 reflects limited real-world impact.

Authentication bypass in phpMyFAQ before 4.1.3 lets any unauthenticated remote attacker reset arbitrary user passwords - including SuperAdmin - by sending a PUT request to /api/user/password/update with only a valid username/email pair, with no token, rate limit, or out-of-band confirmation. The vendor-issued GHSA-w9xh-5f39-vq89 advisory and VulnCheck disclosure document the flaw, and publicly available exploit code exists in the form of a PoC curl invocation; no CISA KEV listing or EPSS score is provided in the input.

Authentication bypass in phpMyFAQ versions prior to 4.1.3 lets remote unauthenticated attackers create and modify FAQ entries, categories, and questions through the REST API v4.0 by submitting an empty x-pmf-token header that matches the default empty api.apiClientToken value. The flaw stems from strict string comparison logic that cannot distinguish an unconfigured token from an attacker-supplied empty one, exposing every default installation. No public exploit identified at time of analysis, but the GHSA advisory includes a detailed proof-of-concept walkthrough.

Privilege escalation in phpMyFAQ before 4.1.3 allows any authenticated low-privilege administrator to take over SuperAdmin (userId=1) or any other account by manipulating the userId parameter in the /admin/api/user/overwrite-password PUT request. The flaw is an insecure direct object reference (IDOR) in the Admin API where authorization checks confirm only that the caller holds the generic USER_EDIT permission, never that the caller is authorized to manage the targeted account. No public exploit identified at time of analysis, but the GHSA advisory from the vendor (thorsten) publicly documents the exact vulnerable code path, making weaponization trivial.

Stored cross-site scripting in phpMyFAQ 4.1.1 lets any authenticated user with a registered account persist JavaScript inside FAQ or News comments by submitting a URL containing an unescaped double quote, which Utils::parseUrl() injects unescaped into an href attribute. Payloads execute for every visitor - including admins viewing the comments panel - enabling session cookie theft and full application takeover. Publicly available exploit code exists in the GHSA advisory, though EPSS is only 0.01% and SSVC categorizes exploitation as POC rather than active.

{tagId} endpoint. The vulnerability affects versions before 4.1.2 and stems from missing authorization checks that allow any logged-in user, including regular frontend users, to permanently delete arbitrary tags using only a valid session cookie. While CVSS rates this 5.4 (Medium), the permanent data loss and FAQ organization disruption represent material operational impact. No active exploitation confirmed (not in CISA KEV), but publicly available exploit code exists per VulnCheck advisory and GitHub security advisory GHSA-7cx3-2qx2-3g6w, lowering exploitation barriers for authenticated attackers.

Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and SMTP secrets by sending a crafted User-Agent header to the public GET /api/captcha endpoint. The flaw sits in BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha(), which interpolate the header into DELETE and INSERT statements via sprintf with no escaping. No public exploit identified at time of analysis, though VulnCheck has published a detailed reachability writeup and a verified time-based blind PoC payload appears in the GHSA advisory.

Stored cross-site scripting in phpMyFAQ versions prior to 4.1.2 allows authenticated users with FAQ_ADD permission to inject malicious JavaScript into FAQ questions and answers that execute in all visitors' browsers. The vulnerability exploits an encode-decode cycle where FILTER_SANITIZE_SPECIAL_CHARS encoding is immediately reversed by html_entity_decode(), bypassing Filter::removeAttributes() which only strips HTML attributes but not tags like <script>. Twig templates render this content with the |raw filter, executing stored payloads. CVSS 5.4 indicates network-accessible attack requiring low-privilege authentication and user interaction, with changed scope enabling cross-user impact. EPSS data not provided; no CISA KEV listing indicates no confirmed widespread exploitation at time of analysis.

Authorization bypass in phpMyFAQ versions prior to 4.1.2 allows any authenticated administrative user to access all permission-protected admin pages, regardless of their assigned privileges. The flaw resides in AbstractAdministrationController::userHasPermission() which sends a forbidden response but fails to terminate execution, leaking admin logs, user data, system information, and configuration. Publicly available exploit details exist via the GHSA advisory, though EPSS exploitation probability remains very low at 0.04%.

Authenticated users with FAQ_EDIT permission in phpMyFAQ can bypass SVG sanitization and execute arbitrary JavaScript in victims' browsers by exploiting recursive entity decoding limits. By nesting ampersand encoding five levels deep around numeric HTML entities in SVG href attributes (e.g., &amp;amp;amp;amp;amp;#106; for 'j'), attackers reconstruct javascript: URLs that the decodeAllEntities() method fails to detect but browsers fully decode. The malicious SVG uploads persist on the server and execute JavaScript when other users click the embedded links. Fixed in version 4.1.2. EPSS and KEV data not available; VulnCheck reported this issue with vendor-confirmed details and proof-of-concept in GitHub security advisory GHSA-whqh-9pq5-c7r3.

Two-factor authentication bypass in phpMyFAQ before 4.1.2 lets unauthenticated remote attackers brute-force any administrator's six-digit TOTP code by submitting sequential POST requests to the /admin/check endpoint, which lacks session binding and rate limiting. CVSS 4.0 scores this 9.3 with no public exploit identified at time of analysis, though a proof-of-concept is described in the GHSA advisory and SSVC marks exploitation as 'poc' with total technical impact. EPSS is low at 0.12%, reflecting limited observed scanning despite the trivial 10^6 keyspace exhaustible in minutes.

Arbitrary directory deletion in phpMyFAQ before 4.1.2 allows authenticated admins with the INSTANCE_DELETE permission to recursively delete directories outside the multisite clientFolder by submitting path traversal sequences in the client URL parameter. The flaw stems from Client::deleteClientFolder() stripping only the https:// scheme without canonicalizing or validating ../ segments before passing the path to Filesystem::deleteDirectory(). Publicly available exploit code exists (VulnCheck advisory and GHSA write-up include a PoC), though EPSS remains low at 0.04% and the issue is not listed in CISA KEV.

Unauthenticated account creation in phpMyFAQ versions before 4.0.18 allows remote attackers to register unlimited user accounts through the WebAuthn prepare endpoint without authentication, CSRF protection, or captcha validation, even when registration is disabled. Public exploit code exists for this vulnerability. Update to version 4.0.18 or later to remediate.

Insufficient access controls in phpMyFAQ 4.0.16 and below expose sensitive information including user email addresses and non-public content through multiple API endpoints, allowing unauthenticated attackers to harvest data for phishing or access private records. Public exploit code exists for this vulnerability, and no patch is currently available. Upgrading to version 4.0.17 or later is required to remediate the exposure.

Authenticated users in phpMyFAQ 4.0.16 and below can bypass permission checks to download FAQ attachments they should not have access to, due to improper validation of authorization tokens in attachment.php and flawed permission logic. An attacker with valid credentials but without the dlattachment permission can exploit this to retrieve sensitive attachment content. Public exploit code exists for this vulnerability, and no patch is currently available.

phpMyFAQ versions 4.0.16 and below allow authenticated users to access the backup API endpoint without proper authorization checks, enabling them to download configuration files containing sensitive data. The vulnerability stems from incomplete authorization validation in SetupController.php, which only verifies authentication rather than admin permissions. Public exploit code exists for this issue, and no patch is currently available.

phpMyFAQ is an open source FAQ web application. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.

phpMyFAQ is an open source FAQ web application. Versions 4.0-nightly-2025-10-03 and below do not enforce uniqueness of email addresses during user registration. This allows multiple distinct accounts to be created with the same email. Because email is often used as an identifier for password resets, notifications, and administrative actions, this flaw can cause account ambiguity and, in certain configurations, may lead to privilege escalation or account takeover. This issue is fixed in version 4.0.13.

phpMyFAQ is an open source FAQ web application. Rated medium severity (CVSS 5.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.