Advisories for Composer/Thorsten/Phpmyfaq package

2026

phpMyFAQ's Missing CONFIGURATION_EDIT Permission Check on 12 Admin API Configuration Tab Endpoints Allows Information Disclosure by Any Authenticated User

12 endpoints in ConfigurationTabController.php use userIsAuthenticated() (login-only check) instead of userHasPermission(PermissionType::CONFIGURATION_EDIT). This allows any authenticated user — including ones with zero admin permissions — to enumerate system configuration metadata including the permission model, active template, cache backend, mail provider, and translation provider.

phpMyFAQ's Missing Authorization on Tag Deletion Allows Any Authenticated User to Delete Tags

The TagController::delete() endpoint at DELETE /admin/api/content/tags/{tagId} only verifies that the user is logged in (userIsAuthenticated()), but does not check any permission. Any authenticated user — including regular non-admin frontend users — can delete any tag by ID. This contrasts with TagController::update() and TagController::search(), which both enforce the FAQ_EDIT permission.

phpMyFAQ: Path Traversal in Client::deleteClientFolder enables arbitrary directory deletion by non-super-admin admins

Client::deleteClientFolder() in phpmyfaq/src/phpMyFAQ/Instance/Client.php:583 takes a URL from the caller, strips the https:// prefix, and passes the remainder to Filesystem::deleteDirectory() relative to the multisite clientFolder. No path-traversal validation runs. An admin with the INSTANCE_DELETE permission (a role short of SUPER_ADMIN) submits https://../../../<path> as the client URL and the server recursively deletes arbitrary directories under the web user's rights. Same pattern and reachability as GHSA-38m8-xrfj-v38x, which the project accepted at High severity …

phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check in phpMyFAQ

A review of phpMyFAQ-main uncovered an authorization issue in the admin-api routes. Several backend endpoints only check whether the caller is logged in. They do not verify that the caller actually has backend or administrative privileges. As a result, a normal frontend user can access API endpoints that are clearly intended for administrative use. During local reproduction, a regular user account was able to request /admin/api/index.php/dashboard/versions and receive a successful …

phpMyFAQ has unauthenticated SQL injection via User-Agent header in BuiltinCaptcha

BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha() at phpmyfaq/src/phpMyFAQ/Captcha/BuiltinCaptcha.php:298 and :330 interpolate the User-Agent header and client IP address into DELETE and INSERT queries with sprintf and no escaping. Both methods run on every hit to the public GET /api/captcha endpoint, which requires no authentication. An unauthenticated attacker sets the User-Agent header to a crafted SQL payload and runs SLEEP(), BENCHMARK(), or time-based blind extraction against the database that backs phpMyFAQ. Verified live against …

phpMyFAQ has unauthenticated FAQ permission bypass via getFaqBySolutionId fallback query

The public /solution_id_{id}.html route calls Faq::getIdFromSolutionId() in phpmyfaq/src/phpMyFAQ/Faq.php:1312. That query joins faqdata with faqcategoryrelations solely by solution_id and returns the matching FAQ's id, lang, thema (title), and category_id with no permission filter. An unauthenticated visitor hits the route with a sequential integer and the server 301-redirects to /content/<category>/<id>/<lang>/<title-slug>.html, leaking the FAQ's existence, internal id, language, category binding, and title via the redirect's Location header and the redirected page's canonical link, …

phpMyFAQ has stored XSS via | raw Filter in search.twig — html_entity_decode(strip_tags()) Bypass in Search Result Rendering

The search result rendering template (search.twig) outputs FAQ content fields result.question and result.answerPreview using Twig's | raw filter, which completely disables the template engine's built-in auto-escaping. A user with FAQ editor/contributor privileges can store a payload encoded as HTML entities. During search result construction, html_entity_decode(strip_tags(…)) restores the raw HTML tags — bypassing strip_tags() — and the restored payload is injected into every visitor's browser via the | raw output. This …

phpMyFAQ has Stored XSS in FAQ Question/Answer via Encode-Decode Bypass of removeAttributes() Sanitization

The FAQ creation and update endpoints in phpMyFAQ apply FILTER_SANITIZE_SPECIAL_CHARS (which HTML-encodes input), then immediately call html_entity_decode() which reverses the encoding, followed by Filter::removeAttributes() which only strips HTML attributes — not tags. This allows <script>, <iframe>, <object>, and <embed> tags to be stored in the database and rendered unescaped via {{ answer|raw }} and {{ question|raw }} in the Twig template, causing JavaScript execution in every visitor's browser.

phpMyFAQ has SQL Injection in CurrentUser::setTokenData through unescaped OAuth token fields

