CVE-2026-49205: phpMyFAQ Authorization Bypass in API Endpoints (v4.1.3 and Earlier)

Technical summary

CVE-2026-49205 is a missing authorization flaw (CWE-862) affecting phpMyFAQ's public API layer. Four write endpoints bypass role-based access control: POST /api/v4.0/category, POST /api/v4.0/faq, PUT /api/v4.0/faq, and POST /api/v4.0/question. These endpoints invoke only $this->hasValidToken()—a check that validates a shared API key header—rather than calling $this->userHasPermission() to enforce individual user roles. This pattern mirrors CVE-2026-24421, which was patched in the BackupController but the same remediation was not applied across all write APIs. An attacker with any valid API token can exploit this to inject, modify, or corrupt FAQ content.

Business impact

Unauthorized modification of FAQ content compromises data integrity and can degrade user trust. An internal user with basic API access, or an external attacker who obtains a valid token, could poison the knowledge base with false or malicious information, disrupt service availability through bulk content creation, or manipulate business-critical documentation. In organizations using phpMyFAQ for customer support or compliance documentation, this could result in regulatory exposure, reputational harm, and operational disruption.

Affected systems

phpMyFAQ versions prior to 4.1.4 are affected. The open-source nature of the project means any deployment using an unpatched version is vulnerable. Organizations running phpMyFAQ for internal or public-facing FAQ systems should verify their version immediately. The vulnerability requires the attacker to possess a valid API token, which reduces exposure if API access is tightly controlled, but increases risk in multi-user or federated authentication scenarios.

Exploitability

The vulnerability is exploitable by any authenticated user holding a valid API key, regardless of their assigned role or permissions. No additional privileges are required, and no user interaction is necessary. An attacker can immediately craft HTTP requests to the affected endpoints and modify FAQ content. The attack surface is high in deployments where API tokens are shared, broadly distributed, or insufficiently rotated. A compromised token—whether from a junior staff member, contractor, or third-party integration—provides direct access to content manipulation.

Remediation

Upgrade phpMyFAQ to version 4.1.4 or later. This version implements role-based permission checks on the affected endpoints, ensuring that $this->userHasPermission(PermissionType::*) is called to validate the user's permissions before allowing create or update operations. Organizations unable to upgrade immediately should restrict API access to trusted internal networks, rotate API tokens regularly, audit recent FAQ modifications for unauthorized changes, and consider disabling public API write endpoints if not actively used.

Patch guidance

Apply the update to version 4.1.4. Verify patch installation by confirming the application version in the phpMyFAQ admin interface. After patching, test API write endpoints with both privileged and unprivileged user accounts to confirm that permission checks are enforced. Review API integration scripts and third-party tools to ensure they continue to function with the updated authorization model. Monitor for any failed API requests immediately after deployment, as some integrations may be using overly permissive tokens.

Detection guidance

Monitor API logs for suspicious POST and PUT requests to /api/v4.0/category, /api/v4.0/faq, and /api/v4.0/question from users whose roles do not grant administrative permissions. Establish baselines for normal API usage patterns and alert on anomalies such as bulk category or FAQ creation outside business hours, or from unexpected source IPs. Audit recently modified or created FAQ entries to identify unauthorized changes. Check API token usage logs to identify tokens with excessive or inappropriate permissions. Implement request logging with user context to distinguish between authenticated requests by role.

Why prioritize this

This vulnerability is a medium-severity authorization bypass affecting content integrity rather than confidentiality. However, it directly enables authenticated attackers to manipulate business-critical information with no additional exploitation complexity. The fix (4.1.4) is available and straightforward to apply. Organizations should prioritize patching to prevent data poisoning and maintain FAQ reliability, especially if phpMyFAQ is customer-facing or regulatory-relevant. The fact that this mirrors a previously patched issue (CVE-2026-24421) suggests a systemic authorization design gap that warrants thorough API review across the codebase.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects network-exploitable access requiring valid authentication and resulting in integrity compromise but not confidentiality or availability breach. The score appropriately reflects that this is not a remote code execution or authentication bypass, but a permission enforcement failure. However, in environments where API tokens are loosely managed, the practical risk may be higher than the base score indicates.

Frequently asked questions