{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/phpmyfaq--4.1.1/","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/"}],"language":"en","title":"CraftedSignal Threat Feed — PhpMyFAQ \u003c= 4.1.1","version":"https://jsonfeed.org/version/1.1"}