phpMyFAQ vulnerabilities

phpMyFAQ is an open source FAQ web application. A stored cross-site scripting (XSS) vulnerability in versions prior to 4.2.0-alpha allows any unauthenticated user (or low-privileged registered user) to inject arbitrary JavaScript that executes in an administrator's browser when they review or edit a user-submitted FAQ entry. This leads to admin account takeover via session theft.

A vulnerability in phpMyFAQ before version 4.1.5 allows unauthenticated attackers to retrieve inactive (draft or review-only) FAQ content due to inconsistent filtering in public API endpoints.

phpMyFAQ before version 4.1.5 contains a path traversal vulnerability in the concatenatePaths() function in Wrapper.php. An authenticated user with FAQ editing privileges can store crafted HTML with image paths that are processed during PDF generation. Lack of path canonicalization and root-directory containment validation may allow reading files outside the intended content directory.

phpMyFAQ before 4.1.3 contains an unauthenticated password reset vulnerability in the user password update API endpoint that allows attackers to change account passwords without token validation.

phpMyFAQ before version 4.1.2 contains a stored cross-site scripting vulnerability in the Utils::parseUrl() function. This allows authenticated users to inject JavaScript via malformed URLs in comments.

phpMyFAQ before version 4.1.2 contains an information disclosure vulnerability in the getIdFromSolutionId() method that lacks permission filtering. This allows unauthenticated attackers to enumerate restricted FAQ entries and read their titles via the /solution_id_{id}.html endpoint.

phpMyFAQ before version 4.1.2 contains a SQL injection vulnerability in CurrentUser::setTokenData that allows authenticated attackers to execute arbitrary SQL by injecting malicious OAuth token claims.

In phpMyFaq before version 2.9.9, there is a CSRF vulnerability in admin/ajax.config.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability that allows modification of a glossary.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability in admin/stat.main.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability in admin/ajax.attachment.php and admin/att.main.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability in admin/news.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability in admin/stat.adminlog.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability in admin/stat.ratings.php.

In phpMyFAQ before version 2.9.9, there is a Cross-Site Request Forgery (CSRF) vulnerability allowing the addition of glossary terms.

phpMyFAQ before version 4.1.6 contains a remote code execution vulnerability in the configuration API. An authenticated administrator with CONFIGURATION_EDIT and ATTACHMENT_ADD privileges can manipulate the upgrade.lastDownloadedPackage setting to write arbitrary PHP files and achieve code execution as the web server user.

phpMyFAQ before version 4.1.2 contains an unauthenticated SQL injection vulnerability in the BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha() methods. Attackers can exploit the public GET /api/captcha endpoint by injecting malicious User-Agent headers, leading to the leakage of sensitive data.

phpMyFAQ before 4.1.2 contains an improper restriction of excessive authentication attempts vulnerability in the /admin/check endpoint, which accepts arbitrary user-id parameters without session binding or rate limiting. Unauthenticated attackers can brute-force any user's six-digit TOTP code by submitting POST requests with sequential token values, bypassing two-factor authentication to gain full administrative access.

phpMyFAQ before 2.9.8 does not properly mitigate brute-force attacks that try many passwords in attempted logins quickly.

phpMyFAQ before 4.1.9 contains an SQL injection vulnerability in PdoMysql::escape(), which escapes single quotes with backslashes that are treated literally when MySQL or MariaDB runs in NO_BACKSLASH_ESCAPES mode. Unauthenticated attackers can send a Unicode right single quotation mark in the search parameter of api/autocomplete, which is normalized to an ASCII quote, to read credentials and configuration secrets, modify records, or drop tables.

phpMyFAQ through 4.1.10 contains a missing authorization vulnerability in the MCP server faq_search tool that allows MCP clients to read restricted FAQs because Search::searchDatabase() never applies user or group permission checks. Attackers connected to the phpmyfaq:mcp:server can issue search queries to retrieve the full question and answer text of active FAQs restricted to specific users or groups.

