CVE-2026-24422: phpMyFAQ Information Disclosure Flaw

CVE-2026-24422 Overview

CVE-2026-24422 is an Information Disclosure vulnerability affecting phpMyFAQ, an open source FAQ web application. In versions 4.0.16 and below, multiple public API endpoints improperly expose sensitive user information due to insufficient access controls. The OpenQuestionController::list() endpoint calls Question::getAll() with showAll=true by default, returning records marked as non-public (isVisible=false) along with user email addresses. Similar exposures are present in comment, news, and FAQ APIs.

Critical Impact

This vulnerability enables unauthenticated attackers to harvest user email addresses for phishing campaigns and access content explicitly marked as private through improperly secured API endpoints.

Affected Products

• phpMyFAQ versions 4.0.16 and below
• All deployments using default API configurations
• Instances with public-facing API endpoints enabled

Discovery Timeline

• January 24, 2026 - CVE-2026-24422 published to NVD
• January 28, 2026 - Last updated in NVD database

Technical Details for CVE-2026-24422

Vulnerability Analysis

This vulnerability stems from improper access control implementation across multiple API endpoints in phpMyFAQ. The core issue lies in the OpenQuestionController::list() method, which invokes the Question::getAll() function with the showAll parameter set to true by default. This configuration flaw causes the API to return all records from the database, including those explicitly marked as non-public through the isVisible=false flag.

The information disclosure extends beyond the open questions API. Similar access control deficiencies exist in the comment, news, and FAQ API endpoints, creating multiple avenues for data exfiltration. An unauthenticated attacker can query these public endpoints without any authorization checks, retrieving sensitive data that should be restricted.

The exposed information includes user email addresses associated with submitted questions and comments, as well as content that administrators had intentionally hidden from public view. This combination makes the vulnerability particularly dangerous for social engineering attacks.

Root Cause

The root cause of CVE-2026-24422 is the absence of proper authorization checks in the API controller layer combined with overly permissive default parameter values. The showAll=true default in the Question::getAll() method bypasses visibility filters that should restrict access to non-public records. Additionally, the API endpoints lack authentication requirements that would prevent anonymous users from accessing sensitive data retrieval functions.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending crafted HTTP requests to the vulnerable API endpoints. The OpenQuestionController::list() endpoint is accessible without authentication, and the default behavior returns all records regardless of their visibility settings.

An attacker would typically enumerate the API endpoints, then send GET requests to endpoints like /api/questions/list to retrieve the full dataset including hidden records and associated email addresses. The attack can be automated to systematically harvest information across all affected API endpoints (questions, comments, news, and FAQs).

The vulnerability mechanism operates through the API controller layer where visibility checks should occur but are bypassed due to the default parameter configuration. For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-24422

Indicators of Compromise

• Unusual volume of API requests to /api/questions/, /api/comments/, /api/news/, or /api/faq/ endpoints from single IP addresses
• Access logs showing repeated enumeration patterns across multiple API endpoints
• Requests to API endpoints from unexpected geographic locations or known malicious IP ranges
• Evidence of automated tooling signatures in User-Agent strings targeting phpMyFAQ API endpoints

Detection Strategies

• Monitor web server access logs for high-frequency requests to phpMyFAQ API endpoints without authenticated sessions
• Implement rate limiting on API endpoints and alert on threshold violations
• Configure web application firewall (WAF) rules to detect API enumeration patterns and bulk data retrieval attempts
• Review application logs for requests that return large datasets from list-type API endpoints

Monitoring Recommendations

• Enable detailed logging for all phpMyFAQ API endpoint access including request parameters and response sizes
• Set up alerting for API requests that return datasets containing email addresses or non-public content
• Monitor for data exfiltration patterns characterized by systematic requests to multiple API endpoints in sequence
• Implement anomaly detection for unusual API usage patterns compared to baseline normal traffic

How to Mitigate CVE-2026-24422

Immediate Actions Required

• Upgrade phpMyFAQ to version 4.0.17 or later immediately to patch the vulnerability
• Review web server logs for evidence of prior exploitation and potential data exposure
• If upgrade is not immediately possible, restrict access to API endpoints at the web server or firewall level
• Notify affected users if evidence suggests email addresses may have been harvested

Patch Information

The phpMyFAQ development team has addressed this vulnerability in version 4.0.17. The fix implements proper access control checks in the affected API endpoints and changes the default behavior to respect visibility flags. Organizations should update to this version or later to fully remediate the vulnerability.

For complete patch details, refer to the GitHub Security Advisory.

Workarounds

• Implement web server access controls (nginx/Apache) to restrict access to API endpoints to authenticated users only
• Configure a reverse proxy or WAF to block unauthenticated requests to sensitive API paths
• Disable unused API endpoints entirely if the FAQ application does not require API functionality
• Apply network-level access controls to limit API access to trusted IP ranges only

# Apache configuration example to restrict API access
<Location "/api/">
    Order deny,allow
    Deny from all
    # Allow only from trusted internal networks
    Allow from 10.0.0.0/8
    Allow from 192.168.0.0/16
</Location>