CVE-2026-111908 is a high severity (CVSS 8.3) broken object-level authorization flaw in phpMyFAQ. An editor can modify FAQs they cannot view by sending the ID. The record lists fixes in 4.1.9 and 4.2.0-beta, but the GitHub advisory lists none. The sections below cover affected versions, how to check, and what to do first.
What's affected
Per the record: phpMyFAQ 4.0.0 before 4.1.9, and 4.2.0-alpha before 4.2.0-beta. The GitHub advisory I fetched names 4.1.8 as the tested version and says patched versions are none.
Source conflict: the record says the fix is in 4.1.9 or 4.2.0-beta, while the GitHub advisory page I fetched lists patched versions as none. Check the phpMyFAQ release notes and the advisory before relying on either.
The route is PUT /api/v3.1/faq/update. It checks the global edit permission but not access to the target FAQ. The record says an editor can change content, bypass moderation and change publication state.
Scoring note: the record's 8.3 is a CVSS 3.1 base score. VulnCheck's advisory also lists 8.7 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 phpmyfaq/phpmyfaq
Then review which accounts hold the edit FAQ permission, and compare recent changes to restricted FAQs against who was allowed to make them.
What to do now
- Find your phpMyFAQ version.
- Confirm in the advisories and release notes which release fixes this for you.
- Upgrade to 4.1.9 or 4.2.0-beta once confirmed.
- Review recent edits to restricted FAQs and revert unauthorised ones.
- Limit the edit FAQ permission to trusted editors until you are on a fixed build.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Do not stop at one host. Write down every place the affected software runs, including test servers, forgotten containers and copies bundled inside other products. Then rank them by exposure: anything reachable from the internet comes first, internal systems next. A short inventory now saves hours when the next advisory lands.
Why it matters
This is CWE-639, authorization bypass through a user-controlled key, often called BOLA. The server checks that you may edit FAQs in general and then trusts the ID in the request. It never asks whether this editor may touch this FAQ.
BOLA tops many API risk lists because it hides in routes that look protected. The advisory shows a view request returning not found for the editor, while the update route accepts the same ID. That mismatch is the bug. It is not listed in CISA KEV.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What is BOLA?
Broken object-level authorization: the server checks the role but not whether the caller may access the specific object.
Can an editor read the restricted FAQ?
The advisory says the editor could not view it, yet could still modify it.
Sources
Last reviewed: 18 October 2026.
