CVE-2026-111907 is a high severity (CVSS 7.1) cross-site request forgery in phpMyFAQ 4.0.0 before 4.1.9. The update-database endpoint runs migrations without a CSRF token, so a lured admin can trigger them. Upgrade to 4.1.9. The sections below cover affected versions, how to check, and what to do first.
What's affected
phpMyFAQ 4.0.0 before 4.1.9, per the record. The GitHub advisory names 4.1.8 as the tested affected version and 4.1.9 as patched.
The endpoint is POST /admin/api/update-database. It checks that the user holds the configuration edit permission but does not validate a CSRF token, unlike other update endpoints. The victim must be signed in with that permission and must visit a hostile page.
Scoring note: the record's 7.1 is a CVSS 3.1 base score. VulnCheck's advisory also lists 7.1 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Check your version:
composer show thorsten/phpmyfaq
The advisory lists the package as thorsten/phpmyfaq for this issue. Then list which accounts hold the configuration edit permission. Those are the accounts a forged request could act as. Review the database for unexpected migrations or schema changes.
What to do now
- Find your phpMyFAQ version.
- Upgrade to 4.1.9 or later.
- Reduce the number of accounts with the configuration edit permission.
- Ask admins to sign out of the admin area when browsing other sites.
- Back up the database before any upgrade or migration.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Keep a record of what you checked and what you changed. Note the version found, the date, the action taken and who approved it. If the advisory is later updated, for example with a fixed release, you will know which systems need another pass, and an auditor or a colleague can follow your reasoning.
Why it matters
This is CWE-352, cross-site request forgery. The browser attaches the session cookie to any request sent to your site, including one triggered by another site. A CSRF token proves the request came from your own page. This endpoint does not ask for one.
Migrations change the schema, so a forged call can harm integrity and availability. The record notes it needs the victim to act, which is why the score stays below the unauthenticated bugs. It is not listed in CISA KEV.
Quick check
What does a CSRF token do?
It ties a request to the page your site served, so a request from another site fails the check.
Who is at risk?
Signed in users with the configuration edit permission, per the advisory.
Sources
Last reviewed: 18 October 2026.
