phpMyFAQ CVE-2026-75918

Exploitation requires that the phpMyFAQ user tracking feature is enabled - the CVE description explicitly states 'when user tracking is enabled', but whether this is the default configuration is not confirmed from any available source. A password reset must be initiated for the target account, either by the victim or by the attacker using the unauthenticated reset form. The tracking file at content/core/data/trackingDDMMYYYY must be accessible over HTTP, meaning the web server must not restrict access to that directory. CVSS PR:N confirms no authentication is needed to read the file. The UI:P rating in the CVSS 4.0 vector indicates that the reset initiation step constitutes the required interaction. Exploitation is strictly limited to phpMyFAQ instances running versions prior to 4.1.7; administrators who have already blocked web access to content/core/data/ or disabled user tracking are not exploitable through this path.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H) reflects realistic severity: the attack is network-accessible, low-complexity, and requires no authentication to read the tracking file. The UI:P metric signals that a password reset must be initiated - either by the victim or by the attacker via the unauthenticated reset form - which limits mass opportunistic exploitation but does not prevent targeted attacks. No EPSS data was supplied in the input, and neither a CISA KEV listing nor public POC code has been identified, so active exploitation remains unconfirmed. Despite these absent signals, even a mid-sized municipal IT team in rybnik should treat this as urgent, because harvesting the token requires no specialized tooling - only a date-constructed URL and a standard HTTP request. The VA:H rating warrants scrutiny: account takeover does not inherently cause availability loss, and this metric appears overstated relative to the described impact, which is primarily confidentiality and integrity compromise.

An attacker targeting a phpMyFAQ user submits a password reset request for the victim's account via the unauthenticated reset form, causing a token to be written to the tracking file. The attacker then fetches the predictably named file at content/core/data/trackingDDMMYYYY - constructed from the current date - and extracts the reset token to replay against the password reset API, fully taking over the account. No public POC has been identified at time of analysis, but the attack requires no specialized tooling beyond a standard HTTP client.