CVE-2026-76212

Executive Summary

CVE-2026-76212 is a denial-of-service (DoS) vulnerability in phpMyFAQ versions prior to 4.1.7, specifically affecting deployments that use the native PostgreSQL PHP extension (pgsql) for database connectivity. The flaw stems from a mismatch between the declared LIKE escape character and the character actually used to escape wildcard characters in search queries, rendering wildcard escaping ineffective. An unauthenticated attacker can submit crafted % and _ characters through the public FAQ search form, forcing broad pattern matches that trigger expensive sequential scans on the database, potentially exhausting database and application resources. The vulnerability has a CVSS score of 5.3 (Medium), is rated at a low likelihood of exploitation per EPSS (0.00299), and is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog.

Technical Analysis

The vulnerability resides in the interaction between two components of the phpMyFAQ search functionality when configured to use PostgreSQL via the native pgsql PHP extension.

Vulnerability Mechanism:

The NVD description identifies the root cause as a configuration mismatch in the PostgreSQL search backend file located at Search/Database/Pgsql.php. The backend declares an incorrect LIKE escape character (=) for SQL queries issued to PostgreSQL. However, the escapeLikeWildcards() function — responsible for sanitizing user-controlled search input — escapes wildcard characters using the | (pipe) prefix.

In SQL, the LIKE operator supports wildcard characters:

• % — matches zero or more characters
• _ — matches exactly one character

To treat these characters literally, SQL provides an ESCAPE clause (e.g., LIKE 'pattern' ESCAPE '|'), which tells the database which character to interpret as the escape prefix. When user input contains % or _, the application must prefix them with the escape character so the database treats them as literals rather than wildcards.

In this vulnerable configuration:

1. The application escapes user input by prefixing % and _ with | (e.g., user input 50% becomes 50|%).
2. The SQL query declares ESCAPE '=' — but = never appears in the user input.
3. Because | is not declared as the escape character, PostgreSQL treats | as a literal part of the pattern and %/_ remain active wildcards.

The result: escapeLikeWildcards() is effectively a no-op. User-controlled % and _ characters pass through into the LIKE pattern unescaped and fully functional.

Attack Surface:

The attack surface is the public FAQ search form. phpMyFAQ is a web-based FAQ management system; the search functionality is typically accessible to unauthenticated visitors. The attacker does not need valid credentials, session cookies, or any prior access. The attack is conducted entirely over HTTP GET/POST requests to the search endpoint.

Resource Exhaustion Vector:

PostgreSQL's query planner typically attempts to use indexes for LIKE patterns with anchored prefixes (e.g., foo%). However, when a pattern begins with a wildcard (e.g., %foo%), index scan strategies become inapplicable for B-tree indexes, and the database must fall back to a sequential scan of the entire table. By submitting patterns composed solely or largely of wildcard characters (e.g., %%%%% or a%o%i%e%), the attacker can force:

• Full table scans on the FAQ content tables
• Expensive pattern-matching operations across all rows
• Excessive CPU consumption on the PostgreSQL server
• Saturated database connections for the duration of each query

Repeated requests amplify the effect, potentially exhausting database connection pools, consuming memory, and starving legitimate queries.

Non-Affected Configurations:

• The PDO PostgreSQL backend is explicitly not affected, meaning deployments using pdo_pgsql are safe.
• MySQL, MariaDB, SQLite, and MS SQL Server backends are not implicated by this CVE's description.
• The NVD description states that quotes remain properly escaped; therefore, this flaw does not enable quote-breaking SQL injection or data exfiltration. The impact is strictly availability.

Exploitation Scenarios

Scenario 1: Unauthenticated Denial of Service via Wildcard Flooding

Step 1 — Reconnaissance: The attacker identifies a phpMyFAQ instance. This can be done via search engine dorking (e.g., searching for "Powered by phpMyFAQ"), Shodan queries for the application's distinctive HTML signatures, or by guessing common CMS paths. The attacker may fingerprint the database backend by observing error messages (if verbose errors are enabled) or by default configuration documentation, or simply by targeting versions known to be before 4.1.7.

Step 2 — Triggering the Flaw: The attacker navigates to the public FAQ search form. No authentication is required. The form accepts a free-text search query parameter. Critically, no access control or rate limiting is described for this endpoint.