CurrentUser::setTokenData() in phpmyfaq/src/phpMyFAQ/User/CurrentUser.php at lines 515-534 builds a SQL UPDATE statement with sprintf and interpolates OAuth token fields (refresh_token, access_token, code_verifier, and json_encode($token['jwt'])) without calling $db->escape(). Sibling methods setAuthSource() and setRememberMe() in the same file do call $db->escape() on user-controlled values, so the omission is local to this method. An attacker (Bob) whose Azure AD display name contains a single quote (for example O'Brien, or a deliberate SQL payload) breaks …

phpMyFAQ has an Authorization Bypass in All Admin Pages Due to Non-Terminating Permission Check

AbstractAdministrationController::userHasPermission() catches the ForbiddenException thrown when a user lacks a specific permission, sends a "forbidden" HTML page via $response->send(), but does not terminate execution. The calling controller method continues to execute, fetches protected data, renders the full template, and returns it as a Response. The final $response->send() in admin/index.php outputs the protected page content after the forbidden page, leaking all permission-protected admin data to any authenticated admin user regardless of …

phpMyFAQ has a SVG Sanitizer Entity Decoding Depth Limit Bypass Leading to Stored XSS

The SvgSanitizer::decodeAllEntities() method limits recursive entity decoding to 5 iterations. By wrapping each character of javascript in an href attribute value with 5 levels of &amp; encoding around numeric HTML entities (e.g., &amp;amp;amp;amp;amp;#106; for j), an attacker can bypass both isSafe() detection and sanitize() removal. The uploaded SVG is served from the application origin with image/svg+xml content type, and the browser's XML parser fully decodes the remaining &#NNN; entities, resulting …

phpMyFAQ enables unauthenticated 2FA brute-force attack via /admin/check acceptance of arbitrary user-id

The /admin/check endpoint in AuthenticationController implements SkipsAuthenticationCheck, making it reachable without any prior authentication. An anonymous attacker (Bob) can POST arbitrary user-id and token values to brute-force any user's 6-digit TOTP code. No rate limiting exists. The 10^6 keyspace is exhaustible in minutes. Reachability confirmed against a default install: unauthenticated POST /admin/check with a user-id body field returns HTTP 302 to /admin/token?user-id=<value>, echoing the attacker-supplied user id without any binding …

phpMyFAQ has a LIKE Wildcard Injection in Search.php — Unescaped % and _ Metacharacters Enable Broad Content Disclosure

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.

phpMyFAQ is Vulnerable to Stored XSS via Unsanitized Email Field in Admin FAQ Editor

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 "alert(1)"@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.

2025

phpMyFAQ has Stored XSS in user list via admin-managed display_name

A stored cross-site scripting (XSS) vulnerability allows an attacker to execute arbitrary JavaScript in an administrator’s browser by registering a user whose display name contains HTML entities (e.g., &lt;img …&gt;). When an administrator views the admin user list, the payload is decoded server-side and rendered without escaping, resulting in script execution in the admin context.

phpMyFAQ contains a CSV injection vulnerability

phpMyFAQ 3.1.12 contains a CSV injection vulnerability that allows authenticated users to inject malicious formulas into their profile names. Attackers can modify their user profile name with a payload like 'calc|a!z|' to trigger code execution when an administrator exports user data as a CSV file.

phpMyFAQ has Authenticated SQL Injection in Configuration Update Functionality

An authenticated SQL injection vulnerability in the main configuration update functionality of phpMyFAQ (v4.0.13 and prior) allows a privileged user with 'Configuration Edit' permissions to execute arbitrary SQL commands. Successful exploitation can lead to a full compromise of the database, including reading, modifying, or deleting all data, as well as potential remote code execution depending on the database configuration.

phpMyFAQ duplicate email registration allows multiple accounts with the same email

phpMyFAQ does not enforce uniqueness of email addresses during user registration. This allows multiple distinct accounts to be created with the same email. Because email is often used as an identifier for password resets, notifications, and administrative actions, this flaw can cause account ambiguity and, in certain configurations, may lead to privilege escalation or account takeover.

phpMyFAQ Vulnerable to Stored HTML Injection at FAQ

Due to insufficient validation on the content of new FAQ posts, it is possible for authenticated users to inject malicious HTML or JavaScript code that can impact other users viewing the FAQ. This vulnerability arises when user-provided inputs in FAQ entries are not sanitized or escaped before being rendered on the page.

2024
2023

phpMyFAQ Improper Access Control vulnerability

phpMyFAQ prior to version 3.1.13 does not properly validate email addresses when updating user profiles. This vulnerability allows an attacker to manipulate their email address and change it to another email address that is already registered in the system, including email addresses belonging to other users such as the administrator. Once the attacker has control of the other user's email address, they can request to remove the user from the …

2022