EUVD-2026-109444
GHSA-hpmh-2f7x-mv5g
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSolve graphical CAPTCHA as anonymous visitor
-
ExploitPOST /api/faq/create with arbitrary openQuestionID
-
ExecutionBypass missing object-level authorization check
-
ImpactOverwrite question and forge answered-history, or permanently delete record
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Default-configuration prerequisites (all shipped defaults of phpMyFAQ before 4.1.10): records.allowNewFaqsForGuests=true so anonymous visitors pass the only feature gate; spam.enableCaptchaCode=true, meaning the attacker must solve one graphical CAPTCHA per request (an anti-automation control, not an authorization check); and at least one victim open question must exist (the normal state of any FAQ site). The parameter must be spelled exactly openQuestionID (capital D) and be non-zero, since property_exists() is case-sensitive - the front-end JS sends openQuestionId, which is why the bug is easy to miss. No account, no CSRF token, and no victim user interaction are required. The destructive, permanent-DELETE variant (CVSS 9.1, availability impact) requires the one additional non-default administrator checkbox records.enableDeleteQuestion=true; with it off (shipped default) exploitation is limited to the UPDATE branch - overwriting category/answer link and forging a faqquestion_history 'answered' row with an attacker-chosen username. The CAPTCHA requirement is the main practical limit on automated mass abuse. |
| Impact | This is a CWE-639 object-level authorization bypass (IDOR) scored CVSS 4.0 8.7 (High) with vector AV:N/AC:L/AT:N/PR:N/UI:N and a pure integrity impact (VI:H, VC:N/VA:N) in the shipped default configuration. The upstream GHSA advisory supplies two CVSS 3.1 framings: 7.5 High for the default UPDATE branch (C:N/I:H/A:N) and 9.1 Critical for the DELETE branch (C:N/I:H/A:H) that activates only when the administrator option records.enableDeleteQuestion is enabled. The network-reachable, no-authentication, no-user-interaction, low-complexity profile makes the flaw trivially triggerable, and a detailed proof of concept with verified live HTTP evidence is published in the GHSA advisory, so the technical barrier is low. Tempering that: no EPSS probability was provided in the input and the CVE is not listed in CISA KEV, so there is no public signal of widespread or active exploitation - this appears to be a newly disclosed issue (reported by VulnCheck, vuln.today Decision label 'this_week') rather than a mass-exploited one. The impact is data integrity against FAQ question records, not code execution, credential theft, or confidentiality loss; availability impact (permanent deletion) is gated behind a non-default admin checkbox. Net: a genuine, easy-to-exploit integrity/data-destruction bug that warrants prompt patching on exposed phpMyFAQ instances, but it is not an RCE-class emergency, and the severity an operator actually faces depends on whether records.enableDeleteQuestion is on. |
| Exploit ScenarioDerived | An anonymous visitor solves the graphical CAPTCHA and sends POST /api/faq/create with an attacker-chosen openQuestionID (exact capitalization, non-zero) referencing any visitor question - including hidden ones the attacker cannot see in the UI. On a stock install the targeted question's category and answer link are overwritten and a forged 'answered' entry is written to faqquestion_history; if the administrator enabled records.enableDeleteQuestion the same request permanently deletes the question with no soft delete or recovery. A working proof of concept with verified HTTP requests and SQL evidence is published in the GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 25, 2026
An object-level authorization bypass in phpMyFAQ before 4.1.10 allows unauthenticated visitors to rewrite or, under one optional administrator setting, permanently delete any visitor-submitted open question by sending an arbitrary openQuestionID to POST /api/faq/create. The only gate in front of the endpoint is the guest-submission feature switch, which defaults to enabled; the graphical CAPTCHA the attacker must solve is an anti-automation measure, not an authorization control, and it is the main practical limit on mass abuse. In the shipped default configuration the impact is integrity-only (CVSS 4.0 8.7, CVSS 3.1 7.5): category and answer link are overwritten and a forged 'answered' entry is written to faqquestion_history; if records.enableDeleteQuestion is turned on, the same request deletes the question outright with no soft-delete and no revision trail, matching the advisory's 9.1 Critical variant. No KEV listing or confirmed active exploitation is reported, and no standalone public exploit code has been identified at time of analysis, although the advisory itself publishes a step-by-step reproduction; this should be scheduled in the current weekly patch cycle.
RemediationAI
Vendor-released patch: phpMyFAQ 4.1.10 - upgrade to that release or later, using the vendor advisory GHSA-9m55-g84r-x6v7 (https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-9m55-g84r-x6v7) and the VulnCheck advisory as the change references; because the vulnerable code was still present in main and in the 4.1-nightly-2026-10-07 build at the time of reporting, operators on nightly or development branches should verify the fix commit is actually present rather than relying on the version string alone. If upgrading cannot be done immediately, set records.enableDeleteQuestion to false, which the advisory confirms is the shipped default and which removes the permanent-DELETE branch entirely - the endpoint then falls back to the category/answer-link overwrite and forged faqquestion_history row, so this is a reduction in severity rather than a fix; be aware that turning the option off changes question-retention behaviour for legitimate administrators who enabled it on purpose. Setting records.allowNewFaqsForGuests to false removes anonymous access to the guest-submission path and therefore blocks the unauthenticated attack route described in the advisory, at the cost of disabling visitor-submitted questions and the /add-question.html workflow. Relying on the CAPTCHA is not sufficient, since the advisory shows it is an anti-automation control that a determined attacker simply solves once per request; the durable fix is the object-level check the advisory proposes - validating that the referenced question exists, binding the request to a one-time session claim token or to PermissionType::QUESTION_ADD, dropping the deletion branch from the public route, keeping deletion behind PermissionType::QUESTION_DELETE in Controller/Administration/Api/QuestionController.php, extending the same check across Frontend/Api/** endpoints that accept client-supplied identifiers, and placing the existing RateLimiter in front of /api/faq/create. After patching, audit the faqquestions table for unexpected category_id/answer_id changes and faqquestion_history for forged Answered rows, noting that question deletions leave no revision trail and are unrecoverable without a database backup.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Root cause is CWE-639 (authorization bypass through a user-controlled key) in phpMyFAQ's frontend API controller. FaqController::create() (phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/FaqController.php, roughly lines 200-229 on main) reads a client-supplied openQuestionID, runs it through Filter::filterVar(..., FILTER_VALIDATE_INT) and then uses the resulting integer directly as the WHERE key of a write against the faqquestions table, without comparing it to the requesting session, without checking faqquestions.is_visible, and without consulting the caller's permissions. Two sinks carry the attacker's identifier: QuestionRepository::updateQuestionAnswer() emits UPDATE %sfaqquestions SET answer_id = %d, category_id = %d WHERE id = %d, and QuestionRepository::delete() emits DELETE FROM %sfaqquestions WHERE id = %d AND lang = '%s'; neither statement contains an ownership, visibility or answer_id predicate. A third write forges an audit row: a QuestionHistoryEntity with eventType Answered is inserted into faqquestion_history using the attacker-controlled identifier, with the username falling back to the attacker-supplied author field when the session login is empty, so the forgery is attributed to an arbitrary name. The pre-existing guards do not constitute an authorization model: isAddingFaqsAllowed() is a feature switch and records.allowNewFaqsForGuests defaults to true (Setup/Installation/DefaultDataSeeder.php), the graphical CAPTCHA in AbstractController is anti-automation only, and the endpoint performs no CSRF token validation. Because property_exists() is case-sensitive for PHP object properties, the parameter must be spelled exactly openQuestionID (capital D) and must be non-zero, whereas the shipped front-end JavaScript sends openQuestionId on the update path, which explains why manual testing easily misses the defect. The lang predicate of the DELETE is also attacker-controlled: Question::delete() uses the current request language and FaqController resolves it with setLanguageWithDetection() because main.languageDetection defaults to true, so requesting a language first selects which localized row is destroyed. The equivalent administrative capability is properly protected in Controller/Administration/Api/QuestionController.php by an admin session, a CSRF token and PermissionType::QUESTION_DELETE, and the public open-questions listing only exposes rows with is_visible = 'Y', confirming that addressing an open question by ID was never intended to be reachable anonymously.
Know when Phpmyfaq gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Remote unauthenticated write with only a CAPTCHA (anti-automation, not auth) gives AV:N/AC:L/PR:N/UI:N; integrity-only I:H for the default UPDATE branch, rising to A:H (9.1) when records.enableDeleteQuestion enables permanent deletion.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
phpMyFAQ before 4.1.10 contains an object-level authorization bypass vulnerability that allows unauthenticated attackers to modify or delete any visitor question by supplying an arbitrary openQuestionID to POST /api/faq/create. Attackers solving the CAPTCHA can rewrite question categories, forge answered entries in faqquestion_history, or permanently delete questions when records.enableDeleteQuestion is enabled.
Technical POC Analysis
CWE-639, Authorization Bypass Through User-Controlled Key.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
CVE-2026-116183 exposes phpMyFAQ deployments (prior to 4.1.10) to unauthenticated tampering with visitor-submitted questions, allowing attackers to rewrite or, under a specific optional setting, permanently delete content without any authorization check. This matters to leadership because public-facing FAQ and knowledge-base content integrity is directly at risk in default configurations, and organizations that have enabled question deletion face irreversible data loss with no audit trail.
No vendor-released patch identified at time of analysis for versions prior to 4.1.10; interim mitigations are to disable the guest-submission feature switch and disable records.enableDeleteQuestion, and rely on CAPTCHA only as an anti-automation measure, not as an authorization control. Upgrading to 4.1.10 or later is the remediation path.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets una
Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8
Authentication Bypass by Capture-replay in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity
Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity (CVSS 9.8), t
Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), th
Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.ratings.php. Rated high severity (CVS
In phpMyFaq before 2.9.9, there is CSRF in admin/ajax.config.php. Rated high severity (CVSS 8.8), this vulnerability is
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) for modifying a glossary. Rated high severity (CVSS
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.main.php. Rated high severity (CVSS 8
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi
Exploit-DB