CVE-2026-76212: phpMyFAQ PostgreSQL DoS Vulnerability

CVE-2026-76212 Overview

CVE-2026-76212 affects phpMyFAQ versions before 4.1.7 when configured with PostgreSQL through the native pgsql PHP extension. The Search/Database/Pgsql.php backend declares an incorrect LIKE ESCAPE character (=) while escapeLikeWildcards() prefixes user input with |. This mismatch renders wildcard escaping a no-op, leaving % and _ characters active as LIKE wildcards in user input. An unauthenticated attacker can submit these characters through the public FAQ search form to trigger broad pattern matches and expensive sequential scans, resulting in denial of service. Quote escaping remains intact, so the flaw does not enable SQL injection or data exfiltration.

Critical Impact

Unauthenticated remote attackers can degrade or exhaust database resources on phpMyFAQ instances backed by native pgsql by submitting crafted wildcard queries to the public search form.

Affected Products

• phpMyFAQ versions before 4.1.7
• Deployments using the native pgsql PHP extension for PostgreSQL
• Public FAQ search endpoint exposed without authentication

Discovery Timeline

• 2026-08-19 - CVE-2026-76212 published to NVD
• 2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-76212

Vulnerability Analysis

The vulnerability stems from an argument injection weakness [CWE-88] in phpMyFAQ's PostgreSQL search backend. The escapeLikeWildcards() function prepends the pipe character (|) to % and _ characters supplied by users. However, the generated SQL query declares ESCAPE '=' rather than ESCAPE '|'. PostgreSQL therefore treats the | prefix as literal input and processes the following % or _ as active wildcards.

An attacker abuses this mismatch by submitting search terms rich in wildcard characters. PostgreSQL cannot use index-based lookups for unanchored LIKE patterns of this form and falls back to sequential scans across the FAQ tables. Repeated requests amplify CPU and I/O consumption on the database server, degrading service for legitimate users.

The PDO PostgreSQL backend correctly aligns escape declarations and is not affected. Quote characters remain properly escaped, so the flaw does not permit quote-breaking SQL injection or unauthorized data retrieval. Impact is confined to availability of the search functionality and the underlying database.

Root Cause

The defect is a single-character inconsistency between the escape prefix applied in application code (|) and the ESCAPE clause declared in the SQL string (=). Because PostgreSQL honors the declared escape character, the sanitizer never neutralizes wildcards. Any input containing % or _ reaches the query engine as an active pattern operator.

Attack Vector

The attack requires no authentication and no user interaction. An attacker sends HTTP requests to the public phpMyFAQ search form with query strings such as %_%_%_%_%_%. Each request forces PostgreSQL into wide-ranging pattern evaluation across indexed text columns. Concurrent requests multiply resource consumption and can render the FAQ instance unresponsive.

Exploitation details are described in the GitHub Security Advisory and the VulnCheck Advisory. No verified proof-of-concept code is published at this time.

Detection Methods for CVE-2026-76212

Indicators of Compromise

• Search requests to phpMyFAQ containing repeated % or _ characters in the query parameter
• Sustained PostgreSQL sequential scans on FAQ content tables correlated with search traffic
• Elevated database CPU and I/O usage tied to the phpMyFAQ backend user
• HTTP access logs showing bursts of anonymous requests to the public search endpoint

Detection Strategies

• Inspect web server logs for search parameters containing three or more wildcard characters in sequence
• Enable PostgreSQL log_min_duration_statement to capture long-running LIKE queries against FAQ tables
• Correlate slow query logs with source IPs hitting the /search endpoint to identify abuse patterns
• Baseline normal search latency and alert on sustained deviations from that baseline

Monitoring Recommendations

• Instrument the phpMyFAQ search endpoint with rate-limit counters and log rejected requests
• Track PostgreSQL wait events and sequential scan counts per relation for the FAQ schema
• Forward web and database logs to a centralized platform for correlation and retention
• Alert on repeated identical or near-identical wildcard-heavy search payloads from single sources

How to Mitigate CVE-2026-76212

Immediate Actions Required

• Upgrade phpMyFAQ to version 4.1.7 or later
• Audit deployment configuration to confirm which PostgreSQL driver is in use
• Apply request rate limiting to the public search endpoint at the reverse proxy or WAF
• Review database resource limits for the phpMyFAQ role to contain runaway queries

Patch Information

phpMyFAQ 4.1.7 corrects the ESCAPE clause in Search/Database/Pgsql.php so the declared escape character matches the | prefix applied by escapeLikeWildcards(). Administrators should follow upgrade instructions in the GitHub Security Advisory. Verify the fix by inspecting the generated SQL to confirm ESCAPE '|' is present.

Workarounds

• Switch the phpMyFAQ database configuration from the native pgsql extension to the PDO PostgreSQL driver, which is not affected
• Deploy a WAF rule that strips or rejects search inputs containing excessive % or _ characters
• Enforce PostgreSQL statement_timeout on the phpMyFAQ database role to bound query runtime
• Restrict access to the search endpoint behind authentication where the FAQ content permits

# Example PostgreSQL statement timeout for the phpMyFAQ role
ALTER ROLE phpmyfaq SET statement_timeout = '5s';