Skip to main content

phpMyFAQ CVE-2026-76212

| EUVDEUVD-2026-62453 MEDIUM
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') (CWE-88)
2026-08-19 VulnCheck GHSA-jj45-w38g-gfrj
6.9
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Identify public phpMyFAQ search endpoint
  2. Delivery
    Submit search queries containing % or _ wildcard characters
  3. Exploit
    Bypass inert LIKE wildcard sanitization in native pgsql backend
  4. Install
    Force PostgreSQL full sequential table scan per request
  5. C2
    Repeat at high frequency
  6. Execute
    Exhaust database CPU and I/O
  7. Impact
    Deny service to legitimate users

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Argument sanitization
Exploitation Conditions

Exploitation requires phpMyFAQ to be deployed with PHP's native pgsql extension as the PostgreSQL backend - the PDO PostgreSQL driver is explicitly unaffected and not exploitable via this flaw. The public FAQ search form must be network-accessible, which is the typical default deployment. The CVSS 4.0 vector (PR:N/UI:N) confirms no credentials or user interaction are required once the vulnerable backend is in place. The following factors limit exploitation scope: (1) only the native pgsql backend is vulnerable - operators on PDO are not at risk; (2) the attack produces availability degradation only - quote escaping remains intact, so SQL injection and data exfiltration are not possible per the CVE description; (3) the denial-of-service effect is rate-dependent, meaning network-layer throttling reduces but does not eliminate risk.

Impact

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N) scores 6.9 and accurately reflects a remotely triggerable, low-complexity availability impact with zero confidentiality or integrity consequence. Real-world risk is meaningfully bounded by a critical deployment prerequisite: only the native pgsql PHP extension backend is affected, not the PDO driver, which limits the vulnerable population considerably. That said, even a mid-sized municipal IT team in kielce running the native pgsql configuration with a public-facing phpMyFAQ instance should treat this as a priority patch, since repeated wildcard-heavy queries can saturate PostgreSQL I/O and CPU without any authentication barrier. There is no KEV listing and no POC code identified in the input, suggesting exploitation is not currently widespread. EPSS data was not provided, so exploitation probability cannot be quantified from available signals. The 'SQLi' tag in the source intelligence is misleading - the CVE description explicitly states quote escaping remains intact and SQL injection is not possible; defenders should not escalate response based on that tag alone.

Exploit ScenarioDerived

An unauthenticated attacker identifies a publicly accessible phpMyFAQ instance configured with the native pgsql PHP extension. The attacker submits rapid, repeated search queries consisting of only % characters, which pass through the broken wildcard sanitization and cause PostgreSQL to execute full sequential table scans on each request. Sustained query flooding exhausts database CPU and I/O capacity, degrading or fully denying service to legitimate users of the FAQ application. No public exploit code has been identified at time of analysis.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Aug 19, 2026

Wildcard injection in phpMyFAQ before 4.1.7 allows unauthenticated attackers to cause denial of service via the public FAQ search form when the application is running against PostgreSQL through PHP's native pgsql extension. The underlying defect is a character mismatch in LIKE escape handling: Search/Database/Pgsql.php declares '=' as the LIKE ESCAPE character but escapeLikeWildcards() prefixes user input with '|', making wildcard sanitization entirely inert. Submitted % and _ characters pass through as active SQL wildcards, forcing PostgreSQL into maximally broad sequential table scans. No public exploit has been identified at time of analysis, and the vulnerability explicitly does not enable SQL injection or data exfiltration.

RemediationAI

The primary remediation is to upgrade phpMyFAQ to version 4.1.7 or later, which corrects the LIKE ESCAPE character mismatch in Search/Database/Pgsql.php. Full advisory details are available at https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-5hx6-c293-588h. If immediate patching is not possible, migrating to the PDO PostgreSQL backend eliminates the vulnerability entirely, though this requires configuration and regression testing. As an interim network-layer control, rate-limiting or WAF rules applied to the public search endpoint can reduce the frequency and impact of wildcard-flooding attempts, at the cost of potentially throttling legitimate high-volume search traffic. Disabling the public FAQ search feature entirely is the most aggressive but fully effective workaround for operators who can accept that functional trade-off.

Affected VersionsENISA

phpMyFAQ 4.2.0-alpha <4.1.7

Affected Packages

euvd phpmyfaq fix: 4.1.7

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

phpMyFAQ is an open-source PHP FAQ management system whose PostgreSQL search backend (Search/Database/Pgsql.php) implements LIKE query escaping through an escapeLikeWildcards() function. The root cause is classified as CWE-88 (Argument Injection or Modification): the declared LIKE ESCAPE character in the SQL clause is '=' while the function actually prepends '|' to % and _ characters in user input. Because PostgreSQL uses '=' as the recognized escape character, the '|'-prefixed wildcards are never treated as escaped, leaving % and _ fully functional as SQL LIKE wildcards. This forces the PostgreSQL query planner to abandon index-optimized lookups in favor of expensive sequential full-table scans on every search request. The CPE cpe:2.3:a:thorsten:phpmyfaq:*:*:*:*:*:*:*:* covers all releases prior to 4.1.7. The PDO PostgreSQL driver is explicitly unaffected because it employs a different parameterization mechanism, and quote escaping remains correct throughout, ruling out SQL injection or data access.

Know when Phpmyfaq gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 6.9 MEDIUM
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
vuln.today AI 5.3 MEDIUM

Network-accessible public search form requires no privileges or interaction; availability impact is Low as DoS is query-rate-dependent and confined to the vulnerable system.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
None
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

1
Patch available
Aug 19, 2026 - 15:17 EUVD

DescriptionCVE.org

phpMyFAQ before 4.1.7, when configured to use PostgreSQL via the native pgsql PHP extension, declares an incorrect LIKE ESCAPE character ('=') in the Search/Database/Pgsql.php backend while escapeLikeWildcards() escapes user input with the '|' prefix. As a result, wildcard escaping is a no-op and user-supplied % and _ characters remain active LIKE wildcards. An unauthenticated attacker can submit such characters in the public FAQ search form to force maximally broad pattern matches and expensive sequential scans, resulting in a denial of service. The PDO PostgreSQL backend is not affected, and quotes remain escaped so this does not enable quote-breaking SQL injection or data exfiltration.

Threat Intelligence Overview

EPSS Score
0.3%
Top 77% exploitable
Prevalence
Low
niche open-source FAQ platform, limited enterprise production footprint
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact· derived
Medium

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

CVE-2025-59943 CRITICAL POC
9.8 Oct 03

Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets una

CVE-2023-5865 CRITICAL POC
9.8 Oct 31

Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8

CVE-2023-1886 CRITICAL POC
9.8 Apr 05

Authentication Bypass by Capture-replay in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity

CVE-2023-1753 CRITICAL POC
9.8 Mar 31

Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity (CVSS 9.8), t

CVE-2022-3754 CRITICAL POC
9.8 Oct 29

Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), th

CVE-2026-46364 CRITICAL POC
9.3 May 15

Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and

CVE-2017-15730 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.ratings.php. Rated high severity (CVS

CVE-2017-15808 HIGH POC
8.8 Oct 23

In phpMyFaq before 2.9.9, there is CSRF in admin/ajax.config.php. Rated high severity (CVSS 8.8), this vulnerability is

CVE-2017-15735 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) for modifying a glossary. Rated high severity (CVSS

CVE-2017-15734 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.main.php. Rated high severity (CVSS 8

CVE-2024-28107 HIGH POC
8.8 Mar 25

phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi

CVE-2024-27299 HIGH POC
8.8 Mar 25

phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi

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