Key points
- phpMyFAQ versions before 4.1.9 and 4.2.0-alpha through 4.2.0-beta are affected by CVE-2026-111908.
- The vulnerability allows bypass of object-level authorization on the PUT /api/v3.1/faq/update endpoint.
- Authenticated users with global edit_faq permission can alter content they cannot view.
Security researchers have identified a broken object-level authorization flaw in phpMyFAQ, a popular open-source knowledge base software. The vulnerability, tracked as CVE-2026-111908, carries a CVSS score of 8.7, which rates it as high severity. It affects phpMyFAQ 4.0.0 through versions prior to 4.1.9, as well as development builds from 4.2.0-alpha up to 4.2.0-beta, according to the National Vulnerability Database.
In plain English
The issue resides in the API endpoint used to update Frequently Asked Questions. When a user sends a request to modify a specific FAQ entry, the software checks whether the user has the general permission to edit FAQs. However, it fails to verify if the user is authorized to edit that specific entry. This means an attacker with basic editing rights can target any FAQ ID, regardless of its visibility or ownership settings.
The background
This weakness is classified under CWE-639, which covers broken object-level authorization. In this scenario, the application relies on a global permission flag named edit_faq. It does not perform a secondary check to ensure the target object belongs to the user or is accessible to them. Consequently, the system treats all FAQ entries as editable by anyone who possesses the broad editing capability, ignoring granular access controls.
What changes now
An authenticated user who holds the edit_faq permission can exploit this flaw by supplying the ID of a restricted FAQ they normally cannot view. By doing so, they can modify the content of that entry, effectively bypassing any moderation processes in place. The attacker can also change the publication state of the FAQ, potentially publishing unauthorized or malicious content to the public-facing site without proper approval.
Who needs to act first
Teams usually prioritize systems exposed to the internet or accessible by untrusted users. Check whether your phpMyFAQ instance is reachable from external networks. If it is, isolate the environment or restrict API access immediately. Back up the database before attempting any manual mitigations. Monitor logs for unusual PUT requests to the update endpoint. Verify that only necessary users possess the edit_faq permission. Review published FAQs for unexpected content changes to detect potential exploitation.
What to do and how to stay safe: phpMyFAQ
- Audit user accounts to ensure only trusted administrators hold the edit_faq permission.
- Restrict network access to the phpMyFAQ API endpoints using firewalls or web application firewalls.
- Monitor server logs for suspicious PUT requests to the /api/v3.1/faq/update path.
- Verify the integrity of published FAQ content to detect unauthorized modifications.
Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits
General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which phpMyFAQ versions are vulnerable to CVE-2026-111908?
phpMyFAQ 4.0.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta are affected.
What is the CVSS score for this vulnerability?
The CVSS score is 8.7, which is rated as high severity.
Can unauthenticated users exploit this flaw?
No, the vulnerability requires an authenticated user with the edit_faq permission.
