phpMyFAQ CVE-2026-76210

The attacker must hold an active phpMyFAQ account with FAQ creation or editing permissions - this is the essential, non-negotiable prerequisite. The target file must reside within the web root's content/ directory, as the attack vector is constrained to paths reachable through that location (e.g., content/core/config/database.php); files outside this subtree are not reachable via the documented attack path. PDF export functionality must be enabled and accessible to the attacker's session. The severity of information disclosure is directly governed by the PHP runtime's zend.exception_string_param_max_len setting: at the PHP default of 15 characters, only a fragment is exposed; at higher operator-configured values, full file contents including credentials may be disclosed. Exploitation does not require any special network position, specific operating system, or non-standard web server configuration beyond authenticated HTTP access to a vulnerable phpMyFAQ installation. Installations where FAQ editing rights are restricted to a small, trusted staff group face substantially lower real-world risk than community-editable deployments.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) places this firmly in the high-severity tier: the attack is network-reachable, requires no elevated complexity or additional attack preconditions, and demands only low-privilege access in the form of a FAQ editor account. The high confidentiality impact is warranted because successful exploitation on a permissively configured instance can yield full database credential disclosure, which cascades into broader infrastructure compromise. No CISA KEV listing exists and no public proof-of-concept has been identified at time of analysis, so exploitation remains theoretical but operationally trivial for any attacker who already holds FAQ editing rights. EPSS data was not provided in available intelligence, which limits probabilistic risk scoring. The primary real-world risk differentiator is the zend.exception_string_param_max_len setting: organizations running PHP at its default value face a significantly reduced disclosure window, whereas instances with elevated values - which some operators configure for debugging purposes - face near-total file exposure. Even a mid-sized municipal IT team in sanok running a community-facing phpMyFAQ deployment should treat this as an urgent upgrade given that leaked credentials from the database.php configuration file could grant attackers direct database access. The requirement for FAQ editor access prevents unauthenticated mass exploitation but does not meaningfully protect installations with open community registration.

An attacker who has obtained FAQ editor access on a community phpMyFAQ instance - through open self-registration or compromised credentials - creates a FAQ answer containing an img tag with its src set to content/core/config/database.php. The attacker then triggers a PDF export of that FAQ, causing TCPDF to read the PHP configuration file as though it were an image; the resulting parse failure raises an uncaught exception whose stack trace is returned in the HTTP response, disclosing the database hostname, username, and password. No public proof-of-concept has been identified, but the attack requires only a standard browser and no specialized tooling.