{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/phpmyfaq/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["phpMyFAQ \u003c= 4.1.1","Azure AD"],"_cs_severities":["high"],"_cs_tags":["sql-injection","oauth","phpmyfaq"],"_cs_type":"threat","_cs_vendors":["phpMyFAQ","Microsoft"],"content_html":"\u003cp\u003ephpMyFAQ version 4.1.1 and earlier contains a SQL injection vulnerability within the \u003ccode\u003eCurrentUser::setTokenData()\u003c/code\u003e function. This function, responsible for updating user data with OAuth token information, fails to properly sanitize specific fields (\u003ccode\u003erefresh_token\u003c/code\u003e, \u003ccode\u003eaccess_token\u003c/code\u003e, \u003ccode\u003ecode_verifier\u003c/code\u003e, and \u003ccode\u003ejwt\u003c/code\u003e) extracted from the Azure AD \u003ccode\u003eid_token\u003c/code\u003e. 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 \u003ccode\u003esetTokenData()\u003c/code\u003e utilizes \u003ccode\u003esprintf\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker registers an Azure AD account and crafts a malicious display name or claim containing SQL injection payloads (e.g., \u003ccode\u003eO'Brien\u003c/code\u003e or \u003ccode\u003ex',(SELECT SLEEP(5)))-- -\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the OAuth login flow on a phpMyFAQ instance with Azure AD authentication enabled.\u003c/li\u003e\n\u003cli\u003eThe Azure AD authorization endpoint redirects back to the phpMyFAQ instance.\u003c/li\u003e\n\u003cli\u003eThe phpMyFAQ instance requests an access token from Azure AD, receiving a JWT in response.\u003c/li\u003e\n\u003cli\u003eThe JWT contains the attacker\u0026rsquo;s crafted display name or claim.\u003c/li\u003e\n\u003cli\u003ephpMyFAQ\u0026rsquo;s \u003ccode\u003esetTokenData()\u003c/code\u003e function receives the JWT and extracts the malicious claim without sanitization.\u003c/li\u003e\n\u003cli\u003eThe unsanitized claim is injected into an SQL UPDATE statement, leading to arbitrary SQL execution.\u003c/li\u003e\n\u003cli\u003eThe attacker can then read sensitive data, modify content, or extract password hashes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ephpMyFAQ SQL Injection Attempt\u003c/code\u003e to detect potential exploitation attempts by monitoring for suspicious SQL syntax within JWT claims (logsource: \u003ccode\u003ewebserver\u003c/code\u003e, category: \u003ccode\u003ewebserver\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eApply the recommended fix provided in the GHSA advisory, which involves escaping all interpolated values using \u003ccode\u003e$this-\u0026gt;configuration-\u0026gt;getDb()-\u0026gt;escape()\u003c/code\u003e in the \u003ccode\u003esetTokenData()\u003c/code\u003e function to mitigate the SQL injection vulnerability (reference: GHSA-pm8c-3qq3-72w7).\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of phpMyFAQ that addresses this vulnerability to prevent further exploitation (affected_products: \u003ccode\u003ephpMyFAQ \u0026lt;= 4.1.1\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-06T20:44:39Z","date_published":"2026-05-06T20:44:39Z","id":"/briefs/2024-01-phpmyfaq-sqli/","summary":"phpMyFAQ is vulnerable to SQL injection due to the `setTokenData` function failing to sanitize OAuth token fields from Azure AD JWT claims, potentially allowing attackers to execute arbitrary SQL commands via crafted Azure AD display names or custom claims.","title":"phpMyFAQ SQL Injection via Unescaped OAuth Token","url":"https://feed.craftedsignal.io/briefs/2024-01-phpmyfaq-sqli/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["phpMyFAQ"],"_cs_severities":["critical"],"_cs_tags":["sql-injection","unauthenticated","web-application"],"_cs_type":"advisory","_cs_vendors":["phpMyFAQ"],"content_html":"\u003cp\u003ephpMyFAQ 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 \u003ccode\u003egarbageCollector()\u003c/code\u003e and \u003ccode\u003esaveCaptcha()\u003c/code\u003e methods within \u003ccode\u003ephpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php\u003c/code\u003e. 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 \u003ccode\u003e/api/captcha\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker crafts a malicious SQL payload.\u003c/li\u003e\n\u003cli\u003eThe attacker injects the payload into the User-Agent header of an HTTP GET request.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the crafted GET request to the \u003ccode\u003e/api/captcha\u003c/code\u003e endpoint of the phpMyFAQ instance.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eCaptchaController.php\u003c/code\u003e processes the request, instantiating the \u003ccode\u003eBuiltinCaptcha\u003c/code\u003e class.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eBuiltinCaptcha\u003c/code\u003e class retrieves the unsanitized User-Agent header.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003egetCaptchaImage()\u003c/code\u003e method calls both the \u003ccode\u003esaveCaptcha()\u003c/code\u003e and \u003ccode\u003egarbageCollector()\u003c/code\u003e methods.\u003c/li\u003e\n\u003cli\u003eThese methods execute the SQL queries with the injected payload, due to the lack of sanitization.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages time-based blind SQL injection to extract sensitive data or manipulate database records.\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 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 \u003ccode\u003e/api/captcha\u003c/code\u003e endpoint makes exploitation straightforward.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix provided in the advisory by implementing input sanitization using \u003ccode\u003eDatabase::escape()\u003c/code\u003e before interpolating values into SQL queries. Specifically, modify \u003ccode\u003ephpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php:298-325\u003c/code\u003e and \u003ccode\u003ephpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php:330\u003c/code\u003e as described in the advisory.\u003c/li\u003e\n\u003cli\u003eAudit the entire codebase for instances of \u003ccode\u003esprintf\u003c/code\u003e used in conjunction with SQL queries, as suggested by the advisory, to identify and remediate any other potential SQL injection vulnerabilities.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;phpMyFAQ Captcha API SQL Injection Attempt\u0026rdquo; to detect attempts to exploit this vulnerability by monitoring for suspicious User-Agent headers in requests to \u003ccode\u003e/api/captcha\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of phpMyFAQ that addresses this vulnerability, if available.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"/briefs/2024-01-phpmyfaq-sql-injection/","summary":"Unauthenticated SQL injection vulnerability exists in phpMyFAQ \u003c= 4.1.1 due to improper handling of the User-Agent header in BuiltinCaptcha, allowing attackers to inject malicious SQL payloads and potentially gain complete control of the datastore.","title":"phpMyFAQ Unauthenticated SQL Injection via User-Agent Header","url":"https://feed.craftedsignal.io/briefs/2024-01-phpmyfaq-sql-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["phpmyfaq (\u003c= 4.1.1)"],"_cs_severities":["medium"],"_cs_tags":["phpMyFAQ","unauthenticated access","information disclosure","web server"],"_cs_type":"advisory","_cs_vendors":["phpmyfaq"],"content_html":"\u003cp\u003ephpMyFAQ 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 \u003ccode\u003e/solution_id_{id}.html\u003c/code\u003e route, which leverages the \u003ccode\u003egetIdFromSolutionId()\u003c/code\u003e function lacking proper permission checks. Additionally, the \u003ccode\u003egetFaqBySolutionId()\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker sends a GET request to \u003ccode\u003e/solution_id_{id}.html\u003c/code\u003e, where \u003ccode\u003e{id}\u003c/code\u003e is a sequentially incremented integer.\u003c/li\u003e\n\u003cli\u003eThe phpMyFAQ server receives the request and calls \u003ccode\u003eFaq::getIdFromSolutionId()\u003c/code\u003e to retrieve FAQ data.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003egetIdFromSolutionId()\u003c/code\u003e executes an SQL query that joins \u003ccode\u003efaqdata\u003c/code\u003e and \u003ccode\u003efaqcategoryrelations\u003c/code\u003e based on \u003ccode\u003esolution_id\u003c/code\u003e without applying any permission filters.\u003c/li\u003e\n\u003cli\u003eThe server constructs a redirect URL using the retrieved data, including the FAQ\u0026rsquo;s category ID, record ID, language, and a slugified title derived from the FAQ\u0026rsquo;s question.\u003c/li\u003e\n\u003cli\u003eThe server responds with a 301 Moved Permanently redirect to the generated URL, exposing the FAQ\u0026rsquo;s title in the \u003ccode\u003eLocation\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eThe attacker records the 301 responses, extracting the FAQ\u0026rsquo;s category, ID, language, and title from the \u003ccode\u003eLocation\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eThe attacker repeats steps 1-6, enumerating solution IDs to discover all FAQ entries, including those with restricted access.\u003c/li\u003e\n\u003cli\u003eThe attacker gains knowledge of restricted FAQ titles, compromising confidentiality where titles contain sensitive information about the FAQ\u0026rsquo;s content.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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., \u003ccode\u003eq3-layoff-plan\u003c/code\u003e), expose sensitive information.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix by adding a permission filter to \u003ccode\u003egetIdFromSolutionId()\u003c/code\u003e using \u003ccode\u003eQueryHelper::queryPermission()\u003c/code\u003e (see code snippet in the original advisory) to prevent unauthenticated access.\u003c/li\u003e\n\u003cli\u003eRemove the unconditional fallback in \u003ccode\u003egetFaqBySolutionId()\u003c/code\u003e at \u003ccode\u003eFaq.php:1256-1265\u003c/code\u003e to ensure permission checks are enforced.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;phpMyFAQ Unauthenticated Solution ID Enumeration\u0026rdquo; to detect attackers enumerating \u003ccode\u003e/solution_id_{id}.html\u003c/code\u003e to discover restricted FAQ titles.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs (category: webserver, product: linux) for HTTP 301 responses originating from requests to \u003ccode\u003e/solution_id_{id}.html\u003c/code\u003e as an indicator of potential exploitation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-phpmyfaq-unauth-bypass/","summary":"phpMyFAQ version 4.1.1 and earlier is vulnerable to an unauthenticated FAQ permission bypass, allowing attackers to enumerate solution IDs and discover restricted FAQ titles due to missing permission filters in key functions.","title":"phpMyFAQ Unauthenticated FAQ Permission Bypass via Solution ID Enumeration","url":"https://feed.craftedsignal.io/briefs/2024-01-phpmyfaq-unauth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["phpMyFAQ (\u003c= 4.1.1)"],"_cs_severities":["critical"],"_cs_tags":["phpMyFAQ","2FA Bypass","Brute-Force","Authentication"],"_cs_type":"advisory","_cs_vendors":["phpMyFAQ"],"content_html":"\u003cp\u003ephpMyFAQ versions 4.1.1 and earlier are susceptible to an unauthenticated two-factor authentication (2FA) bypass vulnerability. The vulnerability exists in the \u003ccode\u003e/admin/check\u003c/code\u003e endpoint, which is intended for validating TOTP codes. Due to the \u003ccode\u003eSkipsAuthenticationCheck\u003c/code\u003e implementation, this endpoint can be accessed without prior password authentication. An attacker can send POST requests with arbitrary \u003ccode\u003euser-id\u003c/code\u003e and \u003ccode\u003etoken\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a valid \u003ccode\u003euser-id\u003c/code\u003e, often starting with common values like 1 for the admin user.\u003c/li\u003e\n\u003cli\u003eAttacker sends a POST request to \u003ccode\u003e/admin/check\u003c/code\u003e with a guessed 6-digit TOTP code and the target \u003ccode\u003euser-id\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003e/admin/check\u003c/code\u003e endpoint processes the request without verifying prior password authentication due to the \u003ccode\u003eSkipsAuthenticationCheck\u003c/code\u003e interface.\u003c/li\u003e\n\u003cli\u003eThe application validates the provided TOTP code against the user ID.\u003c/li\u003e\n\u003cli\u003eIf the TOTP is incorrect, the server redirects to \u003ccode\u003e/admin/token?user-id=\u0026lt;user_id\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker iterates through possible TOTP codes (000000-999999) in a loop.\u003c/li\u003e\n\u003cli\u003eUpon successful TOTP validation, \u003ccode\u003etwoFactorSuccess()\u003c/code\u003e is called, creating an authenticated admin session.\u003c/li\u003e\n\u003cli\u003eThe server redirects to \u003ccode\u003e./\u003c/code\u003e, granting the attacker full administrative access to phpMyFAQ. The attacker can now perform actions like user management, data exfiltration, and configuration changes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows an attacker to bypass 2FA for any user account, including administrators, without knowing the user\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;phpMyFAQ Unauthenticated 2FA Brute-Force Attempt\u0026rdquo; to your SIEM to detect attempts to exploit this vulnerability by monitoring POST requests to \u003ccode\u003e/admin/check\u003c/code\u003e (logsource: webserver).\u003c/li\u003e\n\u003cli\u003eApply a rate limit or account lockout policy on the \u003ccode\u003e/admin/check\u003c/code\u003e endpoint to prevent brute-force attacks.\u003c/li\u003e\n\u003cli\u003eImplement session binding in the \u003ccode\u003echeck()\u003c/code\u003e action to ensure that TOTP validation only occurs after successful password authentication, as described in the Recommended Fix section of the overview.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of phpMyFAQ that addresses this vulnerability, if available.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-phpmyfaq-2fa-bypass/","summary":"phpMyFAQ is vulnerable to an unauthenticated 2FA brute-force attack via the `/admin/check` endpoint, allowing attackers to bypass two-factor authentication and gain administrative access.","title":"phpMyFAQ Unauthenticated 2FA Brute-Force Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-phpmyfaq-2fa-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["phpMyFAQ 4.1.1"],"_cs_severities":["high"],"_cs_tags":["xss","phpmyfaq","stored-xss"],"_cs_type":"advisory","_cs_vendors":["phpMyFAQ"],"content_html":"\u003cp\u003ephpMyFAQ 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 \u003ccode\u003eUtils::parseUrl()\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker registers a user account on the phpMyFAQ instance.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a FAQ entry or News page where comments are enabled (\u003ccode\u003emain.enableCommentEditor = true\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL containing JavaScript code, such as \u003ccode\u003ehttps://www.evil.com/\u0026quot;onmouseover=\u0026quot;alert(document.cookie)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker submits the malicious URL as part of a comment on the targeted FAQ entry or News page.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eUtils::parseUrl()\u003c/code\u003e function processes the comment, converting the URL into an HTML \u003ccode\u003e\u0026lt;a\u0026gt;\u003c/code\u003e tag without proper sanitization.\u003c/li\u003e\n\u003cli\u003eThe crafted URL, including the injected JavaScript, is stored in the phpMyFAQ database.\u003c/li\u003e\n\u003cli\u003eWhen another user, including an administrator, views the FAQ entry or News page, the malicious JavaScript is executed in their browser.\u003c/li\u003e\n\u003cli\u003eThe attacker steals the user\u0026rsquo;s session cookie, potentially leading to account takeover, especially if the victim is an administrator.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of phpMyFAQ that addresses the XSS vulnerability.\u003c/li\u003e\n\u003cli\u003eApply HTML escaping to user-supplied URLs when rendering comments to prevent arbitrary HTML injection.\u003c/li\u003e\n\u003cli\u003eImplement a Content Security Policy (CSP) to restrict the execution of inline JavaScript.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect phpMyFAQ XSS Payload in Comments\u003c/code\u003e to identify potential exploitation attempts (see below).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for requests containing the XSS payload \u003ccode\u003ehttps://www.evil.com/\u0026quot;onmouseover=\u0026quot;alert(document.cookie)\u003c/code\u003e (see IOCs).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-phpmyfaq-xss/","summary":"A stored XSS vulnerability in phpMyFAQ version 4.1.1 allows an authenticated user to inject JavaScript code into comments, leading to session cookie theft and potential admin account takeover when other users view the affected FAQ or News page.","title":"phpMyFAQ Stored XSS Vulnerability in Comment Rendering","url":"https://feed.craftedsignal.io/briefs/2024-01-02-phpmyfaq-xss/"}],"language":"en","title":"CraftedSignal Threat Feed — PhpMyFAQ","version":"https://jsonfeed.org/version/1.1"}