Step 3 — Payload Execution at the Vulnerability-Class Level: The attacker submits a search string composed of repeated % and _ wildcard characters (e.g., %%%% or a pattern like %a%b%c%). Because the LIKE escape is misconfigured (declared as = while the application escapes with |), these characters are transmitted verbatim into the PostgreSQL LIKE pattern. The resulting SQL query performs a maximally broad pattern match. Since the pattern begins with a wildcard, PostgreSQL's query planner cannot use any B-tree index, forcing a sequential scan across the FAQ tables.

Step 4 — Post-Exploitation Impact: Each such query consumes significant database CPU and I/O. By issuing repeated requests — either manually, via a script, or from a botnet — the attacker can create a sustained load. Depending on the FAQ table size and database server capacity, this can:

• Slow legitimate search responses to a crawl
• Exhaust the PostgreSQL connection pool, denying service to all users
• Potentially crash the database process under extreme load (though not confirmed)

Scenario 2: Slow Application Response / Cascading Failure

The attacker sends low-and-slow requests with a moderate wildcard payload to avoid triggering simple rate-limit thresholds, while still causing high per-query cost. If the application uses a limited connection pool, even a handful of concurrent malicious queries can occupy all connections, blocking legitimate users from any database-backed operation (including browsing FAQ categories, not just search).

Scenario 3: No Public Exploit Code — Inferred Attack Chain

Note: The data indicates a public PoC exists, but no exploit code is available, and no Nuclei template has been published. The attack chain described above is inferred from the vulnerability class (wildcard escape bypass in LIKE queries) and the NVD description. The simplicity of the exploit — submitting a URL-encoded % and _ — means even a minimally skilled attacker can implement it from the CVE description alone.

Impact Assessment

Business Impact:

This is a medium-severity availability issue (CVSS 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L). The key characteristics:

• Confidentiality Impact: None — The NVD description explicitly states that quotes remain escaped; there is no SQL injection or data exfiltration path.
• Integrity Impact: None — No data modification is possible through this flaw.
• Availability Impact: Low (per CVSS sub-score) — CVSS rates the availability impact as Low, suggesting a limited but measurable degradation. However, the practical impact scales with the size of the FAQ database and the volume of malicious requests.

Affected Systems:

• phpMyFAQ versions before 4.1.7
• Must be configured with the native pgsql PHP extension (not PDO)
• The application must expose the public search form
• The PostgreSQL table containing FAQ articles must be of sufficient size for sequential scans to become costly

Blast Radius:

• Directly affected: the phpMyFAQ application instance and its associated PostgreSQL server
• Indirectly affected: end users who rely on the FAQ for product support, self-service troubleshooting, or documentation access — an outage degrades user experience and may increase support ticket volume
• No downstream supply-chain impact; this is a standalone web application vulnerability

Exploitation Likelihood:

• EPSS score: 0.00299 (22.0% percentile) — low probability of exploitation in the wild
• Not on CISA KEV — no confirmed active exploitation
• Public PoC exists but no full exploit code published, indicating a moderate barrier for script kiddies but trivial for a competent attacker

Detection Guidance

The following detection content targets different telemetry sources. Since this is a server-side vulnerability triggered by HTTP requests, detection should focus on anomalous search patterns and the resulting database load.

Sigma Rule

title: phpMyFAQ Wildcard Search Flood - Potential DoS (CVE-2026-76212)
id: c8d9e2a1-5b6f-4c3e-9a80-2f1b6a5d4e3c
status: experimental
description: Detects HTTP requests to phpMyFAQ search endpoints containing excessive LIKE wildcard characters, indicative of CVE-2026-76212 exploitation attempts.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-76212
author: Valters IT Threat Intelligence
date: 2026/01/15
logsource:
    category: webserver
    product: apache
    definition: 'Requirements: Access logs or WAF logs capturing HTTP request URIs and query parameters. phpMyFAQ search typically uses a query parameter named "search" (verify against your deployment).'
