phpMyFAQ EUVD-2026-62453

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.

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.

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.