PhpMyFAQ — CraftedSignal Threat Feed

phpMyFAQ SQL Injection via Unescaped OAuth Token

hello@craftedsignal.io — Wed, 06 May 2026 20:44:39 +0000

phpMyFAQ version 4.1.1 and earlier contains a SQL injection vulnerability within the CurrentUser::setTokenData() function. This function, responsible for updating user data with OAuth token information, fails to properly sanitize specific fields (refresh_token, access_token, code_verifier, and jwt) extracted from the Azure AD id_token. An attacker with a Microsoft Azure AD account whose display name or custom claim contains SQL metacharacters (e.g., a single quote) can inject arbitrary SQL queries into the phpMyFAQ database. The vulnerability exists because setTokenData() utilizes sprintf for constructing the SQL query without proper escaping, unlike other functions within the same file. Successful exploitation allows an attacker to read, modify, or delete sensitive FAQ data, extract user credentials, and potentially compromise the entire phpMyFAQ installation.

Attack Chain

Attacker registers an Azure AD account and crafts a malicious display name or claim containing SQL injection payloads (e.g., O'Brien or x',(SELECT SLEEP(5)))-- -).
The attacker initiates the OAuth login flow on a phpMyFAQ instance with Azure AD authentication enabled.
The Azure AD authorization endpoint redirects back to the phpMyFAQ instance.
The phpMyFAQ instance requests an access token from Azure AD, receiving a JWT in response.
The JWT contains the attacker’s crafted display name or claim.
phpMyFAQ’s setTokenData() function receives the JWT and extracts the malicious claim without sanitization.
The unsanitized claim is injected into an SQL UPDATE statement, leading to arbitrary SQL execution.
The attacker can then read sensitive data, modify content, or extract password hashes.

Impact

Successful exploitation of this SQL injection vulnerability grants the attacker the ability to execute arbitrary SQL commands on the phpMyFAQ database. This can lead to a full compromise of the application, including unauthorized access to all FAQ data (including restricted entries), modification or deletion of content, and extraction of password hashes and session tokens of all users, including administrators. This can result in significant data breaches and reputational damage.

Recommendation

Deploy the Sigma rule phpMyFAQ SQL Injection Attempt to detect potential exploitation attempts by monitoring for suspicious SQL syntax within JWT claims (logsource: webserver, category: webserver).
Apply the recommended fix provided in the GHSA advisory, which involves escaping all interpolated values using $this->configuration->getDb()->escape() in the setTokenData() function to mitigate the SQL injection vulnerability (reference: GHSA-pm8c-3qq3-72w7).
Upgrade to a patched version of phpMyFAQ that addresses this vulnerability to prevent further exploitation (affected_products: phpMyFAQ <= 4.1.1).

phpMyFAQ Unauthenticated SQL Injection via User-Agent Header

hello@craftedsignal.io — Tue, 09 Jan 2024 12:00:00 +0000

phpMyFAQ versions 4.1.1 and earlier are vulnerable to unauthenticated SQL injection in the BuiltinCaptcha component. The vulnerability stems from the improper handling of the User-Agent header and client IP address in the garbageCollector() and saveCaptcha() methods within phpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php. These methods fail to sanitize user-supplied data before incorporating it into SQL queries, specifically a DELETE and an INSERT statement, respectively. An attacker can inject arbitrary SQL commands by crafting a malicious User-Agent header and sending a GET request to the /api/captcha endpoint. The vulnerability was verified against phpMyFAQ 4.2.0-alpha, demonstrating a significant time difference in response times between clean and injected requests. This issue allows attackers to potentially read sensitive data, manipulate database records, and gain complete control of the phpMyFAQ datastore.

Attack Chain

An unauthenticated attacker crafts a malicious SQL payload.
The attacker injects the payload into the User-Agent header of an HTTP GET request.
The attacker sends the crafted GET request to the /api/captcha endpoint of the phpMyFAQ instance.
The CaptchaController.php processes the request, instantiating the BuiltinCaptcha class.
The BuiltinCaptcha class retrieves the unsanitized User-Agent header.
The getCaptchaImage() method calls both the saveCaptcha() and garbageCollector() methods.
These methods execute the SQL queries with the injected payload, due to the lack of sanitization.
The attacker leverages time-based blind SQL injection to extract sensitive data or manipulate database records.

Impact

