phpMyFAQ versions from 4.2.0-alpha.2 up to but not including 4.2.0-beta contain a privilege escalation vulnerability. The flaw exists in the UserController::updateUserRights function, where language restrictions on user rights are improperly dropped when rights are re-granted. This allows administrators with USER_EDIT privileges to escalate their access by submitting language-scoped rights for themselves, gaining unrestricted create, edit, and publish permissions across all languages.
phpMyFAQ versions 4.1.0 through before 4.1.9 and 4.2.0-alpha through before 4.2.0-beta contain a missing authorization vulnerability in the admin dashboard. Authenticated users without admin rights can access restricted data such as unpublished FAQ questions, admin edit URLs, recent user identities, and site statistics by requesting /admin/index.php/. This vulnerability allows unauthorized data disclosure but does not require elevated privileges beyond an activated account.
phpMyFAQ versions from 4.0.0 up to but not including 4.1.9 contain an incorrect authorization vulnerability. Delegated administrators without the editnews right can modify news items by exploiting a mischeck of permissions in the update API endpoint. This allows attackers with addnews and delnews rights to alter news content displayed on the public front page.
phpMyFAQ versions before 4.1.9 and between 4.2.0-alpha and 4.2.0-beta contain an account enumeration vulnerability. This flaw allows unauthenticated attackers to confirm registered display names and emails by observing distinct HTTP 409 responses when submitting guest comments. The vulnerability can be exploited to link user names to email addresses, facilitating targeted phishing attacks.
phpMyFAQ versions from 4.2.0-alpha.2 up to but not including 4.2.0-beta have a vulnerability in the removeTwofactorConfig() endpoint that lacks brute-force protection. This allows authenticated attackers with a hijacked session and CSRF token to repeatedly guess TOTP codes without limitation and disable the victim's two-factor authentication (2FA).
phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain an authorization vulnerability in the GroupController::deleteGroup() function. This flaw allows authenticated administrators with the GROUP_DELETE privilege, but not SuperAdmin rights, to delete higher-privileged groups by sending a crafted groupId to the /admin/api/group/delete endpoint. This results in permanent deletion of groups and removal of inherited rights from their members.
phpMyFAQ versions before 4.1.9 and between 4.2.0-alpha and 4.2.0-beta allow changing the account email without requiring the current password, relying only on session and CSRF token validation. An attacker who has hijacked a user session can change the email to their own and then use the password reset process to take over accounts that do not have two-factor authentication enabled, including superadmin accounts.
phpMyFAQ versions 3.2.0-alpha up to but not including 4.1.9, and 4.2.0-alpha up to but not including 4.2.0-beta, contain an authentication bypass vulnerability. This flaw allows users authenticated via Identity Providers (IdP) using Keycloak and Entra ID SSO callbacks to bypass TOTP two-factor authentication. Attackers with a valid or phished IdP identity linked to a 2FA-enabled account can complete the OpenID Connect (OIDC) flow and gain a fully authenticated session, including administrator privileges.
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 versions 4.1.0 through 4.1.10 contain a missing authorization vulnerability in the MCP server's faq_search tool. This flaw allows MCP clients to bypass user and group permission checks when performing search queries, enabling unauthorized access to restricted FAQs. The vulnerability arises because the Search::searchDatabase() function does not enforce access controls on the returned FAQ content.
phpMyFAQ versions prior to 4.1.6 contain an SQL injection vulnerability in the StopWords::add() method. This method improperly constructs an SQL INSERT statement by directly embedding user-supplied input without proper escaping. An authenticated administrator with access to the stop-word management feature can exploit this flaw to inject arbitrary SQL commands. The vulnerability is fixed in version 4.1.6.
phpMyFAQ is an open source FAQ web application. Versions 3.2.0 through 4.1.5 contain an authentication bypass in its 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 first authenticating with the account password, allowing takeover of any 2FA-enabled account, including administrator accounts. Version 4.1.6 is patched by binding TOTP verification to a session established after successful password authentication and limiting failed TOTP attempts. No official workaround is documented; affected installations should upgrade to 4.1.6 or later.
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. The vulnerability exists because `html_entity_decode()` converts HTML entities into executable HTML after `strip_tags()` has already passed them through, and the admin template renders the content with Twig's `|raw` filter without any output sanitization. Version 4.2.0-alpha fixes the issue.
phpMyFAQ versions before 4.1.8 contain a stored cross-site scripting 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 4.1.8 contains an authentication bypass vulnerability in its two-factor authentication (TOTP) disable functionality. The removeTwofactorConfig() handler (reachable via POST /api/user/remove-twofactor) verifies only 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. The same downgrade is also reachable inline via PUT /api/user/data/update, which accepts a plain twofactor_enabled form field under the same session+CSRF-only guard. An attacker who has hijacked a user's session can silently strip two-factor protection from any account, including administrator accounts, after which password-only authentication succeeds.
phpMyFAQ versions before 4.2.0-alpha.2 have a missing authorization vulnerability in the admin dashboard API endpoints 'searches' and 'content-health'. These endpoints only enforce authentication but do not check user permissions, allowing any authenticated user to access site-wide search statistics and content-health counters regardless of 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.