Threats affecting pkg:github/thorsten/phpmyfaq

phpMyFAQ before 4.1.10 contains an object-level authorization bypass vulnerability that allows unauthenticated attackers to modify or delete any visitor question by supplying an arbitrary openQuestionID to POST /api/faq/create. Attackers solving the CAPTCHA can rewrite question categories, forge answered entries in faqquestion_history, or permanently delete questions when records.enableDeleteQuestion is enabled.

phpMyFAQ before 4.1.10 contains a server-side request forgery vulnerability in the PDF export feature that fetches external images referenced in FAQ answers. Attackers who can influence FAQ content can embed image URLs pointing to loopback or internal services, causing the server to request them and embed responses in generated PDFs.

phpMyFAQ versions 4.0.0 through before 4.1.9 contain an authentication bypass vulnerability in the WebAuthn registration endpoints. This flaw allows attackers to attach credentials to any account without proper authentication or challenge validation. Exploitation enables attackers to register a passkey for a victim's username using a forged attestation and subsequently log in without needing passwords or TOTP, leading to account takeover.

phpMyFAQ versions before 4.1.9 and between 4.2.0-alpha and 4.2.0-beta contain an authorization bypass vulnerability in attachment.php. This flaw allows low-privileged users with the dlattachment right, or anonymous users if allowDownloadsForGuests is enabled, to download attachments from restricted FAQs by bypassing per-record permission checks. The vulnerability has a high severity with a CVSS score of 7.1.

phpMyFAQ versions prior to 4.1.9 have a missing authorization vulnerability in the deleteUser() API. Authenticated users with delete_user permission but without superadmin privileges can delete superadmin accounts by sending a crafted DELETE request. This flaw allows removal of administrative accounts other than the default superadmin user with ID 1, potentially disrupting administrative control.

phpMyFAQ versions 4.0.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta have an authorization bypass vulnerability in the API endpoint for updating FAQs. Authenticated users with the edit_faq permission can modify restricted FAQs they should not have access to by supplying the ID of those FAQs, bypassing object-level access controls. This allows unauthorized modification of FAQ content and publication state.

phpMyFAQ versions 4.0.0 up to but not including 4.1.9 contain a cross-site request forgery (CSRF) vulnerability in the POST /admin/api/update-database endpoint. This endpoint executes database migrations without validating a CSRF token, allowing an attacker to trick a logged-in user with CONFIGURATION_EDIT permission into triggering unintended database migrations. This can affect database integrity or availability.

phpMyFAQ versions before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contain a cross-site request forgery (CSRF) vulnerability in the Elasticsearch and OpenSearch administration API endpoints. These endpoints do not validate CSRF tokens for create, drop, and import actions. An attacker can trick a user with CONFIGURATION_EDIT permission into visiting a malicious page that triggers these actions, potentially deleting search indexes, forcing re-indexing, or exhausting resources.

phpMyFAQ versions 3.2.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta have an authorization bypass vulnerability. This flaw allows delegated administrators with user-management rights to access any user's full faquserdata, including the live TOTP secret, without proper SuperAdmin or protected-target checks. As a result, they can generate valid two-factor authentication codes and bypass 2FA protections.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain an information disclosure vulnerability. This flaw allows unauthenticated attackers to access hidden open questions and associated usernames by exploiting an inverted check in the OpenQuestionController API endpoint. The vulnerability enables unauthorized reading of non-public moderation or internal questions via GET requests to /api/v4.0/open-questions.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain a stored cross-site scripting (XSS) vulnerability in the SvgSanitizer component. This flaw allows users with FAQ_EDIT permission to bypass SVG sanitization by using XML DTD custom entities, enabling injection of JavaScript in anchor href attributes. When other users view the malicious SVG and click the link, the script executes, potentially hijacking admin sessions.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain an authorization bypass vulnerability. This flaw occurs in the isFaqAccessibleForUser() function, where missing FAQ translations are incorrectly treated as accessible to unauthenticated users. Attackers can exploit this by sending mismatched Accept-Language headers to API endpoints for comments and attachments, allowing them to view comments and attachment listings of unpublished or access-controlled FAQs.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta have an uncontrolled resource consumption vulnerability in the unauthenticated FAQs and search API endpoints. Attackers can send concurrent GET requests that cause the server to load and process all database records into PHP memory, potentially exhausting CPU and memory resources and crashing the server. This vulnerability has a high severity with a CVSS score of 8.7. No patch or official fix information is provided in the available data.

phpMyFAQ versions before 4.1.9 and between 4.2.0-alpha and 4.2.0-beta contain an improper authorization vulnerability in attachment.php. This flaw allows authenticated users with the dlattachment permission to download attachments belonging to draft FAQs that should not be visible to them.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain an authentication bypass vulnerability. This flaw allows attackers controlling a Keycloak identity with a matching preferred_username or unverified email to log in as local users and escalate to superadmin privileges. The vulnerability is exploitable via the /auth/keycloak/authorize endpoint.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain an authorization bypass vulnerability. This flaw allows category-restricted editors with medium permissions to manage attachments of FAQs outside their authorized categories by manipulating record or attachment IDs. Attackers can upload or delete files on unauthorized FAQs, potentially tampering with or removing files without proper authorization.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain a stored cross-site scripting (XSS) vulnerability in the SvgSanitizer component. This flaw allows FAQ editors to store executable SVG files by exploiting how script tags can be split around removed tokens, enabling script execution when victims open the affected files. The vulnerability has a medium severity rating with a CVSS 4.0 score of 5.1.

phpMyFAQ versions 3.2.0 before 4.0.0 and 4.0.2 before 4.2.0-beta contain an authentication bypass vulnerability in the Microsoft Entra ID login flow. The issue arises because the system links users by the mutable preferred_username claim and the AuthEntraId::create() function ignores duplicate-login exceptions, allowing attackers controlling an Entra identity with a matching preferred_username to take over local accounts, including super-admin accounts.

phpMyFAQ versions 3.2.1 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contain a stored cross-site scripting (XSS) vulnerability. Authenticated content authors can inject malicious JavaScript by embedding iframes with data:text/html sources in FAQ or News content. This bypasses the hostless media-host allowlist in the content sanitization function, leading to potential phishing or top-frame redirect attacks for users viewing the content.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain a privilege escalation vulnerability. Delegated administrators with category restrictions can exploit this flaw to assign categories outside their allowed scope, effectively granting unrestricted category access to groups. This occurs via a POST request to /admin/api/group/category-restrictions with out-of-scope or empty categoryIds.