{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/phpmyfaq--4.1.3/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["phpmyfaq \u003c 4.1.3"],"_cs_severities":["high"],"_cs_tags":["authentication-bypass","account-takeover","phpmyfaq","web-application"],"_cs_type":"advisory","_cs_vendors":["phpmyfaq"],"content_html":"\u003cp\u003eA critical authentication bypass vulnerability exists in phpMyFAQ versions prior to 4.1.3. This flaw allows an unauthenticated attacker to reset the password of any user account, including those with SuperAdmin privileges. The vulnerability stems from the lack of proper password reset token verification, rate limiting, and email confirmation in the \u003ccode\u003e/api/user/password/update\u003c/code\u003e endpoint. By crafting a simple PUT request containing a valid username and associated email address, an attacker can trigger the system to generate a new plaintext password and transmit it to the user\u0026rsquo;s email address, effectively granting them complete control over the targeted account. This poses a significant risk to organizations using phpMyFAQ for knowledge management and support purposes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a target phpMyFAQ instance.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a PUT request to \u003ccode\u003e/phpmyfaq/api/user/password/update\u003c/code\u003e with a valid username and incorrect email address to determine if the username exists (username enumeration).\u003c/li\u003e\n\u003cli\u003eIf the response indicates the username exists, the attacker sends another PUT request to \u003ccode\u003e/phpmyfaq/api/user/password/update\u003c/code\u003e with the valid username and associated email address in the JSON body.\u003c/li\u003e\n\u003cli\u003eThe phpMyFAQ application, lacking proper authentication, processes the request without requiring any token verification, rate limiting, or email confirmation.\u003c/li\u003e\n\u003cli\u003eThe application generates a new plaintext password for the specified user account.\u003c/li\u003e\n\u003cli\u003eThe application sends the new plaintext password to the user\u0026rsquo;s email address.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the email containing the new password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new password to log in to the phpMyFAQ application and take complete control of the account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to gain full administrative access to a phpMyFAQ installation. This includes the ability to access and modify sensitive information, such as user data and FAQ content. An attacker can also lock out legitimate users, disrupt service availability, and potentially use the compromised system as a platform for further malicious activities. All phpMyFAQ administrators and end-users are potentially impacted, especially those using default installations. The attack has very low complexity, requiring no special knowledge beyond identifying a valid username and associated email address.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade phpMyFAQ to version 4.1.3 or later to patch the vulnerability as detailed in \u003ca href=\"https://github.com/advisories/GHSA-w9xh-5f39-vq89\"\u003eGHSA-w9xh-5f39-vq89\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect phpMyFAQ Password Reset Exploit\u003c/code\u003e to identify potential exploitation attempts in web server logs.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on the \u003ccode\u003e/api/user/password/update\u003c/code\u003e endpoint to prevent username/email enumeration attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-20T15:50:07Z","date_published":"2026-05-20T15:50:07Z","id":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-account-takeover/","summary":"An authentication bypass vulnerability in phpMyFAQ allows an unauthenticated attacker to reset the password of any user account, including SuperAdmin accounts, by sending a PUT request with a valid username and associated email address to /api/user/password/update, resulting in complete account takeover.","title":"phpMyFAQ Authentication Bypass Allows Account Takeover","url":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-account-takeover/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["phpMyFAQ \u003c 4.1.3"],"_cs_severities":["medium"],"_cs_tags":["phpMyFAQ","password-reset","account-enumeration"],"_cs_type":"advisory","_cs_vendors":["phpMyFAQ"],"content_html":"\u003cp\u003ephpMyFAQ versions prior to 4.1.3 are vulnerable to an unauthenticated password reset vulnerability. The vulnerability resides in the password reset API, which lacks proper authentication and authorization checks. An attacker can exploit this by sending a crafted request to the \u003ccode\u003e/api/index.php/user/password/update\u003c/code\u003e endpoint with a valid username and email combination. Upon receiving this request, the application immediately generates a new password, updates the user\u0026rsquo;s account, and sends the new password to the user\u0026rsquo;s email address. This bypasses the intended password reset flow, allowing attackers to forcibly change passwords without any out-of-band confirmation or token validation. This issue was confirmed in a local Docker deployment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a potential target username and email address.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a PUT request to \u003ccode\u003e/api/index.php/user/password/update\u003c/code\u003e with the target\u0026rsquo;s username and email in the JSON body.\u003c/li\u003e\n\u003cli\u003eThe phpMyFAQ application receives the request at \u003ccode\u003ephpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application checks if the provided username and email combination exists.\u003c/li\u003e\n\u003cli\u003eIf the username and email are valid, the application generates a new password.\u003c/li\u003e\n\u003cli\u003eThe application updates the user\u0026rsquo;s password in the database with the newly generated password.\u003c/li\u003e\n\u003cli\u003eThe application sends the new password to the user\u0026rsquo;s email address.\u003c/li\u003e\n\u003cli\u003eThe attacker has now forced a password reset, effectively locking the user out of their account using the original password.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe unauthenticated password reset vulnerability in phpMyFAQ allows attackers to enumerate valid usernames and email addresses. More critically, it enables attackers to forcibly reset user passwords, leading to account disruption and potential denial of service. An attacker knowing a valid username/email pair can trigger an immediate password change without any confirmation, invalidating the old password. While the attacker might not gain immediate access to the account if they lack access to the email, the forced password reset disrupts the victim\u0026rsquo;s access and could lead to further exploitation if the attacker can intercept the new password.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the provided patch or upgrade to phpMyFAQ version 4.1.3 or later to remediate the vulnerability.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect phpMyFAQ Password Reset Attempt\u003c/code\u003e to monitor for suspicious PUT requests to the password update endpoint.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on the \u003ccode\u003e/api/index.php/user/password/update\u003c/code\u003e endpoint to mitigate brute-force attempts to enumerate valid username/email pairs.\u003c/li\u003e\n\u003cli\u003eChange the password recovery flow to a token-based design as outlined in the source document, generating reset tokens and validating those tokens before resetting the password.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-20T15:47:42Z","date_published":"2026-05-20T15:47:42Z","id":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-password-reset/","summary":"phpMyFAQ versions prior to 4.1.3 are vulnerable to an unauthenticated password reset vulnerability that allows attackers to enumerate valid accounts and forcibly change user passwords by exploiting the password reset API without token validation.","title":"phpMyFAQ Unauthenticated Password Reset Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-password-reset/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["phpMyFAQ \u003c 4.1.3"],"_cs_severities":["high"],"_cs_tags":["phpMyFAQ","IDOR","privilege-escalation","account-takeover"],"_cs_type":"advisory","_cs_vendors":["phpMyFAQ"],"content_html":"\u003cp\u003eAn Insecure Direct Object Reference (IDOR) vulnerability exists in phpMyFAQ versions prior to 4.1.3. The vulnerability is located in the Admin API within the \u003ccode\u003eoverwritePassword()\u003c/code\u003e method, which lacks proper authorization checks. Any authenticated administrator, even those with low privileges (USER_EDIT permission), can change the password of any user account, including the SuperAdmin account (userId=1). By manipulating the \u003ccode\u003euserId\u003c/code\u003e parameter in a PUT request to \u003ccode\u003e/admin/api/user/overwrite-password\u003c/code\u003e, an attacker can escalate their privileges to full SuperAdmin control. This poses a significant risk to organizations with multiple admin users and environments requiring privilege separation or multi-tenancy.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains access to a low-privilege admin account, either through legitimate means or by exploiting a separate vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the \u003ccode\u003eoverwritePassword()\u003c/code\u003e endpoint \u003ccode\u003e/admin/api/user/overwrite-password\u003c/code\u003e and its lack of authorization checks.\u003c/li\u003e\n\u003cli\u003eThe attacker requests a CSRF token from an admin page using \u003ccode\u003ecurl\u003c/code\u003e and \u003ccode\u003egrep\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a PUT request to the \u003ccode\u003e/admin/api/user/overwrite-password\u003c/code\u003e endpoint. The request body includes a JSON payload with the target \u003ccode\u003euserId\u003c/code\u003e set to \u0026lsquo;1\u0026rsquo; (SuperAdmin), a valid CSRF token, and the desired new password for the SuperAdmin account.\u003c/li\u003e\n\u003cli\u003eThe phpMyFAQ application receives the PUT request and, due to the IDOR vulnerability, does not validate whether the requesting admin has permission to modify the target user\u0026rsquo;s password.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eoverwritePassword()\u003c/code\u003e method changes the SuperAdmin\u0026rsquo;s password to the attacker-supplied password.\u003c/li\u003e\n\u003cli\u003eThe attacker logs in as the SuperAdmin using the newly set password.\u003c/li\u003e\n\u003cli\u003eThe attacker now has full control of the phpMyFAQ application and can perform any administrative task.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this IDOR vulnerability allows an attacker to gain complete control of the phpMyFAQ application. This can lead to data breaches, defacement of the FAQ content, and unauthorized modification of system configurations. Organizations with multiple admin users, where not all should have SuperAdmin access, are particularly vulnerable. In multi-tenant environments, this vulnerability could allow an attacker to compromise all tenants managed by the phpMyFAQ instance.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade phpMyFAQ to version 4.1.3 or later to patch the IDOR vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003eDetect phpMyFAQ Admin Password Overwrite\u003c/code\u003e to detect potential exploitation attempts (see below).\u003c/li\u003e\n\u003cli\u003eReview and restrict admin privileges based on the principle of least privilege to limit the impact of potential account compromises.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication for all admin accounts to further mitigate the risk of unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-20T15:47:28Z","date_published":"2026-05-20T15:47:28Z","id":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-idor/","summary":"An IDOR vulnerability in phpMyFAQ's Admin API allows any authenticated administrator to change the password of any user account, including SuperAdmin accounts, without authorization verification, leading to privilege escalation.","title":"phpMyFAQ IDOR Allows Admin Account Takeover","url":"https://feed.craftedsignal.io/briefs/2026-05-phpmyfaq-idor/"}],"language":"en","title":"CraftedSignal Threat Feed — Phpmyfaq \u003c 4.1.3","version":"https://jsonfeed.org/version/1.1"}