Security Advisory 2026-10-03

Multiple vulnerabilities in phpMyFAQ

Issued on:

2026-10-03

Software:

phpMyFAQ <= 4.1.8

Risk:

Critical

Platforms:

all

The phpMyFAQ Team has learned of security issues that'd been discovered in phpMyFAQ 4.1.8 and earlier.

Description

Critical severity

The WebAuthn enrollment endpoint can be called without an authenticated session, so an attacker who knows a username can register their own security key for that account and log in as the account owner. The WebAuthn registration flow never validates the challenge returned by the client and accepts attestations with fmt=none, allowing an unauthenticated attacker to inject a credential into any known account and take it over, bypassing both password and TOTP verification.

High severity

Single sign-on logins through Keycloak and Microsoft Entra ID complete the session directly and skip the one-time token step, so two-factor authentication is not enforced for SSO users. Microsoft Entra ID logins are matched to local accounts by the mutable preferred_username claim instead of an immutable subject identifier, so a directory account renamed to an existing phpMyFAQ username takes over that account. Keycloak logins implicitly link to a pre-existing local account with the same user name, allowing takeover of that account. The user control panel changes the e-mail address of an account without asking for the current password, so an attacker with temporary access to a logged-in session can redirect the password-reset mail and take over the account permanently. This also defeats the fix for GHSA-6r2c-rfg8-9hww. Editors restricted to specific categories can add, replace, and delete attachments of FAQs outside the categories they are allowed to work in. Attachment downloads evaluate the guest download flag before the record ACLs, so visibility restrictions on a FAQ do not apply to its attachments. The admin endpoint GET /admin/api/user/data/{userId} performs no object-level authorization and returns the live TOTP secret of other users, allowing an administrator to generate valid second factors for a SuperAdmin account. FAQ updates are not checked against object-level authorization, so a user may modify FAQ records they have no permission for. A user manager without SuperAdmin permissions can delete SuperAdmin accounts. The database update endpoint /admin/api/update-database is not CSRF protected, so a visited web page can trigger database migrations in the name of a logged-in administrator. The API pagination parameters are not bounded, so unauthenticated requests can exhaust the memory and CPU of the server. Frontend FAQ submissions are stripped of HTML tags but not of HTML entities, which are decoded afterward and rendered unsanitized, resulting in stored cross-site scripting in the administration. The PDF export follows redirects when fetching remote resources, enabling server-side request forgery, and the attachment handling can be tricked into returning attachments without applying the configured encryption.

Moderate severity

The deleteGroup API checks only for the GROUP_DELETE right, so a delegated administrator can delete groups of higher-privileged users. The endpoint that removes two-factor authentication has no brute-force lockout, which is a residual gap of the fix for CVE-2026-76213. Guest comment creation answers with a distinct HTTP 409 for existing accounts, allowing unauthenticated enumeration of registered users. The admin dashboard page requires only a login instead of the corresponding permissions and discloses unpublished FAQs and recently created accounts to any authenticated user. updateUserRights drops the per-right language restrictions when a right is granted again, so an administrator with USER_EDIT can widen a scoped right. The group permission API grants rights without preserving their language and category scope, so an administrator with GROUP_EDIT can widen the scope of a right. Group category restrictions are applied without validating the scope of the acting delegated administrator, allowing privilege escalation. The password reset endpoints have no effective rate limiting. The HTML sanitizer allows <iframe src="data:text/html,...">, resulting in stored cross-site scripting. SvgSanitizer::sanitize() reassembles <script> elements and still reports success, so a user with FAQ_EDIT can store an executable SVG. The SVG sanitizer can be bypassed with DTD entities, resulting in stored cross-site scripting. Users with the attachment download permission can access draft FAQ records. isFaqAccessibleForUser() treats a missing translation as visible, so comments of unpublished FAQs can be read by choosing a different Accept-Language header. The public open questions API returns questions that are marked as hidden. The Elasticsearch and OpenSearch index endpoints are not CSRF protected, so a visited web page can drop or rebuild the search index in the name of a logged-in administrator.

Low severity

PUT /admin/api/news/update accepts the NEWS_DELETE permission where NEWS_EDIT is required.

Solution

The phpMyFAQ Team has released the new phpMyFAQ versions 4.1.9 and 4.2.0-beta, which fix these vulnerabilities. All users of affected phpMyFAQ versions are encouraged to upgrade as soon as possible to one of these versions.

Workaround

There's no workaround except installing phpMyFAQ 4.1.9 or 4.2.0-beta.

Thanks

The phpMyFAQ team would like to thank 4n86rakam1, baeseungwon1010, bp0lr, David Vieira Kurz, euriconicacio, Hama1cco, HieuDC-SAS-NightWolf, JulienPerrinGithub, jwngo, kemrec, Maksim Hayder, manus-pi, manus-use, MTekinAU, nirtem, R4yGM, santhreal, and Sultan0f1 for the responsible disclosures of these vulnerabilities.