Thorsten Phpmyfaq vulnerabilities, page 5

105 vulnerabilities

Known vulnerabilities in Thorsten Phpmyfaq, newest first, with CVSS severity, EPSS, KEV listings, ransomware use and the affected versions.

8.8HighCVE-2026-75918phpmyfaq +1 morephpMyFAQ before 4.1.7 Authentication Bypass via Tracking FilephpMyFAQ before 4.1.7 stores password reset tokens in a publicly accessible tracking file when user tracking is enabled. Unauthenticated attackers can read the tracking file at content/core/data/trackingDDMMYYYY to extract reset tokens and replay them against the password reset API to take over user accounts.EPSS0.49%6.9MediumCVE-2026-75919phpmyfaq +1 morephpMyFAQ before 4.1.7 Authentication Bypass via Setup APIphpMyFAQ before 4.1.7 contains an authentication bypass vulnerability in SetupController that allows unauthenticated attackers to run database migrations and create configuration backups when maintenance mode is enabled. Attackers can call POST /api/setup/update-database and POST /api/setup/backup endpoints to execute database updates, disable maintenance mode, and extract database credentials from generated ZIP archives.EPSS0.55%9.3CriticalCVE-2026-45010thorsten · phpmyfaqphpMyFAQ - Unauthenticated Two-Factor Authentication Brute-Force via /admin/check EndpointphpMyFAQ before 4.1.2 contains an improper restriction of excessive authentication attempts vulnerability in the /admin/check endpoint, which accepts arbitrary user-id parameters without session binding or rate limiting. Unauthenticated attackers can brute-force any user's six-digit TOTP code by submitting POST requests with sequential token values, bypassing two-factor authentication to gain full administrative access.EPSS0.57%5.3MediumCVE-2026-45009thorsten · phpmyfaqphpMyFAQ - Insufficient Authorization Check in Admin API EndpointsphpMyFAQ 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.EPSS0.28%5.3MediumCVE-2026-45007thorsten · phpmyfaqphpMyFAQ - Missing Permission Check on 12 Configuration API Endpoints Allows Information DisclosurephpMyFAQ before 4.1.2 contains missing permission checks in ConfigurationTabController.php where 12 endpoints use userIsAuthenticated() instead of userHasPermission(CONFIGURATION_EDIT). Any authenticated user can enumerate system configuration metadata including permission model, cache backend, mail provider, and translation provider by querying /admin/api/configuration endpoints, violating least privilege access control.EPSS0.28%7HighCVE-2026-45008thorsten · phpmyfaqphpMyFAQ - Path Traversal in Client::deleteClientFolder via URL ParameterphpMyFAQ before 4.1.2 contains a path traversal vulnerability in Client::deleteClientFolder that allows admins with INSTANCE_DELETE permission to delete arbitrary directories. Attackers can submit traversal sequences like https://../../../<path> in the client URL parameter to recursively delete directories outside the intended clientFolder scope.EPSS0.48%6.5MediumCVE-2026-49205thorsten · phpmyfaqphpMyFAQ: Missing userHasPermission() in 4 API write endpoints (CVE-2026-24421 Incomplete Fix)phpMyFAQ is an open source FAQ web application. Versions prior to 4.1.4 have Missing Authorization in the API CategoryController. CVE-2026-24421 addressed this in the BackupController by adding: $this->userHasPermission(PermissionType::BACKUP). The same fix was not applied to 4 other write endpoints in the public API. All 4 only call $this->hasValidToken() — which checks a shared API key header, rather than the individual user's role permissions. The following APIs are affected: POST /api/v4.0/category (CategoryController::create), POST /api/v4.0/faq (FaqController::create), PUT /api/v4.0/faq (FaqController::update), and POST /api/v4.0/question (QuestionController::create). This issue has been fixed in version 4.1.4.EPSS0.39%6.1MediumCVE-2026-32629phpmyfaq +1 morephpMyFAQ: Stored XSS via Unsanitized Email Field in Admin FAQ EditorphpMyFAQ 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.EPSS0.30%6.9MediumCVE-2026-34973phpmyfaq +1 morephpMyFAQ has a LIKE Wildcard Injection in Search.php — Unescaped % and _ Metacharacters Enable Broad Content DisclosurephpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the searchCustomPages() method in phpmyfaq/src/phpMyFAQ/Search.php uses real_escape_string() (via escape()) to sanitize the search term before embedding it in LIKE clauses. However, real_escape_string() does not escape SQL LIKE metacharacters % (match any sequence) and _ (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records — including content that was not meant to be surfaced — resulting in information disclosure. This issue has been patched in version 4.1.1.EPSS0.39%6.1MediumCVE-2026-34729phpmyfaq +1 morephpMyFAQ: Stored XSS via Regex Bypass in Filter::removeAttributes()phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, there is a stored XSS vulnerability via Regex Bypass in Filter::removeAttributes(). This issue has been patched in version 4.1.1.EPSS0.29%8.7HighCVE-2026-34728phpmyfaq +1 morephpMyFAQ: Path Traversal - Arbitrary File Deletion in MediaBrowserControllerphpMyFAQ 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.EPSS0.79%5.4MediumCVE-2026-34974phpmyfaq +1 morephpMyFAQ: SVG Sanitizer Bypass via HTML Entity Encoding leads to Stored XSS and Privilege EscalationphpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the regex-based SVG sanitizer in phpMyFAQ (SvgSanitizer.php) can be bypassed using HTML entity encoding in javascript: URLs within SVG <a href> attributes. Any user with edit_faq permission can upload a malicious SVG that executes arbitrary JavaScript when viewed, enabling privilege escalation from editor to full admin takeover. This issue has been patched in version 4.1.1.EPSS0.26%8.8HighCVE-2026-35676thorsten · phpmyfaqphpMyFAQ - Unauthenticated Password Reset via User Password Update EndpointphpMyFAQ before 4.1.3 contains an unauthenticated password reset vulnerability in the user password update API endpoint that allows attackers to change account passwords without token validation. Attackers can enumerate valid username and email pairs and force immediate password changes by sending PUT requests to the /api/index.php/user/password/update endpoint, causing account disruption and invalidating legitimate user credentials.EPSS0.33%8.7HighCVE-2026-35672thorsten · phpmyfaqphpMyFAQ - Authentication Bypass via Empty API TokenphpMyFAQ before 4.1.3 contains an authentication bypass vulnerability in API v4.0 where the default empty api.apiClientToken allows unauthenticated users to create and modify FAQ entries. Attackers can send an empty x-pmf-token header to bypass token validation and inject malicious content via POST endpoints /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question.EPSS0.56%8.8HighCVE-2026-35675thorsten · phpmyfaqphpMyFAQ - Authentication Bypass via Missing Password Reset Token in /api/user/password/updatephpMyFAQ before 4.1.3 contains an authentication bypass vulnerability in the password reset endpoint that allows unauthenticated attackers to reset any user account password without token verification or email confirmation. Attackers can enumerate valid usernames, obtain plaintext passwords via email, and achieve complete account takeover including administrative access.EPSS0.46%8.8HighCVE-2026-35671thorsten · phpmyfaqphpMyFAQ - Insecure Direct Object Reference in User Password APIphpMyFAQ before 4.1.3 contains an insecure direct object reference vulnerability in the admin API user password endpoint that allows authenticated administrators to change any user's password without authorization verification. An attacker with low-privilege admin credentials can escalate to SuperAdmin by modifying the userId parameter in the overwrite-password API request.EPSS0.44%5.3MediumCVE-2026-85588thorsten · phpmyfaqphpMyFAQ before 4.1.8 TOTP Secret Exposure via Data ExportphpMyFAQ versions before 4.1.8 include live TOTP shared secrets in plaintext within user data export ZIP files. Attackers obtaining exported archives can extract the TOTP seed and generate valid one-time codes to bypass two-factor authentication.EPSS0.53%5.3MediumCVE-2026-85587thorsten · phpmyfaqphpMyFAQ before 4.1.8 Incorrect Authorization via Admin PagesphpMyFAQ before 4.1.8 enforces incorrect permission checks on admin content pages, allowing lesser-privileged editors to read draft and inactive content. Attackers with only add permissions can access news edit and FAQ translate endpoints to view unpublished content invisible to the public.EPSS0.36%7.1HighCVE-2026-85590thorsten · phpmyfaqphpMyFAQ before 4.1.8 Authentication Bypass via Two-Factor DisablephpMyFAQ before 4.1.8 contains an authentication bypass vulnerability in its two-factor authentication (TOTP) disable functionality. The removeTwofactorConfig() handler (reachable via POST /api/user/remove-twofactor) verifies only that the user is logged in and that a valid CSRF token is supplied, then disables TOTP without requiring password re-entry or a current TOTP code. The same downgrade is also reachable inline via PUT /api/user/data/update, which accepts a plain twofactor_enabled form field under the same session+CSRF-only guard. An attacker who has hijacked a user's session can silently strip two-factor protection from any account, including administrator accounts, after which password-only authentication succeeds.EPSS0.52%7.1HighCVE-2026-85591thorsten · phpmyfaqphpMyFAQ before 4.1.8 Authentication Bypass via Unverified Password ChangephpMyFAQ versions before 4.1.8 contain an authentication bypass vulnerability in the user control panel API endpoint that allows authenticated attackers to change account passwords without verifying the current password. Attackers with session access can submit a PUT request to the user data update endpoint with only a CSRF token to silently change any user's password, including administrators, causing irreversible account takeover and victim lockout.EPSS0.52%