Successful exploitation of this vulnerability allows an attacker to perform unauthenticated remote SQL injection against the phpMyFAQ database. In a default installation, this includes the ability to read user credential hashes, the admin token, SMTP credentials, and the content of FAQ entries, including those marked as private or restricted. Attackers can also tamper with or wipe arbitrary rows within the database due to the ability to modify DELETE queries. The absence of authentication, CSRF protection, or rate limiting on the /api/captcha endpoint makes exploitation straightforward.

Recommendation

Apply the recommended fix provided in the advisory by implementing input sanitization using Database::escape() before interpolating values into SQL queries. Specifically, modify phpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php:298-325 and phpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php:330 as described in the advisory.
Audit the entire codebase for instances of sprintf used in conjunction with SQL queries, as suggested by the advisory, to identify and remediate any other potential SQL injection vulnerabilities.
Deploy the provided Sigma rule “phpMyFAQ Captcha API SQL Injection Attempt” to detect attempts to exploit this vulnerability by monitoring for suspicious User-Agent headers in requests to /api/captcha.
Upgrade to a patched version of phpMyFAQ that addresses this vulnerability, if available.

phpMyFAQ Unauthenticated FAQ Permission Bypass via Solution ID Enumeration

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

phpMyFAQ version 4.1.1 and earlier contains a vulnerability that allows unauthenticated users to bypass intended access restrictions on FAQ entries. The vulnerability stems from the /solution_id_{id}.html route, which leverages the getIdFromSolutionId() function lacking proper permission checks. Additionally, the getFaqBySolutionId() function incorporates an explicit fallback mechanism that also bypasses permission filters. By sequentially querying solution IDs, an attacker can discover the existence and titles of FAQs intended for specific user groups or administrators. This affects deployments hosting sensitive internal knowledge alongside public content, impacting the confidentiality of restricted information. The vulnerability was reported on May 6, 2026.

Attack Chain

An unauthenticated attacker sends a GET request to /solution_id_{id}.html, where {id} is a sequentially incremented integer.
The phpMyFAQ server receives the request and calls Faq::getIdFromSolutionId() to retrieve FAQ data.
getIdFromSolutionId() executes an SQL query that joins faqdata and faqcategoryrelations based on solution_id without applying any permission filters.
The server constructs a redirect URL using the retrieved data, including the FAQ’s category ID, record ID, language, and a slugified title derived from the FAQ’s question.
The server responds with a 301 Moved Permanently redirect to the generated URL, exposing the FAQ’s title in the Location header.
The attacker records the 301 responses, extracting the FAQ’s category, ID, language, and title from the Location header.
The attacker repeats steps 1-6, enumerating solution IDs to discover all FAQ entries, including those with restricted access.
The attacker gains knowledge of restricted FAQ titles, compromising confidentiality where titles contain sensitive information about the FAQ’s content.

Impact

Successful exploitation allows any unauthenticated visitor to enumerate all FAQ entries on the phpMyFAQ instance, including those intended for specific groups or users. The attacker can read the title of every restricted FAQ. For deployments that host internal-only content alongside public content (e.g., staff knowledge bases, internal SOPs, confidential customer notes), this leads to a loss of confidentiality. The slugified titles, often encoding the subject directly (e.g., q3-layoff-plan), expose sensitive information.

Recommendation

Apply the recommended fix by adding a permission filter to getIdFromSolutionId() using QueryHelper::queryPermission() (see code snippet in the original advisory) to prevent unauthenticated access.
Remove the unconditional fallback in getFaqBySolutionId() at Faq.php:1256-1265 to ensure permission checks are enforced.
Deploy the Sigma rule “phpMyFAQ Unauthenticated Solution ID Enumeration” to detect attackers enumerating /solution_id_{id}.html to discover restricted FAQ titles.
Monitor web server logs (category: webserver, product: linux) for HTTP 301 responses originating from requests to /solution_id_{id}.html as an indicator of potential exploitation.

phpMyFAQ Unauthenticated 2FA Brute-Force Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

phpMyFAQ versions 4.1.1 and earlier are susceptible to an unauthenticated two-factor authentication (2FA) bypass vulnerability. The vulnerability exists in the /admin/check endpoint, which is intended for validating TOTP codes. Due to the SkipsAuthenticationCheck implementation, this endpoint can be accessed without prior password authentication. An attacker can send POST requests with arbitrary user-id and token values, attempting to brute-force the 6-digit TOTP code. The absence of rate limiting allows an attacker to exhaust the keyspace relatively quickly. Successful exploitation grants a fully authenticated administrative session, enabling complete control over the application. This poses a significant risk to the confidentiality, integrity, and availability of the phpMyFAQ instance and its data.