detection:
    selection_search_path:
        cs-method: 'GET'
        cs-uri-extension: 'php'
        cs-uri-query|contains:
            - 'search='
    selection_wildcard_threshold:
        # Pattern-based: request query contains 3+ consecutive percent-encoded wildcards (%25) or underscores
        cs-uri-query|re:
            - '(?:%25){3,}'                      # three or more % (URL-encoded)
            - '_(?:%25|_){2,}'                    # underscore followed by multiple wildcards
            - '.*(%25%25%25|___).*'              # direct encoded triple wildcards
    selection_high_frequency:
        # Detection over time window - use with frequency aggregation in SIEM
        cs-uri-query|contains: 'search='
    condition: selection_search_path and selection_wildcard_threshold
    timeframe: 5m
    level: medium
    fields:
        - clientip
        - cs-uri-query
        - cs-user-agent
    falsepositives:
        - Legitimate users searching for terms containing % or _ characters (e.g., "100%", "C++_guide")
        - URL-encoded literals in normal usage
    tags:
        - attack.t1498.001
        - attack.t1190
        - cve.2026-76212
        - dos

YARA Rule

rule phpMyFAQ_Wildcard_DoS_Attempt_CVE_2026_76212
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Detects HTTP payloads in access logs containing excessive wildcard characters targeting phpMyFAQ search endpoints (CVE-2026-76212)"
        date = "2026-01-15"
        cve = "CVE-2026-76212"
        severity = "medium"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76212"

    strings:
        // Percent-encoded wildcard sequences (%25 = %)
        $enc_percent_3 = "%25%25%25"
        $enc_percent_6 = "%25%25%25%25%25%25"
        $enc_percent_10 = "%25%25%25%25%25%25%25%25%25%25"

        // Raw wildcard sequences in URL-encoded payloads
        $raw_wild_3 = "%%%"
        $raw_wild_10 = "%%%%%%%%%%"
        $raw_underscore_3 = "___"
        $raw_underscore_6 = "______"

        // Search parameter association
        $search_param = "search="
        $search_query = "search=" nocase
        $search_do = "aktion=search" nocase

    condition:
        // Must reference the search functionality
        any of ($search_param*) and
        // And contain multiple wildcard characters (encoded or raw)
        (any of ($enc_percent*) or any of ($raw_wild*) or any of ($raw_underscore*))
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"ET WEB_SERVER phpMyFAQ Wildcard Search DoS Attempt (CVE-2026-76212)";
    flow:established,to_server;
    http.method;
    content:"GET";
    http.uri;
    content:"search=";
    nocase;
    pcre:"/search=[^&\s]*((?:%25){3,}|(?:%26){3,}|#{3,})/i";
    reference:cve,2026-76212;
    reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-76212;
    classtype:attempted-dos;
    sid:202676212;
    rev:1;
    metadata:attack_target Web_Server, created_at 2026_01_15, cve CVE_2026_76212, deployment Perimeter, signature_severity Major, updated_at 2026_01_15;
)

Elastic Detection

// EQL detection for phpMyFAQ wildcard search DoS (CVE-2026-76212)
// Requires: Filebeat/auditbeat harvesting web server access logs into Elasticsearch
// Index: logs-* or filebeat-*
// Detection: Correlate multiple requests with heavy wildcard usage within a short window

sequence by source.ip with maxspan=5m
    [any where process.name == "httpd" or event.module == "apache"
        // Match requests containing percent-encoded wildcards in search parameter
        // Adjust the query parameter name to match your phpMyFAQ installation
        (url.query : "*search=*%25%25*" or url.query : "*search=*%25%25%25*")
    ] with runs=5

Splunk SPL Query

index=web sourcetype=access_combined uri_path=*index.php*
| rex field=uri_query "search=(?<search_term>[^&\s]+)"
| eval wildcard_count = (mvcount(split(search_term, "%25")) - 1) + (mvcount(split(search_term, "_")) - 1)
| where wildcard_count >= 3
| stats count as request_count, values(search_term) as search_terms, dc(srcip) as src_ip_count by srcip, dest_host
| where request_count > 10
| sort - request_count
| eval alert_message = "Potential CVE-2026-76212 phpMyFAQ wildcard search DoS from " . srcip . " with " . request_count . " suspicious queries"
| table _time, srcip, dest_host, request_count, src_ip_count, search_terms, alert_message

Wazuh OSSEC Rule

<group name="phpmyfaq,">
  <rule id="202612" level="10" frequency="10" timeframe="120">
    <if_sid>3150</if_sid>
    <field name="url">\.php</field>
    <match>search=</match>
    <regex>%25%25|%%</regex>
    <description>phpMyFAQ: Repeated wildcard-heavy search queries detected - Possible CVE-2026-76212 DoS attempt</description>
    <mitre><id>T1498.001</id></mitre>
    <group>cve-2026-76212,denial_of_service,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY — 2 independent sources confirm fix)

