Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
110 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 their actual permissions. Details The parent class AbstractController::userHasPermission() (phpmyfaq/src/phpMyFAQ/Controller/AbstractController.php:317-327) correctly enforces authorization by throwing a ForbiddenException when the user lacks the required permission. This exception would normally propagate to Symfony's HttpKernel exception handler, which would return an error response and prevent the controller from continuing. However,…
Recommended action: Upgrade to 4.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored XSS vulnerability in the comment rendering pipeline allows an authenticated user to inject JavaScript that executes for every visitor of an affected FAQ or News page. An attacker with a registered account can steal admin session cookies and take over the application. Details Utils::parseUrl() (phpmyfaq/src/phpMyFAQ/Utils.php, line 281) converts URLs in comment text into clickable <a tags at render time: $pattern = '/(https?:\/\/[^\s]+)/i'; $replacement = '<a href="$1"$1</a'; return pregreplace($pattern, $replacement, $string); The regex [^\s]+ matches " and <, and the URL is inserted into the href attribute with no htmlspecialchars() call. A URL with a literal " closes the attribute early and allows injecting event handlers like onmouseover. This only reaches the sink when main.enableCommentEditor is enabled. In that path, comment text goes through sanitizeHtmlComment() instead of FILTERSANITIZESPECIALCHARS — which encodes " — so the double-quote survives to storage.…
Recommended action: Upgrade to 4.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, javascript: 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…
Recommended action: Upgrade to 4.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 4.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 "<scriptalert(1)</script"@evil.com. PHP's FILTERVALIDATEEMAIL 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. Details 1. PHP FILTERVALIDATEEMAIL accepts RFC-valid quoted local parts with dangerous characters phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/FaqController.php:99 $email = trim((string) Filter::filterVar($data-email, FILTERVALIDATEEMAIL)); PHP accepts "<scriptalert(1)</script"@evil.com as a valid email (RFC 5321 allows <, inside quoted local parts). Confirmed: "<scriptalert(1)</script"@evil.com = string (valid, not false) 2. Email stored raw without HTML sanitization phpmyfaq/src/phpMyFAQ/Faq.php — email retrieved directly as $row-email from…
Recommended action: Upgrade to 4.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details File: phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/WebAuthnController.php, lines 63-79 The endpoint: 1. Accepts any POST request with a JSON username field 2. If the username doesn't exist, creates a new active user account 3. Does NOT check if WebAuthn support is enabled (security.enableWebAuthnSupport) 4. Does NOT check if registration is enabled (security.enableRegistration) 5. Does NOT verify CSRF tokens 6. Does NOT require captcha validation 7. Has no rate limiting PoC Impact - Registration bypass: Accounts created even when self-registration is disabled - Username squatting: Reserve usernames before legitimate users - Database exhaustion: Create millions of fake active accounts (DoS) - User…
Recommended action: Upgrade to 4.0.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Several public API endpoints return email addresses and non‑public records (e.g. open questions with isVisible=false). Details OpenQuestionController::list() calls Question::getAll() with the default showAll=true, returning invisible questions and their emails. Similar exposures exist in comment/news/faq APIs. PoC Impact Privacy exposure of email addresses and non‑public content; increased risk of phishing/scraping.
Recommended action: Upgrade to 4.0.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authenticated non‑admin users can call /api/setup/backup and trigger a configuration backup. The endpoint only checks authentication, not authorization, and returns a link to the generated ZIP. Details SetupController.php uses userIsAuthenticated() but does not verify that the requester has configuration/admin permissions. This allows any logged‑in user to create a sensitive backup and retrieve its path. PoC Precondition: API enabled, any authenticated non‑admin user. - Log in as a non‑admin user. - Call backup endpoint. Impact Low‑privileged users can generate sensitive backups. If the ZIP is web‑accessible (server misconfiguration), this can lead to secret exposure.
Recommended action: Upgrade to 4.0.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A logged‑in user without the dlattachment right can download FAQ attachments. This is due to a permissive permission check in attachment.php that treats the mere presence of a right key as authorization and a flawed group/user logic expression. Details In attachment.php, the access decision uses: isset() returns true even when the right value is false, and the logic simplifies to $groupPermission for some permission modes. As a result, a user without dlattachment can still access the attachment. PoC Precondition: A non‑admin user exists; an attachment is associated to a FAQ record; records.allowDownloadsForGuests = false. Log in as a non‑admin user without dlattachment. Request the attachment download endpoint. Impact Unauthorized users can download attachments (confidentiality breach). Depending on content, this may expose sensitive documents.
Recommended action: Upgrade to 4.0.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated remote attacker can trigger generation of a configuration backup ZIP via POST /api/setup/backup and then download the generated ZIP from a web-accessible location. The ZIP contains sensitive configuration files (e.g., database.php with database credentials), leading to high-impact information disclosure and potential follow-on compromise. Details The endpoint /api/setup/backup is reachable via default rewrite rules and does not enforce authentication/authorization or API token verification. When called with any non-empty body (used as an “installed version” string), the server creates a ZIP archive inside the configuration directory and returns a direct URL to the generated ZIP file. Relevant code paths: - Rewrite rule exposing the endpoint: - phpmyfaq/.htaccess: RewriteRule ^api/setup/(check|backup|update-database) api/index.php [L,QSA] - Controller implementation: - phpmyfaq/src/phpMyFAQ/Controller/Api/SetupController.php → backup() - No call to…
Recommended action: Upgrade to 4.0.16; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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., <img ...>). 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. Details Root cause is the following chain: - User-controlled input stored: attacker-provided displayname (real name) is stored in DB (often as HTML entities, e.g., <img ...>). - Decode on read: phpmyfaq/src/phpMyFAQ/User/UserData.php decodes displayname using htmlentitydecode(...) (“for backward compatibility”). - Unsafe sink: admin user list renders the decoded value unescaped using Twig |raw: - phpmyfaq/assets/templates/admin/user/users.twig (users table uses {{ user.displayname|raw }}) As a result, an entity-encoded payload becomes active HTML/JS when rendered in the admin user list.…
Recommended action: Upgrade to 4.0.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The vulnerability exists in the save method within the src/phpMyFAQ/Controller/Administration/ConfigurationTabController.php controller. This method handles the saving of application-wide configuration settings. It retrieves all submitted form data as an associative array via $request-get('edit'). The core of the issue is that while the values of this array are processed, the keys are trusted implicitly and are not sanitized or validated. File: src/phpMyFAQ/Controller/Administration/ConfigurationTabController.php The $newConfigValues array, which…
Recommended action: Upgrade to 4.0.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details An account management logic flaw in phpMyFAQ allows attackers to register multiple accounts under the same email address. If email is used for password reset or administrative flows, this may result in account takeover, loss of accountability, and abuse of business logic. PoC 1.Register a user with email test@example.com 2.Register another user with the same email. 3.Both accounts appear in /admin/?action=user&useraction=listallusers. <img width="1150" height="628" alt="image" src="https://github.com/user-attachments/assets/8c19f01a-e897-4ca7-b3f8-fcf83e6ff952" / Impact -Data integrity…
Recommended action: Upgrade to 4.0.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability exists in the FAQ Record component where a privileged attacker can trigger a file download on a victim's machine upon page visit by embedding it in an <iframe element without user interaction or explicit consent. Details In http://localhost/admin/index.php?action=editentry&id=20&lang=en, where a FAQ record is either created or edited, an attacker can insert an iframe, as "source code", pointing to a prior "malicious" attachment that the attacker has uploaded via FAQ "new attachment" upload, such that any page visits to this FAQ will trigger an automated download (from the edit screen, download is automated; from the faq page view as a normal user, depending on the browser, a pop up confirmation may be presented before the actual download. Firebox browser, for instance, does not require any interactions). PoC 1. create a new FAQ record and upload a "malicious" file - in my case, I uploaded an eicar file. take note of the uri, ie <p<iframe…
Recommended action: Upgrade to 3.2.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Exposure of database (ie postgreSQL) server's credential when connection to DB fails. Details Exposed database credentials upon misconfig/DoS @ permalink: https://github.com/thorsten/phpMyFAQ/blob/main/phpmyfaq/src/phpMyFAQ/Setup/Installer.php#L694 PoC When postgreSQL server is unreachable, an error would be thrown exposing the credentials of the database. For instance, when "http://<phpmyfaq-instance:8080/setup/index.php" is hit when the database instance/server is down, then credentials are exposed, for instance: A way to force this would be to perform a denial of service on the database instance/server. When the db connection is refused, the credentials would show. The remote attacker can then use that to gain full control on the database. Impact This vulnerability exposes the credentials of the database and grants a remote attacker full control over the database. First notified Snyk on 16 Jan 2024.
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.
Recommended action: Upgrade to 3.1.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.
Recommended action: Upgrade to 3.1.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.2.1.
Recommended action: Upgrade to 3.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.2.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.1.
Recommended action: Upgrade to 3.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.2.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18.
Recommended action: Upgrade to 3.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unrestricted Upload of File with Dangerous Type in GitHub repository thorsten/phpmyfaq prior to 3.1.18.
Recommended action: Upgrade to 3.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18.
Recommended action: Upgrade to 3.1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.