phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta have a vulnerability due to lack of effective rate limiting on unauthenticated password update and reset endpoints. This allows attackers to send unlimited password reset requests, potentially flooding a user's inbox and exhausting server mail resources.
phpMyFAQ versions from 4.2.0-alpha.2 up to but not including 4.2.0-beta contain a privilege escalation vulnerability in the group permission API. This flaw allows non-superadmin administrators with GROUP_EDIT rights to escalate privileges by granting themselves unrestricted FAQ create, edit, and publish access across all languages and categories. The vulnerability arises because permission checks do not consider language or category scope, enabling unauthorized broad access.
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 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 prior to 4.1.7 contain a missing authorization vulnerability where parent FAQ visibility checks are not enforced before returning child resources such as comments and attachments. This allows unauthenticated attackers to access restricted comment text, commenter email addresses, and attachment filenames for FAQ entries they cannot directly access.
phpMyFAQ versions before 4.1.7 have an authentication bypass vulnerability due to failure to persist the WebAuthn login challenge. This allows an attacker who captures a valid WebAuthn assertion to replay it indefinitely and authenticate as the user without interaction or hardware key.
phpMyFAQ versions before 4.1.7, when using the native pgsql PHP extension for PostgreSQL, improperly handle wildcard escaping in SQL LIKE queries. This flaw allows unauthenticated attackers to submit wildcard characters in the public FAQ search form, causing broad pattern matches and expensive sequential scans that can lead to denial of service. The issue does not affect the PDO PostgreSQL backend and does not enable SQL injection or data exfiltration.
phpMyFAQ versions before 4.1.7 have a missing authorization vulnerability in the admin API read endpoints related to LDAP, Elasticsearch, OpenSearch, and dashboard configuration. This flaw allows any authenticated user to access sensitive administrative data without proper permission checks. Exploitation can reveal LDAP server topology, bind account names, search bases, index statistics, and site analytics.
phpMyFAQ versions before 4.1.6 have a vulnerability where HTML in FAQ answers is not properly sanitized before generating PDFs using TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag referencing local files under the web root's content/ directory. When the PDF is generated, phpMyFAQ tries to read the referenced file, causing an error that results in an uncaught exception. This exception discloses part of the file's contents in the stack trace to any user triggering the PDF export. The disclosed content is truncated by default but can be configured to reveal entire files, including sensitive data like database credentials.
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.