phpMyFAQ before 4.1.6 has a vulnerability in the StopWords::add() method that builds a SQL INSERT statement using sprintf() and inserts the user-supplied stop word value directly into the query without calling the database escaping function. An authenticated administrator can submit a crafted value that breaks out of the SQL string literal and injects arbitrary SQL, including dropping tables, exfiltrating data, or modifying other rows.

phpMyFAQ before version 4.2.0-alpha is vulnerable to SQL LIKE wildcard injection in the chat user search. An authenticated user can bypass the display-name search filter and enumerate active users, as % and _ are not escaped.

phpMyFAQ versions 3.2.0 through 4.1.5 contain an authentication bypass in the public two-factor authentication verification flow. An unauthenticated attacker can submit an account's numeric user ID and a valid or brute-forced six-digit TOTP code without the password, allowing takeover of any 2FA-enabled account, including administrators. Version 4.1.6 patches the issue by binding TOTP verification to a session established after successful password authentication and limiting failed TOTP attempts.

phpMyFAQ versions before 4.1.8 contain a stored XSS vulnerability in FaqHelper::convertOldInternalLinks() that calls html_entity_decode() on sanitized FAQ content, reversing entity-encoding protection. Authenticated users with FAQ editing privileges can inject JavaScript payloads that execute in the browsers of all users viewing the affected FAQ pages.

phpMyFAQ before 4.1.8 contains an authorization bypass vulnerability in the question creation endpoint where the isAddingQuestionsAllowed() method grants access to all callers when main.enableAskQuestions is enabled, ignoring the records.allowQuestionsForGuests setting. Unauthenticated attackers can submit questions via the question/create API endpoint to bypass guest submission restrictions and inject spam into the admin moderation queue.

phpMyFAQ versions before 4.1.8 contain an authentication bypass vulnerability in the user control panel API endpoint that allows authenticated attackers to change account passwords without verifying the current password. Attackers with session access can submit a PUT request to the user data update endpoint with only a CSRF token to silently change any user's password, including administrators, causing irreversible account takeover and victim lockout.

phpMyFAQ before version 4.1.8 contains an authentication bypass vulnerability in its two-factor authentication (TOTP) disable functionality. The removeTwofactorConfig() handler only verifies that the user is logged in and that a valid CSRF token is supplied, then disables TOTP without requiring password re-entry or a current TOTP code. An attacker who has hijacked a user's session can silently strip two-factor protection from any account, including administrator accounts.

phpMyFAQ before 4.2.0-alpha.2 contains a missing authorization vulnerability in the admin dashboard API endpoints searches and content-health that enforce only authentication without permission checks. Any authenticated user can access these endpoints to read site-wide search statistics and content-health counters regardless of their privilege level.

phpMyFAQ versions before 4.1.8 include live TOTP shared secrets in plaintext within user data export ZIP files. Attackers obtaining exported archives can extract the TOTP seed and generate valid one-time codes to bypass two-factor authentication.

phpMyFAQ before 4.1.8 enforces incorrect permission checks on admin content pages, allowing lesser-privileged editors to read draft and inactive content. Attackers with only add permissions can access news edit and FAQ translate endpoints to view unpublished content invisible to the public.

phpMyFAQ versions before 4.1.8 fail to validate CAPTCHA when the store parameter is set to 'now' in question submission requests. Unauthenticated attackers can bypass CAPTCHA protection and submit unlimited questions directly, causing database pollution and triggering outgoing mail notifications.

phpMyFAQ before 4.1.7 fails to apply parent FAQ visibility checks before returning child resources including comments and attachments. Unauthenticated attackers can retrieve restricted comment text, commenter email addresses, and attachment filenames for FAQ records they cannot directly access by querying the comments and attachments API endpoints.

phpMyFAQ before version 4.1.7 fails to persist the WebAuthn login challenge, allowing an attacker who captures a successful WebAuthn assertion to replay it indefinitely and authenticate as the user without interaction or hardware key.

phpMyFAQ before 4.1.7 contains a brute-force vulnerability in the two-factor authentication step where the failure counter is session-scoped and reset on each successful password re-authentication. Attackers with a valid password can bypass the five-attempt limit by obtaining a fresh session cookie and repeatedly re-authenticating to reset the counter, enabling unbounded TOTP code guessing.

