Skip to main content

PHP CVE-2026-34973

MEDIUM
Improper Neutralization of Special Elements in Data Query Logic (CWE-943)
2026-04-01 https://github.com/thorsten/phpMyFAQ GHSA-gcp9-5jc8-976x
6.9
CVSS 4.0 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
6.9 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

3
Patch released
Apr 02, 2026 - 14:30 nvd
Patch available
Analysis Generated
Apr 02, 2026 - 00:15 vuln.today
CVE Published
Apr 01, 2026 - 23:41 nvd
MEDIUM 6.9

DescriptionGitHub Advisory

Summary

The searchCustomPages() method in phpmyfaq/src/phpMyFAQ/Search.php uses real_escape_string() (via escape()) to sanitize the search term before embedding it in LIKE clauses. However, real_escape_string() does not escape SQL LIKE metacharacters % (match any sequence) and _ (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records - including content that was not meant to be surfaced - resulting in information disclosure.

Details

File: phpmyfaq/src/phpMyFAQ/Search.php, lines 226-240

Vulnerable code:

php
$escapedSearchTerm = $this->configuration->getDb()->escape($searchTerm);
$searchWords = explode(' ', $escapedSearchTerm);
$searchConditions = [];

foreach ($searchWords as $word) {
    if (strlen($word) <= 2) {
        continue;
    }
    $searchConditions[] = sprintf(
        "(page_title LIKE '%%%s%%' OR content LIKE '%%%s%%')",
        $word,
        $word
    );
}

escape() calls mysqli::real_escape_string(), which escapes characters like ', \, NULL, etc. - but explicitly does not escape % or _, as these are not SQL string delimiters. They are, however, LIKE pattern wildcards.

Attack vector:

A user submits a search term containing _ or % as part of a 3+ character word (to bypass the strlen <= 2 filter). Examples:

  • Search for a_b → LIKE becomes '%a_b%'_ matches any single character, e.g. matches "aXb", "a1b", "azb" - broader than the literal string a_b
  • Search for te%t → LIKE becomes '%te%t%' → matches test, text, te12t, etc.
  • Search for _%_ → LIKE becomes '%_%_%' → matches any record with at least one character, effectively dumping all custom pages

This allows an attacker to retrieve custom page content that would not appear in normal exact searches, bypassing intended search scope restrictions.

PoC

  1. Navigate to the phpMyFAQ search page (accessible to unauthenticated users by default).
  2. Submit a search query: _%_ (underscore, percent, underscore - length 3, bypasses the <= 2 filter).
  3. The backend executes: WHERE (page_title LIKE '%_%_%' OR content LIKE '%_%_%')
  4. This matches all custom pages with at least one character in title or content - returning content that would not appear for a specific search term.

Impact

  • Authentication required: None - search is publicly accessible
  • Affected component: searchCustomPages() in Search.php; custom pages (faqcustompages table)
  • Impact: Unauthenticated users can enumerate/disclose all custom page content regardless of the intended search term filter
  • Fix: Escape % and _ in LIKE search terms before interpolation:
php
  $word = str_replace(['\\', '%', '_'], ['\\\\', '\\%', '\\_'], $word);

Or use parameterized queries with properly escaped LIKE values.

AnalysisAI

Information disclosure in phpMyFAQ allows unauthenticated attackers to enumerate custom page content by injecting SQL LIKE wildcards (% and _) into the search term, bypassing intended search filters. The searchCustomPages() method in Search.php uses real_escape_string() which does not escape LIKE metacharacters, enabling an attacker to craft queries like _%_ that match all records regardless of intended search scope. This vulnerability has no authentication requirement and affects the publicly accessible search functionality.

Technical ContextAI

The vulnerability exists in the searchCustomPages() method which constructs SQL LIKE clauses by concatenating user-controlled search terms after escaping via mysqli::real_escape_string() (wrapped in the escape() function). While real_escape_string() properly escapes SQL string delimiters such as single quotes, backslashes, and NULL bytes, it explicitly does not escape the LIKE pattern metacharacters % (wildcard for any sequence of characters) and _ (wildcard for any single character). These characters have special meaning only within LIKE predicates, not in string literals, so the MySQL escaping function omits them. The vulnerable code embeds the insufficiently-escaped search term directly into LIKE clause patterns like '%<term>%', allowing an attacker to inject % or _ to expand the matching scope. The root cause is CWE-943 (Improper Neutralization of Special Elements in Data Query Logic), specifically the failure to apply context-aware escaping for LIKE syntax. Affected product is phpMyFAQ (CPE: pkg:composer/thorsten_phpmyfaq) across all versions where this code pattern exists.

RemediationAI

Apply the vendor-released patch from the phpMyFAQ project as documented in the GitHub security advisory at https://github.com/advisories/GHSA-gcp9-5jc8-976c. The fix requires escaping SQL LIKE metacharacters in search terms before embedding them into LIKE clauses; the recommended approach is to add str_replace(['\', '%', '_'], ['\\', '\%', '\_'], $word) before constructing the LIKE condition, or migrate to parameterized queries with properly escaped LIKE values. Operators should upgrade to the patched phpMyFAQ version indicated in the advisory and verify that custom pages are not exposed through unauthenticated search.

More in PHP

View all
CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

CVE-2024-46506 CRITICAL POC
10.0 May 13

NetAlertX (formerly PiAlert) versions 23.01.14 through 24.x before 24.10.12 allow unauthenticated command injection thro

CVE-2024-8353 CRITICAL POC
9.8 Sep 28

The GiveWP - Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all

Share

CVE-2026-34973 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy