EUVD-2026-30592
GHSA-9r8r-x3vg-6xh4
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4DescriptionCVE.org
phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.
AnalysisAI
Authorization bypass in phpMyFAQ versions before 4.1.2 allows authenticated frontend users to access admin-only API endpoints and retrieve sensitive backend configuration data. The vulnerability stems from admin-api routes checking only login status (isLoggedIn) without verifying administrative privileges, enabling any valid user account to query dashboard versions, LDAP configuration details, Elasticsearch statistics, and health-check data. While this is an information disclosure issue rather than direct write access, it exposes internal infrastructure details useful for reconnaissance. The low CVSS score (4.3) reflects limited confidentiality impact, but defenders should prioritize remediation in environments where backend configuration exposure aids broader attack campaigns. Vendor patch available in version 4.1.2.
Technical ContextAI
phpMyFAQ is an open-source FAQ management system written in PHP. The vulnerability affects the authorization architecture in the Administration\Api controller namespace. The codebase implements two distinct access control methods in controller base classes: userIsAuthenticated() verifies only login status, while userHasPermission() performs role-based privilege checking. Multiple admin-api controllers (DashboardController, LdapController, ElasticsearchController, OpenSearchController, UpdateController) incorrectly use the weaker userIsAuthenticated() check despite serving administrative functions. This maps to CWE-863 (Incorrect Authorization), where authentication is present but insufficient for the sensitivity level of the resource. The affected endpoints use Symfony-style routing attributes with paths like '/admin/api/index.php/dashboard/versions', clearly indicating administrative intent. The CPE string cpe:2.3:a:thorsten:phpmyfaq identifies Thorsten Rinne as the vendor namespace. Both composer packages (thorsten/phpmyfaq and phpmyfaq/phpmyfaq) prior to 4.1.2 contain the flaw, with version 4.1.1 explicitly confirmed vulnerable.
RemediationAI
Upgrade immediately to phpMyFAQ version 4.1.2, which implements proper authorization checks in admin-api controllers by replacing userIsAuthenticated() calls with appropriate userHasPermission() role verification. Update via composer with 'composer update thorsten/phpmyfaq' or 'composer update phpmyfaq/phpmyfaq' depending on package namespace in use. Verify the patch by testing that regular user accounts can no longer access /admin/api/index.php/dashboard/versions or other admin endpoints (should return 401/403). If immediate patching is not feasible, implement compensating controls: (1) Apply web application firewall rules to block /admin/api/ paths for non-administrative source IPs, noting this breaks legitimate admin remote access and requires IP allowlisting; (2) Disable user registration if the FAQ system does not require public accounts, reducing attacker account acquisition; (3) Segment phpMyFAQ network access so that even with exposed LDAP/Elasticsearch configuration, attackers cannot reach those backend systems from the web tier. Monitor authentication logs for unusual patterns of admin-api endpoint access by non-privileged accounts. Full advisory and patch details: https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-jrc5-w569-h7h5.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the s
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execut
Remote code execution occurs in Apache Solr before 7.1 with Apache Lucene before 7.1 by exploiting XXE in conjunction wi
Directory traversal vulnerability in Elasticsearch before 1.6.1 allows remote attackers to read arbitrary files via unsp
Directory traversal vulnerability in Elasticsearch before 1.4.5 and 1.5.x before 1.5.2, when a site plugin is enabled, a
Kibana versions before 5.6.15 and 6.6.1 contain an arbitrary code execution flaw in the Timelion visualizer. Rated criti
Kibana versions 6.7.0 to 6.8.8 and 7.0.0 to 7.6.2 contain a prototype pollution flaw in the Upgrade Assistant. Rated hig
Kibana versions before 6.4.3 and 5.6.13 contain an arbitrary file inclusion flaw in the Console plugin. Rated critical s
opensearch-ruby is a community-driven, open source fork of elasticsearch-ruby. Rated high severity (CVSS 8.8), this vuln
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generat
A symbolic link following vulnerability in Buildkite Elastic CI for AWS versions prior to 6.7.1 and 5.22.5 allows the bu
All versions of Elastic Cloud Enterprise has the Elasticsearch “anonymous” user enabled by default in deployed clusters.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today