Attack Chain

Attacker identifies a valid user-id, often starting with common values like 1 for the admin user.
Attacker sends a POST request to /admin/check with a guessed 6-digit TOTP code and the target user-id.
The /admin/check endpoint processes the request without verifying prior password authentication due to the SkipsAuthenticationCheck interface.
The application validates the provided TOTP code against the user ID.
If the TOTP is incorrect, the server redirects to /admin/token?user-id=.
The attacker iterates through possible TOTP codes (000000-999999) in a loop.
Upon successful TOTP validation, twoFactorSuccess() is called, creating an authenticated admin session.
The server redirects to ./, granting the attacker full administrative access to phpMyFAQ. The attacker can now perform actions like user management, data exfiltration, and configuration changes.

Impact

Successful exploitation allows an attacker to bypass 2FA for any user account, including administrators, without knowing the user’s password. This results in full administrative control over the phpMyFAQ instance, potentially leading to unauthorized data access, modification, or deletion. The attacker can manage users, modify FAQ content, change configurations, and access backup/export functions containing all data. Given the ease of exploitation due to the lack of rate limiting, a wide range of phpMyFAQ instances are at risk.

Recommendation

Deploy the Sigma rule “phpMyFAQ Unauthenticated 2FA Brute-Force Attempt” to your SIEM to detect attempts to exploit this vulnerability by monitoring POST requests to /admin/check (logsource: webserver).
Apply a rate limit or account lockout policy on the /admin/check endpoint to prevent brute-force attacks.
Implement session binding in the check() action to ensure that TOTP validation only occurs after successful password authentication, as described in the Recommended Fix section of the overview.
Upgrade to a patched version of phpMyFAQ that addresses this vulnerability, if available.

phpMyFAQ Stored XSS Vulnerability in Comment Rendering

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

phpMyFAQ version 4.1.1 is vulnerable to a stored Cross-Site Scripting (XSS) vulnerability due to improper sanitization of URLs within user comments. An attacker with a registered user account can inject malicious JavaScript code into a comment. This code is then executed when other users, including administrators, view the FAQ or news page containing the comment. The vulnerability stems from the Utils::parseUrl() function, which converts URLs in comments to clickable links without proper HTML escaping, allowing for the injection of arbitrary HTML attributes. This can lead to session cookie theft and full administrative account takeover.

Attack Chain

An attacker registers a user account on the phpMyFAQ instance.
The attacker identifies a FAQ entry or News page where comments are enabled (main.enableCommentEditor = true).
The attacker crafts a malicious URL containing JavaScript code, such as https://www.evil.com/"onmouseover="alert(document.cookie).
The attacker submits the malicious URL as part of a comment on the targeted FAQ entry or News page.
The Utils::parseUrl() function processes the comment, converting the URL into an HTML tag without proper sanitization.

The crafted URL, including the injected JavaScript, is stored in the phpMyFAQ database.

When another user, including an administrator, views the FAQ entry or News page, the malicious JavaScript is executed in their browser.

The attacker steals the user’s session cookie, potentially leading to account takeover, especially if the victim is an administrator.

Impact

Successful exploitation of this stored XSS vulnerability allows an attacker to inject arbitrary JavaScript code into phpMyFAQ pages. This can lead to session cookie theft, potentially resulting in the takeover of user accounts, including administrative accounts. Given the lack of Content-Security-Policy headers, the impact is magnified. This vulnerability affects all visitors to the page with the malicious comment, and the injected code persists until the comment is manually removed.

Recommendation

Upgrade to a patched version of phpMyFAQ that addresses the XSS vulnerability.
Apply HTML escaping to user-supplied URLs when rendering comments to prevent arbitrary HTML injection.
Implement a Content Security Policy (CSP) to restrict the execution of inline JavaScript.
Deploy the Sigma rule Detect phpMyFAQ XSS Payload in Comments to identify potential exploitation attempts (see below).
Monitor web server logs for requests containing the XSS payload https://www.evil.com/"onmouseover="alert(document.cookie) (see IOCs).