| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Cross-site scripting (XSS) vulnerability in phpMyFAQ before 2.0.17 and 2.5.x before 2.5.2, when used with Internet Explorer 6 or 7, allows remote attackers to inject arbitrary web script or HTML via unspecified parameters to the search page. |
| Unspecified vulnerability in phpMyFAQ 1.6.9 and earlier, when register_globals is enabled, allows remote attackers to "gain the privilege for uploading files on the server." |
| SQL injection vulnerability in phpMyFAQ 1.6.7 and earlier allows remote attackers to execute arbitrary SQL commands via unspecified vectors, possibly the userfile or filename parameter. |
| Unspecified vulnerability in phpMyFAQ 1.6.7 and earlier allows remote attackers to upload arbitrary PHP scripts via unspecified vectors. |
| phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below have flawed authorization logic which exposes the /api/setup/backup endpoint to any authenticated user despite their permissions. SetupController.php uses userIsAuthenticated() but does not verify that the requester has configuration/admin permissions. Non-admin users can trigger a configuration backup and retrieve its path. The endpoint only checks authentication, not authorization, and returns a link to the generated ZIP. This issue is fixed in version 4.0.17. |
| phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below allow an authenticated user without the dlattachment permission to download FAQ attachments due to a incomprehensive permissions check. The presence of a right key is improperly validated as proof of authorization in attachment.php. Additionally, the group and user permission logic contains a flawed conditional expression that may allow unauthorized access. This issue has been fixed in version |
| phpMyFAQ is 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, with similar exposures present in comment, news, and FAQ APIs. This information disclosure vulnerability could enable attackers to harvest email addresses for phishing campaigns or access content that was explicitly marked as private. This issue has been fixed in version 4.0.17. |
| phpMyFAQ is an open source FAQ web application. Prior to version 4.0.18, the WebAuthn prepare endpoint (`/api/webauthn/prepare`) creates new active user accounts without any authentication, CSRF protection, captcha, or configuration checks. This allows unauthenticated attackers to create unlimited user accounts even when registration is disabled. Version 4.0.18 fixes the issue. |
| phpMyFAQ 1.4.0 allows remote attackers to access the Image Manager to upload or delete images without authorization via a direct request. |
| Directory traversal vulnerability in index.php in PhpMyFaq 1.5.1 allows remote attackers to read arbitrary files or include arbitrary PHP files via a .. (dot dot) in the LANGCODE parameter, which also allows direct code injection via the User Agent field in a request packet, which can be activated by using LANGCODE to reference the user tracking data file. |
| Cross-site scripting (XSS) vulnerability in the "add content" page in phpMyFAQ 1.5.3 and earlier allows remote attackers to inject arbitrary web script or HTML via the (1) thema, (2) username, and (3) usermail parameters. |
| PhpMyFaq 1.5.1 allows remote attackers to obtain sensitive information via a LANGCODE parameter that does not exist, which reveals the path in an error message. |
| Multiple cross-site scripting (XSS) vulnerabilities in PhpMyFaq 1.5.1 allow remote attackers to inject arbitrary web script or HTML via the (1) PMF_CONF[version] parameter to footer.php or (2) PMF_LANG[metaLanguage] to header.php. |
| SQL injection vulnerability in password.php in PhpMyFaq 1.5.1 allows remote attackers to modify SQL queries and gain administrator privileges via the user field. |
| SQL injection vulnerability in phpMyFAQ 1.4 and 1.5 allows remote attackers to add FAQ records to the database via the username field in forum messages. |
| Directory traversal vulnerability in phpMyFAQ 1.3.12 allows remote attackers to read arbitrary files, and possibly execute local PHP files, via the action variable, which is used as part of a template filename. |
| Directory traversal vulnerability in phpMyFAQ 1.4.0 alpha allows remote attackers to read arbitrary files, and possibly execute local PHP files, via .. sequences in the lang (language) variable. |
| PhpMyFaq 1.5.1 stores data files under the web document root with insufficient access control and predictable filenames, which allows remote attackers to obtain sensitive information via a direct request to the data/tracking[DATE] file. |
| phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, an unauthenticated attacker can submit a guest FAQ with an email address that is syntactically valid per RFC 5321 (quoted local part) yet contains raw HTML — for example "<script>alert(1)</script>"@evil.com. PHP's FILTER_VALIDATE_EMAIL accepts this email as valid. The email is stored in the database without HTML sanitization and later rendered in the admin FAQ editor template using Twig's |raw filter, which bypasses auto-escaping entirely. This issue has been patched in version 4.1.1. |
| phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the MediaBrowserController::index() method handles file deletion for the media browser. When the fileRemove action is triggered, the user-supplied name parameter is concatenated with the base upload directory path without any path traversal validation. The FILTER_SANITIZE_SPECIAL_CHARS filter only encodes HTML special characters (&, ', ", <, >) and characters with ASCII value < 32, and does not prevent directory traversal sequences like ../. Additionally, the endpoint does not validate CSRF tokens, making it exploitable via CSRF attacks. This issue has been patched in version 4.1.1. |
