phpMyFAQ vulnerabilities

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.

phpMyFAQ before 4.1.4 contains missing authorization vulnerabilities in editUser() and updateUserRights() endpoints that allow authenticated administrators to escalate privileges. Non-SuperAdmin users with edit_user permission can set is_superadmin flag or grant arbitrary rights to escalate to SuperAdmin access.

phpMyFAQ prior to version 4.1.4 uses SHA-1 for hashing attachment passwords. SHA-1 is cryptographically broken and vulnerable to collision attacks since 2017.

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 4.1.2 contains a missing authorization vulnerability in the DELETE /admin/api/content/tags/{tagId} endpoint that allows any authenticated user, including regular frontend users, to delete arbitrary tags, resulting in permanent data loss.

phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in FAQ creation and update endpoints that bypasses sanitization through encode-decode cycles. An authenticated attacker with FAQ_ADD permission can inject malicious script tags via question or answer parameters, which execute in every visitor's browser when FAQ content is rendered with the raw Twig filter.

phpMyFAQ before 4.1.2 contains a stored XSS vulnerability in search.twig where result.question and result.answerPreview are rendered with the raw filter, disabling autoescape. Attackers with FAQ editor privileges can inject HTML-entity-encoded payloads that bypass html_entity_decode(strip_tags()) processing in SearchController.php, executing arbitrary JavaScript in every visitor's browser, including administrators.

phpMyFAQ before 4.1.2 contains a stored cross-site scripting vulnerability in SvgSanitizer::decodeAllEntities() that limits recursive entity decoding to 5 iterations, allowing attackers to bypass sanitization. Authenticated users with FAQ_EDIT permission can upload malicious SVG files with deeply nested ampersand encoding around numeric HTML entities to reconstruct javascript: URLs, which execute arbitrary JavaScript when clicked by other users viewing the uploaded SVG.

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.

phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that only checks login status instead of backend privileges. Authenticated ordinary users can access sensitive backend operational information such as dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.

phpMyFAQ before 4.1.2 contains a path traversal vulnerability in Client::deleteClientFolder that allows admins with INSTANCE_DELETE permission to delete arbitrary directories. Attackers can submit traversal sequences like https://../../../<path> in the client URL parameter to recursively delete directories outside the intended clientFolder scope.

phpMyFAQ before 4.1.2 contains missing permission checks in ConfigurationTabController.php where 12 endpoints use userIsAuthenticated() instead of userHasPermission(CONFIGURATION_EDIT). Any authenticated user can enumerate system configuration metadata including permission model, cache backend, mail provider, and translation provider, violating least privilege.

phpMyFAQ before version 4.1.1 contains an XSS vulnerability in the regex-based SVG sanitizer. Attackers with edit_faq permission can upload a malicious SVG that uses HTML entity encoding in javascript: URLs within <a href> attributes, leading to arbitrary JavaScript execution and privilege escalation to full admin takeover.

An information disclosure vulnerability was found in phpMyFAQ prior to version 4.1.1 in the searchCustomPages() method. The escape() function uses real_escape_string(), which does not escape LIKE metacharacters (% and _), allowing an unauthenticated attacker to inject these characters and read unintended records.

phpMyFAQ prior to version 4.1.1 contains a stored XSS vulnerability via Regex Bypass in Filter::removeAttributes(). This issue has been patched in version 4.1.1.

phpMyFAQ prior to 4.1.1 allows an unauthenticated attacker to submit a guest FAQ with an RFC 5321-valid email address (quoted local part) containing raw HTML, such as "<script>alert(1)</script>"@evil.com. FILTER_VALIDATE_EMAIL accepts it, the email is stored without sanitization, and it is rendered in the admin FAQ editor using Twig's |raw filter, bypassing auto-escaping. This is patched in 4.1.1.

phpMyFAQ prior to version 4.0.16 allows an unauthenticated attacker to trigger generation of a configuration backup ZIP via POST /api/setup/backup and then download it from a web-accessible location. The ZIP contains sensitive configuration files, including database credentials.

phpMyFAQ versions 4.0.14 and 4.0.15 have a stored cross-site scripting (XSS) vulnerability that allows an attacker to execute arbitrary JavaScript in an administrator's browser by registering a user whose display name contains HTML entities. When an administrator views the admin user list, the payload is decoded server-side and rendered without escaping, resulting in script execution in the admin context. Version 4.0.16 contains a patch for the issue.

phpMyFAQ is an open source FAQ web application. Prior to version 4.0.14, an authenticated SQL injection vulnerability in the main configuration update functionality of phpMyFAQ allows a privileged user with 'Configuration Edit' permissions to execute arbitrary SQL commands.

phpMyFAQ versions 4.0-nightly-2025-10-03 and below do not enforce uniqueness of email addresses during user registration, allowing multiple accounts with the same email. This can cause account ambiguity and, in certain configurations, may lead to privilege escalation or account takeover. The issue is fixed in version 4.0.13.