Summary
phpMyFAQ contains an object-level authorization flaw in the visitor-question API that can allow unauthenticated attackers who solve the CAPTCHA to modify or delete questions belonging to other users. The issue becomes risky when an attacker can submit an arbitrary question identifier and deletion is enabled by configuration.
phpMyFAQ contains an object-level authorization flaw in the visitor-question API that can allow unauthenticated attackers who solve the CAPTCHA to modify or delete questions belonging to other users. The issue becomes risky when an attacker can submit an arbitrary question identifier and deletion is enabled by configuration.
Affected context
The vulnerability occurs in phpMyFAQ deployments where the /api/faq/create endpoint processes a client-supplied openQuestionID without sufficiently verifying that the requester is authorized to access the referenced question. The impact may include unauthorized history and category changes, as well as deletion where the records.enableDeleteQuestion setting permits it.
The vulnerability occurs in phpMyFAQ deployments where the /api/faq/create endpoint processes a client-supplied openQuestionID without sufficiently verifying that the requester is authorized to access the referenced question. The impact may include unauthorized history and category changes, as well as deletion where the records.enableDeleteQuestion setting permits it.
Exploit preconditions
- Attack surface: The visitor-question API endpoint
- Required access: No authenticated account is required, but the attacker must satisfy the endpoint's CAPTCHA challenge
- Trigger point: A POST request to
/api/faq/createcontaining an arbitraryopenQuestionID - Why exploitation is possible: The server may use the supplied object identifier without enforcing ownership or authorization checks for the referenced question
- Attack surface: The visitor-question API endpoint
- Required access: No authenticated account is required, but the attacker must satisfy the endpoint's CAPTCHA challenge
- Trigger point: A POST request to
/api/faq/createcontaining an arbitraryopenQuestionID - Why exploitation is possible: The server may use the supplied object identifier without enforcing ownership or authorization checks for the referenced question
Why this happens
The underlying bug is a failure to enforce object-level authorization on a user-controlled record identifier. The endpoint accepts an arbitrary openQuestionID and performs actions on that object without reliably confirming that the requester is permitted to modify or delete it. This behavior maps to CWE-639, which covers authorization bypasses caused by user-controlled object references.
The underlying bug is a failure to enforce object-level authorization on a user-controlled record identifier. The endpoint accepts an arbitrary openQuestionID and performs actions on that object without reliably confirming that the requester is permitted to modify or delete it. This behavior maps to CWE-639, which covers authorization bypasses caused by user-controlled object references.
Potential impact
- An attacker may alter categories assigned to visitor questions
- An attacker may create or forge answered entries in question history
- An attacker may delete questions when deletion is enabled
- The application may lose data integrity and audit reliability
- Publicly submitted content may be manipulated or removed without authorization
- An attacker may alter categories assigned to visitor questions
- An attacker may create or forge answered entries in question history
- An attacker may delete questions when deletion is enabled
- The application may lose data integrity and audit reliability
- Publicly submitted content may be manipulated or removed without authorization
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the object level
for every operation involving a client-supplied identifier.
Common defensive patterns include:
- Verify ownership, role, or explicit administrative permission before modifying or deleting each referenced question
- Treat object identifiers as references only, not as proof of authorization
- Apply the same authorization checks to create, update, history, and delete workflows
- Use secure-by-default settings that keep destructive operations disabled unless explicitly required
- Reduce trust in client-controlled fields and derive sensitive state from server-side records
- Apply least privilege to application roles and isolate administrative question-management functions
Mitigation generally focuses on enforcing authorization at the object level
for every operation involving a client-supplied identifier.
Common defensive patterns include:
- Verify ownership, role, or explicit administrative permission before modifying or deleting each referenced question
- Treat object identifiers as references only, not as proof of authorization
- Apply the same authorization checks to create, update, history, and delete workflows
- Use secure-by-default settings that keep destructive operations disabled unless explicitly required
- Reduce trust in client-controlled fields and derive sensitive state from server-side records
- Apply least privilege to application roles and isolate administrative question-management functions
How teams detect issues like this
High-level detection approaches include:
- Static analysis and code review for endpoints that use request parameters to select database objects
- Searches for update or delete operations keyed directly by client-supplied identifiers
- Review of authorization middleware and service-layer checks for object ownership or role validation
- Tests that attempt cross-user access to object identifiers under anonymous and low-privilege sessions
- API policy enforcement requiring authorization decisions before object retrieval or mutation
- Monitoring for unusual sequences of question updates, history changes, or deletions from unauthenticated sources
High-level detection approaches include:
- Static analysis and code review for endpoints that use request parameters to select database objects
- Searches for update or delete operations keyed directly by client-supplied identifiers
- Review of authorization middleware and service-layer checks for object ownership or role validation
- Tests that attempt cross-user access to object identifiers under anonymous and low-privilege sessions
- API policy enforcement requiring authorization decisions before object retrieval or mutation
- Monitoring for unusual sequences of question updates, history changes, or deletions from unauthenticated sources