phpMyFAQ before 4.1.7, when configured to use PostgreSQL via the native pgsql PHP extension, declares an incorrect LIKE ESCAPE character ('=') in the Search/Database/Pgsql.php backend while escapeLikeWildcards() escapes user input with the '|' prefix. As a result, wildcard escaping is a no-op and user-supplied % and _ characters remain active LIKE wildcards. An unauthenticated attacker can submit such characters in the public FAQ search form to force maximally broad pattern matches and expensive sequential scans, resulting in a denial of service. The PDO PostgreSQL backend is not affected, and quotes remain escaped so this does not enable quote-breaking SQL injection or data exfiltration.

phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATION_EDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session.

phpMyFAQ before 4.1.6 does not adequately sanitize HTML in FAQ answers before generating PDFs via TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag whose src references a local file under the web root's content/ directory. When the PDF is generated, phpMyFAQ attempts to read the referenced file; because it is not a valid image the resulting error is converted into an uncaught exception whose stack trace discloses part of the file's contents to any user who triggers the PDF export. By default the disclosed portion is truncated, but a larger configured value can result in disclosure of entire files, including database credentials.

phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.

phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the account_status column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7.

phpMyFAQ before 4.1.7 contains a two-factor authentication bypass vulnerability where remember-me tokens are issued before 2FA verification completes. Attackers with valid credentials can obtain a remember-me cookie, skip the 2FA challenge, and replay the cookie to gain full authenticated access without second-factor verification.

phpMyFAQ versions before 4.1.7 fail to validate active status in the PDF export endpoint, allowing unauthenticated attackers to retrieve draft FAQ metadata. Attackers can access the public PDF export route with sequential FAQ identifiers to obtain titles, solution IDs, author names, and last-update timestamps of inactive or unpublished FAQs.

phpMyFAQ before 4.1.7 contains a SQL injection vulnerability in the glossary create and update endpoints caused by truncating an escaped string before embedding it in a SQL literal. Authenticated users with glossary add or edit permissions can craft a payload with a dangling backslash to escape the closing quote and inject arbitrary SQL commands to read sensitive database information.

phpMyFAQ before v4.1.6 writes content backup ZIP archives to the web-accessible document root at content.zip, exposing sensitive files including database credentials. Unauthenticated attackers can race concurrent requests to download the temporary ZIP file before deletion, or exploit XSS in admin contexts to trigger authenticated backups and retrieve the archive.

phpMyFAQ before 4.1.7 contains an authentication bypass vulnerability in SetupController that allows unauthenticated attackers to run database migrations and create configuration backups when maintenance mode is enabled. Attackers can call POST /api/setup/update-database and POST /api/setup/backup endpoints to execute database updates, disable maintenance mode, and extract database credentials from generated ZIP archives.

phpMyFAQ before 4.1.7 stores password reset tokens in a publicly accessible tracking file when user tracking is enabled. Unauthenticated attackers can read the tracking file at content/core/data/trackingDDMMYYYY to extract reset tokens and replay them against the password reset API to take over user accounts.

In phpMyFAQ before version 4.1.6, a privilege escalation vulnerability exists in GroupController::updateMembers(). Administrators with group-management permissions can join privileged groups without verification.

A vulnerability in phpMyFAQ before 4.1.6 fails to validate path traversal sequences in the existing_image field during category updates, allowing authenticated attackers to delete arbitrary files by exploiting insufficient sanitization in Image::delete(). Attackers can delete the database.php configuration file to disable the installation gate and access the public setup wizard to create new superadmin accounts.

phpMyFAQ before version 4.1.5 contains a privilege escalation vulnerability in the user/add API endpoint. It allows delegated administrators (non-SuperAdmin) to create SuperAdmin accounts, leading to full instance takeover.

phpMyFAQ before version 4.1.5 contains a privilege escalation vulnerability in GroupController::updatePermissions that allows GROUP_EDIT administrators to grant arbitrary rights to groups without verifying they hold those rights themselves. A delegated administrator can exploit this by assigning high-value permissions to a group they belong to, inheriting those rights and escalating privileges up to full administrative control.