1. Immediate Mitigations (Before Patching)

• Upgrade if possible — This is the only definitive fix. If the organization has any policy allowing fast-track patching for DoS vulnerabilities, apply it here.
• Database connection pool limits — Reduce the maximum PostgreSQL connection pool size for the phpMyFAQ application to limit the number of concurrent expensive queries an attacker can force.
• Query timeout — Set a statement_timeout for the PostgreSQL user/role used by phpMyFAQ (e.g., ALTER ROLE phpmyfaq SET statement_timeout = '5s';). This caps per-query execution time and prevents runaway scans.
• Rate limiting — Implement rate limiting on the search endpoint at the web server or WAF layer (e.g., 5-10 requests/minute per IP for search queries).
• Web Application Firewall (WAF) rule — Deploy a WAF rule to block or alert on request bodies/query strings containing 3+ consecutive % or _ characters in the search parameter.
• Switch DB driver (temporary) — If feasible, reconfigure phpMyFAQ to use the PDO PostgreSQL backend (pdo_pgsql) instead of the native pgsql extension. The NVD description explicitly states the PDO backend is not affected. This is an effective immediate workaround.
• Temporary search disable — If the FAQ search is not business-critical, consider disabling the search feature temporarily until patching is completed.

2. Patch / Upgrade Steps

1. Update to phpMyFAQ 4.1.7 or later. This version contains the fix for the LIKE escape character mismatch.
2. Post-upgrade verification: After upgrading, submit a search containing % and _ characters (e.g., 100%) and verify the application returns only literal matches — not wildcard-expanded results.
3. Confirm the backend driver: Verify that the php.ini configuration loads the pgsql extension and that the application configuration points to the native driver. If the organization later reconfigures the database connection, re-check that the LIKE escape configuration remains consistent.
4. Regression testing: Run a quick functional test of the search with normal queries, quoted phrases, and special-character inputs to ensure no regression in search behavior.

3. Long-Term Hardening

• Inventory database drivers: Document which database backends each phpMyFAQ deployment uses. Flag any deployment using the native pgsql driver for priority review.
• Input validation layered over escaping: In addition to the application's escapeLikeWildcards() (now fixed in 4.1.7), consider a defense-in-depth layer at the WAF or web server that rejects or sanitizes excessive wildcard characters in search parameters.
• Database workload monitoring: Set up monitoring on the PostgreSQL server for metrics such as sequential scans per second, query execution time percentiles, and connection pool saturation. Alert on anomalies that match the wildcard-scan pattern.
• Establish patch SLAs: Consider adopting a policy where any CVE with a CVSS availability impact (even Low) affecting internet-facing applications receives a patch window of ≤7 days.
• Subscribe to vendor advisories: Monitor phpMyFAQ's official release notes and security advisories for quick awareness of future vulnerabilities.
• Periodic security review: Include a quarterly review of all public-facing web applications for search-related DoS vectors (wildcard escape mismatches, expensive regex patterns, etc.).

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2026-76212 Official NVD record with CVSS vector, CWE classification, and description.

2. OSV Advisory — https://osv.dev/vulnerability/CVE-2026-76212 OSV package entry confirming the fix and the affected OSV package commit reference (a429fb81a4efe1f7c0aeec5b7bf8a98a50509b85→unfixed).

3. phpMyFAQ Official Site / Release Notes — https://www.phpmyfaq.de/ Vendor website with release notes confirming the 4.1.7 fix. (Note: verify the specific changelog entry for this CVE on the vendor site.)

4. CWE-88 — Improper Neutralization of Argument Delimiters in a Command — https://cwe.mitre.org/data/definitions/88.html MITRE CWE definition for the classification assigned to this vulnerability.

5. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog CVE-2026-76212 is not currently listed on the KEV catalog, indicating no confirmed exploitation in the wild as of the publication date.

Threat Actor Campaigns / Exploit-in-the-Wild Evidence:

As of this report, there is no confirmed exploitation in the wild for CVE-2026-76212. It is not listed on the CISA KEV catalog. The EPSS score of 0.00299 places it in the 22nd percentile of exploited CVEs, indicating a relatively low probability of active exploitation. However, a public PoC exists, which means the technical barrier for weaponization is lowered. Security teams should treat this as a "watch-list" vulnerability: patch promptly during regular maintenance windows, but this does not require emergency out-of-band patching unless the affected instance is internet-facing and unmonitored.