Thorsten
Monthly
Authenticated account takeover in phpMyFAQ before 4.1.8 allows any authenticated user-including low-privileged accounts-to silently reset the password of any other account, including administrators, by submitting a crafted PUT request to the user data update API endpoint with only a CSRF token and no current-password verification. Successful exploitation locks the victim out of their account irreversibly and grants the attacker full control of that account, enabling vertical privilege escalation from a low-privilege user to administrator. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack is straightforward for any authenticated session holder.
phpMyFAQ before 4.1.8 allows an authenticated attacker who has hijacked a user's session to silently strip two-factor authentication (TOTP) protection from any account, including administrator accounts, by calling either POST /api/user/remove-twofactor or PUT /api/user/data/update with only a valid session cookie and CSRF token - no password re-entry or current TOTP code is required. The root cause is CWE-308: the application guards a security-downgrade operation with single-factor controls (session identity plus CSRF) rather than requiring the second factor whose removal is being requested. After TOTP is disabled, the targeted account becomes accessible via password-only authentication, negating the deployment's MFA posture. No public exploit code or CISA KEV listing has been identified at time of analysis.
Authentication bypass via WebAuthn assertion replay in phpMyFAQ affects all versions up to and including 4.1.5, fixed in 4.1.7. Because prepareForLogin generates a login challenge but neither WebAuthn controller writes the mutated key object back to the database, the anti-replay check is short-circuited by its own null guard, so an attacker who captures one successful WebAuthn assertion can resubmit it indefinitely to log in as that user with no hardware key or user interaction. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the root cause is well documented in the vendor advisory.
Two-factor authentication bypass in phpMyFAQ before 4.1.7 lets an attacker who already knows a valid password defeat the TOTP second factor through unbounded brute force. Because the five-attempt failure counter is stored per session and reset on every successful password re-authentication (CWE-307), an attacker can loop - grab a fresh session cookie, re-enter the known password, and get five more guesses - until the 6-digit TOTP is guessed, yielding full account takeover. Reported by VulnCheck with no public exploit identified at time of analysis and not listed in CISA KEV.
Local file disclosure in phpMyFAQ before 4.1.7 is triggered through unsanitized HTML in FAQ answers when PDF documents are generated via TCPDF. Any user holding FAQ creation or editing rights can embed an img tag whose src attribute references a local file within the content/ directory - when PDF export runs, TCPDF fails to parse the target as an image and raises an uncaught exception whose stack trace exposes a portion of the file's raw contents, potentially including database credentials stored in content/core/config/database.php. No public exploit has been identified at time of analysis, but the CVSS 4.0 score of 7.1 with high confidentiality impact accurately reflects the realistic severity given the potential for full credential exposure under permissive PHP runtime settings.
LDAP authentication bypass in phpMyFAQ 3.1.0-4.1.6 allows a blocked local account to be silently reactivated by authenticating via LDAP, letting previously suspended users regain full application access. The AuthLdap::create() method calls User::setStatus('active') unconditionally after any successful LDAP bind, overwriting an administratively set 'blocked' status in the database without logging the state change. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; the vendor-confirmed fixed release is 4.1.7.
Two-factor authentication bypass in phpMyFAQ before 4.1.7 allows any attacker holding valid first-factor credentials to obtain a remember-me cookie prior to 2FA challenge completion, then replay that cookie to achieve full authenticated access while entirely circumventing the second-factor control. Affected deployments relying on 2FA as their primary defense-in-depth layer against credential compromise are effectively left with single-factor authentication. No public exploit code or CISA KEV listing has been identified at time of analysis, though the bypass logic is straightforward and the vulnerability is trivially reproducible given valid credentials.
SQL injection in phpMyFAQ before 4.1.7 allows authenticated low-privileged users to exfiltrate and manipulate database contents via the glossary create and update endpoints. The flaw stems from a string truncation defect that breaks SQL escaping: when an escaped string is truncated before embedding in a SQL literal, a trailing backslash can dangle, escaping the closing quote and allowing arbitrary SQL injection. No public exploit or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.6 with high confidentiality and integrity impact reflects serious potential for sensitive data exposure.
Password reset token exposure in phpMyFAQ before 4.1.7 enables unauthenticated account takeover by reading a publicly accessible, date-stamped tracking file. When user tracking is enabled, the application writes password reset tokens to content/core/data/trackingDDMMYYYY without access controls, allowing any network attacker to retrieve the file and replay the token against the reset API. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack path is low-complexity once the preconditions are met.
Unauthenticated account takeover in phpMyFAQ before 4.1.3 allows remote attackers to forcibly reset any user's password by sending a PUT request to the /api/index.php/user/password/update endpoint with a valid username and email pair. The endpoint also leaks valid credentials through response code differentials (200 vs 409), enabling username/email enumeration before the reset. No public exploit identified at time of analysis, though a detailed PoC is published in the GHSA advisory.
Authentication bypass in phpMyFAQ before 4.1.3 lets any unauthenticated remote attacker reset arbitrary user passwords - including SuperAdmin - by sending a PUT request to /api/user/password/update with only a valid username/email pair, with no token, rate limit, or out-of-band confirmation. The vendor-issued GHSA-w9xh-5f39-vq89 advisory and VulnCheck disclosure document the flaw, and publicly available exploit code exists in the form of a PoC curl invocation; no CISA KEV listing or EPSS score is provided in the input.
Authentication bypass in phpMyFAQ versions prior to 4.1.3 lets remote unauthenticated attackers create and modify FAQ entries, categories, and questions through the REST API v4.0 by submitting an empty x-pmf-token header that matches the default empty api.apiClientToken value. The flaw stems from strict string comparison logic that cannot distinguish an unconfigured token from an attacker-supplied empty one, exposing every default installation. No public exploit identified at time of analysis, but the GHSA advisory includes a detailed proof-of-concept walkthrough.
Privilege escalation in phpMyFAQ before 4.1.3 allows any authenticated low-privilege administrator to take over SuperAdmin (userId=1) or any other account by manipulating the userId parameter in the /admin/api/user/overwrite-password PUT request. The flaw is an insecure direct object reference (IDOR) in the Admin API where authorization checks confirm only that the caller holds the generic USER_EDIT permission, never that the caller is authorized to manage the targeted account. No public exploit identified at time of analysis, but the GHSA advisory from the vendor (thorsten) publicly documents the exact vulnerable code path, making weaponization trivial.
Stored cross-site scripting in phpMyFAQ 4.1.1 lets any authenticated user with a registered account persist JavaScript inside FAQ or News comments by submitting a URL containing an unescaped double quote, which Utils::parseUrl() injects unescaped into an href attribute. Payloads execute for every visitor - including admins viewing the comments panel - enabling session cookie theft and full application takeover. Publicly available exploit code exists in the GHSA advisory, though EPSS is only 0.01% and SSVC categorizes exploitation as POC rather than active.
Unauthenticated information disclosure in phpMyFAQ before 4.1.2 lets attackers enumerate all FAQ entries, including restricted ones. By iterating solution IDs via the /solution_id_{id}.html endpoint, the application leaks the existence, internal ID, language, category, and title of every FAQ through HTTP 301 redirect headers and page canonical links. No user interaction is required, and a public proof-of-concept exists, though the CVE is not yet listed in CISA's Known Exploited Vulnerabilities catalog.
Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and SMTP secrets by sending a crafted User-Agent header to the public GET /api/captcha endpoint. The flaw sits in BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha(), which interpolate the header into DELETE and INSERT statements via sprintf with no escaping. No public exploit identified at time of analysis, though VulnCheck has published a detailed reachability writeup and a verified time-based blind PoC payload appears in the GHSA advisory.
Authorization bypass in phpMyFAQ versions prior to 4.1.2 allows any authenticated administrative user to access all permission-protected admin pages, regardless of their assigned privileges. The flaw resides in AbstractAdministrationController::userHasPermission() which sends a forbidden response but fails to terminate execution, leaking admin logs, user data, system information, and configuration. Publicly available exploit details exist via the GHSA advisory, though EPSS exploitation probability remains very low at 0.04%.
Stored cross-site scripting in phpMyFAQ before 4.1.2 lets FAQ editors persist HTML-entity-encoded JavaScript that survives sanitization and executes in every visitor's browser, including administrators. The flaw stems from Twig's `| raw` filter being applied to `result.question` and `result.answerPreview` in `search.twig`, combined with a `html_entity_decode(strip_tags())` round-trip in SearchController.php that resurrects encoded tags. Publicly available exploit code exists (POC per SSVC), though EPSS is 0.01% and the issue is not on the CISA KEV list.
SQL injection in phpMyFAQ prior to 4.1.2 allows attackers authenticating through Azure AD/Entra ID OAuth to execute arbitrary database queries by embedding SQL metacharacters in their identity provider display name or JWT claims. The CurrentUser::setTokenData() method interpolates OAuth token fields into an UPDATE statement via sprintf without calling the database escape routine, while sibling methods in the same file correctly escape input. Publicly available exploit code exists per VulnCheck and the GHSA advisory, though EPSS is low (0.03%, 9th percentile) and the issue is not in CISA KEV.
Two-factor authentication bypass in phpMyFAQ before 4.1.2 lets unauthenticated remote attackers brute-force any administrator's six-digit TOTP code by submitting sequential POST requests to the /admin/check endpoint, which lacks session binding and rate limiting. CVSS 4.0 scores this 9.3 with no public exploit identified at time of analysis, though a proof-of-concept is described in the GHSA advisory and SSVC marks exploitation as 'poc' with total technical impact. EPSS is low at 0.12%, reflecting limited observed scanning despite the trivial 10^6 keyspace exhaustible in minutes.
Arbitrary directory deletion in phpMyFAQ before 4.1.2 allows authenticated admins with the INSTANCE_DELETE permission to recursively delete directories outside the multisite clientFolder by submitting path traversal sequences in the client URL parameter. The flaw stems from Client::deleteClientFolder() stripping only the https:// scheme without canonicalizing or validating ../ segments before passing the path to Filesystem::deleteDirectory(). Publicly available exploit code exists (VulnCheck advisory and GHSA write-up include a PoC), though EPSS remains low at 0.04% and the issue is not listed in CISA KEV.
Stored cross-site scripting in phpMyFAQ before 4.1.8 allows authenticated FAQ editors to plant persistent JavaScript payloads that execute in every visitor's browser. The root cause is FaqHelper::convertOldInternalLinks() calling html_entity_decode() on content that was previously sanitized via entity encoding - effectively undoing the protection and re-introducing executable HTML. The impact extends beyond the attacker's own session to all users who subsequently view the poisoned FAQ pages, confirmed by the scope-change metrics in the CVSS 4.0 vector. No public exploit or KEV listing exists at time of analysis.
Authorization bypass in phpMyFAQ before 4.1.8 allows unauthenticated network attackers to submit questions through the question/create API endpoint regardless of guest-restriction settings. The root cause is an incomplete two-setting access control check: isAddingQuestionsAllowed() enforces only the main.enableAskQuestions feature flag while silently ignoring the records.allowQuestionsForGuests restriction, nullifying administrator intent. The practical result is spam injection into the admin moderation queue; no code execution or data exfiltration is achievable through this path alone. No public exploit code has been identified at time of analysis.
Missing authorization in phpMyFAQ's admin dashboard API exposes aggregate search statistics and content-health counters to any authenticated user, regardless of their assigned role or privilege level. All versions before 4.2.0-alpha.2 are affected, with the /searches and /content-health admin API endpoints enforcing only authentication - not permission checks - as the access gate. No public exploit has been identified, and the impact is confined to confidentiality of internal operational statistics.
phpMyFAQ versions before 4.1.8 expose TOTP shared secrets in plaintext within user data export ZIP archives, enabling two-factor authentication bypass. Any authenticated user who generates their own data export - or any party who obtains such an archive through secondary means (e.g., misconfigured storage, insider access, or a separate file-disclosure vulnerability) - can extract the raw TOTP seed and compute valid one-time codes indefinitely. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Incorrect authorization (CWE-863) in phpMyFAQ before 4.1.8 allows authenticated low-privileged editors to read draft and inactive content that is intentionally withheld from public view. Users holding only 'add' permissions can directly invoke the news-edit and FAQ-translate admin endpoints, bypassing the intended role separation and exposing unpublished material. No public exploit has been identified at time of analysis, and exploitation requires a valid account in the target phpMyFAQ installation.
CAPTCHA validation in phpMyFAQ before 4.1.8 is completely skipped when the `store` parameter is set to `now` in question submission requests, exposing any publicly accessible instance to unauthenticated spam automation. Attackers exploiting this bypass can flood the FAQ database with arbitrary question entries and force outbound email notifications to administrators for each submission. No public exploit code or active exploitation has been identified, but the bypass is trivially reproducible through a single parameter manipulation.
Missing authorization in phpMyFAQ before 4.1.7 exposes restricted FAQ child resources - comments and attachments - to unauthenticated network attackers via unguarded API endpoints. The system applies visibility restrictions to parent FAQ records but omits equivalent checks when those records' associated comments and attachments are queried directly, leaking comment text, commenter email addresses, and attachment filenames. No public exploit code has been identified at time of analysis, and it is not listed in CISA KEV; the CVSS 4.0 score of 6.9 reflects the network-accessible, zero-authentication nature of the flaw tempered by its limited, low-confidentiality impact.
Wildcard injection in phpMyFAQ before 4.1.7 allows unauthenticated attackers to cause denial of service via the public FAQ search form when the application is running against PostgreSQL through PHP's native pgsql extension. The underlying defect is a character mismatch in LIKE escape handling: Search/Database/Pgsql.php declares '=' as the LIKE ESCAPE character but escapeLikeWildcards() prefixes user input with '|', making wildcard sanitization entirely inert. Submitted % and _ characters pass through as active SQL wildcards, forcing PostgreSQL into maximally broad sequential table scans. No public exploit has been identified at time of analysis, and the vulnerability explicitly does not enable SQL injection or data exfiltration.
Broken access control in phpMyFAQ before 4.1.7 exposes sensitive infrastructure configuration to any authenticated user, regardless of permission level. Admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration fail to enforce the CONFIGURATION_EDIT permission check, meaning a low-privileged account holder can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics. No public exploit or CISA KEV listing exists at time of analysis, but the low attack complexity and broad exposure to all authenticated users make this a meaningful reconnaissance risk in environments with LDAP or Elastic integrations.
Registration restriction bypass in phpMyFAQ before v4.1.6 enables network attackers to create user accounts even when administrators have explicitly disabled self-registration via the security.enableRegistration configuration flag. The REST API endpoints POST /api/register and POST /api/v3.1/register lack the server-side authorization check present in the HTML registration page, creating a security control gap (CWE-862). No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the mechanically trivial nature of the bypass - a standard HTTP POST - makes it low-effort to abuse once an attacker identifies an exposed phpMyFAQ instance.
phpMyFAQ before version 4.1.7 fails to validate the active/published status of FAQ entries in its PDF export endpoint, enabling unauthenticated remote attackers to retrieve metadata for draft and unpublished FAQ items. By iterating sequential FAQ identifiers against the publicly accessible PDF export route, an attacker can harvest titles, solution IDs, author names, and last-update timestamps of content not yet approved for public release. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing exists for this vulnerability.
phpMyFAQ before v4.1.6 exposes database credentials by writing backup ZIP archives to the publicly accessible document root at a predictable path (`content.zip`), enabling credential theft via two distinct attack chains. Unauthenticated attackers can race concurrent HTTP requests against the brief window between archive creation and deletion, while a second path chains a stored XSS in the admin panel to force an authenticated backup and retrieve the resulting archive. No public exploit code has been identified at time of analysis, though the concrete credential disclosure impact warrants prompt remediation for all internet-facing deployments.
Authentication bypass in phpMyFAQ's SetupController prior to version 4.1.7 allows unauthenticated network attackers to invoke privileged database setup API endpoints whenever the application is in maintenance mode. By sending unauthenticated POST requests to /api/setup/update-database and /api/setup/backup, an attacker can execute database schema migrations, toggle maintenance mode off, and retrieve plaintext database credentials bundled inside a generated ZIP archive. No public exploit has been identified at time of analysis, but the concrete endpoint paths and trivial HTTP-based trigger make independent rediscovery straightforward for any attacker monitoring a maintenance window.
Missing authorization in four write API endpoints of phpMyFAQ prior to version 4.1.4 allows any holder of the shared API key to create categories, create or update FAQs, and post questions regardless of their assigned role permissions. The vulnerability is a partial remediation gap: CVE-2026-24421 previously added `userHasPermission` checks to BackupController, but that fix was not consistently applied to CategoryController::create, FaqController::create, FaqController::update, and QuestionController::create. No public exploit code has been identified and this CVE is not listed in CISA KEV at time of analysis.
Weak cryptographic hashing of attachment passwords in phpMyFAQ prior to 4.1.4 exposes protected attachment credentials to offline cracking or collision-based forgery. The application stored SHA-1 hashes of per-attachment passwords in the database column `password_hash`, computed via `sha1((string) $key)` in `AbstractAttachment::setKey()`. Because SHA-1 has been cryptographically broken since the 2017 SHAttered collision attack, an attacker who obtains these database-stored hashes faces significantly weakened resistance compared to a modern algorithm. No active exploitation is confirmed (CISA KEV: no; exploit status E:U per CVSS 4.0), and the CVSS 4.0 base score of 2.7 reflects limited real-world impact.
Authenticated users without administrative privileges can delete FAQ tags via phpMyFAQ's DELETE /admin/api/content/tags/{tagId} endpoint. The vulnerability affects versions before 4.1.2 and stems from missing authorization checks that allow any logged-in user, including regular frontend users, to permanently delete arbitrary tags using only a valid session cookie. While CVSS rates this 5.4 (Medium), the permanent data loss and FAQ organization disruption represent material operational impact. No active exploitation confirmed (not in CISA KEV), but publicly available exploit code exists per VulnCheck advisory and GitHub security advisory GHSA-7cx3-2qx2-3g6w, lowering exploitation barriers for authenticated attackers.
Stored cross-site scripting in phpMyFAQ versions prior to 4.1.2 allows authenticated users with FAQ_ADD permission to inject malicious JavaScript into FAQ questions and answers that execute in all visitors' browsers. The vulnerability exploits an encode-decode cycle where FILTER_SANITIZE_SPECIAL_CHARS encoding is immediately reversed by html_entity_decode(), bypassing Filter::removeAttributes() which only strips HTML attributes but not tags like <script>. Twig templates render this content with the |raw filter, executing stored payloads. CVSS 5.4 indicates network-accessible attack requiring low-privilege authentication and user interaction, with changed scope enabling cross-user impact. EPSS data not provided; no CISA KEV listing indicates no confirmed widespread exploitation at time of analysis.
Authenticated users with FAQ_EDIT permission in phpMyFAQ can bypass SVG sanitization and execute arbitrary JavaScript in victims' browsers by exploiting recursive entity decoding limits. By nesting ampersand encoding five levels deep around numeric HTML entities in SVG href attributes (e.g., &amp;amp;amp;amp;#106; for 'j'), attackers reconstruct javascript: URLs that the decodeAllEntities() method fails to detect but browsers fully decode. The malicious SVG uploads persist on the server and execute JavaScript when other users click the embedded links. Fixed in version 4.1.2. EPSS and KEV data not available; VulnCheck reported this issue with vendor-confirmed details and proof-of-concept in GitHub security advisory GHSA-whqh-9pq5-c7r3.
Authorization bypass in phpMyFAQ versions before 4.1.2 allows authenticated frontend users to access admin-only API endpoints and retrieve sensitive backend configuration data. The vulnerability stems from admin-api routes checking only login status (isLoggedIn) without verifying administrative privileges, enabling any valid user account to query dashboard versions, LDAP configuration details, Elasticsearch statistics, and health-check data. While this is an information disclosure issue rather than direct write access, it exposes internal infrastructure details useful for reconnaissance. The low CVSS score (4.3) reflects limited confidentiality impact, but defenders should prioritize remediation in environments where backend configuration exposure aids broader attack campaigns. Vendor patch available in version 4.1.2.
Insufficient authorization in phpMyFAQ 4.1.1 and earlier allows any authenticated user to enumerate sensitive system configuration metadata through 12 admin API endpoints. The ConfigurationTabController improperly uses userIsAuthenticated() instead of userHasPermission(CONFIGURATION_EDIT), enabling low-privilege users to query /admin/api/configuration endpoints and discover the permission model, active template, cache backend, mail provider, translation settings, and other deployment details that should require administrative access. This information disclosure violates least privilege principles and aids reconnaissance for subsequent attacks. EPSS data not available; no active exploitation confirmed at time of analysis. Vendor-released patch available in version 4.1.2.
Authenticated account takeover in phpMyFAQ before 4.1.8 allows any authenticated user-including low-privileged accounts-to silently reset the password of any other account, including administrators, by submitting a crafted PUT request to the user data update API endpoint with only a CSRF token and no current-password verification. Successful exploitation locks the victim out of their account irreversibly and grants the attacker full control of that account, enabling vertical privilege escalation from a low-privilege user to administrator. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack is straightforward for any authenticated session holder.
phpMyFAQ before 4.1.8 allows an authenticated attacker who has hijacked a user's session to silently strip two-factor authentication (TOTP) protection from any account, including administrator accounts, by calling either POST /api/user/remove-twofactor or PUT /api/user/data/update with only a valid session cookie and CSRF token - no password re-entry or current TOTP code is required. The root cause is CWE-308: the application guards a security-downgrade operation with single-factor controls (session identity plus CSRF) rather than requiring the second factor whose removal is being requested. After TOTP is disabled, the targeted account becomes accessible via password-only authentication, negating the deployment's MFA posture. No public exploit code or CISA KEV listing has been identified at time of analysis.
Authentication bypass via WebAuthn assertion replay in phpMyFAQ affects all versions up to and including 4.1.5, fixed in 4.1.7. Because prepareForLogin generates a login challenge but neither WebAuthn controller writes the mutated key object back to the database, the anti-replay check is short-circuited by its own null guard, so an attacker who captures one successful WebAuthn assertion can resubmit it indefinitely to log in as that user with no hardware key or user interaction. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the root cause is well documented in the vendor advisory.
Two-factor authentication bypass in phpMyFAQ before 4.1.7 lets an attacker who already knows a valid password defeat the TOTP second factor through unbounded brute force. Because the five-attempt failure counter is stored per session and reset on every successful password re-authentication (CWE-307), an attacker can loop - grab a fresh session cookie, re-enter the known password, and get five more guesses - until the 6-digit TOTP is guessed, yielding full account takeover. Reported by VulnCheck with no public exploit identified at time of analysis and not listed in CISA KEV.
Local file disclosure in phpMyFAQ before 4.1.7 is triggered through unsanitized HTML in FAQ answers when PDF documents are generated via TCPDF. Any user holding FAQ creation or editing rights can embed an img tag whose src attribute references a local file within the content/ directory - when PDF export runs, TCPDF fails to parse the target as an image and raises an uncaught exception whose stack trace exposes a portion of the file's raw contents, potentially including database credentials stored in content/core/config/database.php. No public exploit has been identified at time of analysis, but the CVSS 4.0 score of 7.1 with high confidentiality impact accurately reflects the realistic severity given the potential for full credential exposure under permissive PHP runtime settings.
LDAP authentication bypass in phpMyFAQ 3.1.0-4.1.6 allows a blocked local account to be silently reactivated by authenticating via LDAP, letting previously suspended users regain full application access. The AuthLdap::create() method calls User::setStatus('active') unconditionally after any successful LDAP bind, overwriting an administratively set 'blocked' status in the database without logging the state change. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; the vendor-confirmed fixed release is 4.1.7.
Two-factor authentication bypass in phpMyFAQ before 4.1.7 allows any attacker holding valid first-factor credentials to obtain a remember-me cookie prior to 2FA challenge completion, then replay that cookie to achieve full authenticated access while entirely circumventing the second-factor control. Affected deployments relying on 2FA as their primary defense-in-depth layer against credential compromise are effectively left with single-factor authentication. No public exploit code or CISA KEV listing has been identified at time of analysis, though the bypass logic is straightforward and the vulnerability is trivially reproducible given valid credentials.
SQL injection in phpMyFAQ before 4.1.7 allows authenticated low-privileged users to exfiltrate and manipulate database contents via the glossary create and update endpoints. The flaw stems from a string truncation defect that breaks SQL escaping: when an escaped string is truncated before embedding in a SQL literal, a trailing backslash can dangle, escaping the closing quote and allowing arbitrary SQL injection. No public exploit or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.6 with high confidentiality and integrity impact reflects serious potential for sensitive data exposure.
Password reset token exposure in phpMyFAQ before 4.1.7 enables unauthenticated account takeover by reading a publicly accessible, date-stamped tracking file. When user tracking is enabled, the application writes password reset tokens to content/core/data/trackingDDMMYYYY without access controls, allowing any network attacker to retrieve the file and replay the token against the reset API. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack path is low-complexity once the preconditions are met.
Unauthenticated account takeover in phpMyFAQ before 4.1.3 allows remote attackers to forcibly reset any user's password by sending a PUT request to the /api/index.php/user/password/update endpoint with a valid username and email pair. The endpoint also leaks valid credentials through response code differentials (200 vs 409), enabling username/email enumeration before the reset. No public exploit identified at time of analysis, though a detailed PoC is published in the GHSA advisory.
Authentication bypass in phpMyFAQ before 4.1.3 lets any unauthenticated remote attacker reset arbitrary user passwords - including SuperAdmin - by sending a PUT request to /api/user/password/update with only a valid username/email pair, with no token, rate limit, or out-of-band confirmation. The vendor-issued GHSA-w9xh-5f39-vq89 advisory and VulnCheck disclosure document the flaw, and publicly available exploit code exists in the form of a PoC curl invocation; no CISA KEV listing or EPSS score is provided in the input.
Authentication bypass in phpMyFAQ versions prior to 4.1.3 lets remote unauthenticated attackers create and modify FAQ entries, categories, and questions through the REST API v4.0 by submitting an empty x-pmf-token header that matches the default empty api.apiClientToken value. The flaw stems from strict string comparison logic that cannot distinguish an unconfigured token from an attacker-supplied empty one, exposing every default installation. No public exploit identified at time of analysis, but the GHSA advisory includes a detailed proof-of-concept walkthrough.
Privilege escalation in phpMyFAQ before 4.1.3 allows any authenticated low-privilege administrator to take over SuperAdmin (userId=1) or any other account by manipulating the userId parameter in the /admin/api/user/overwrite-password PUT request. The flaw is an insecure direct object reference (IDOR) in the Admin API where authorization checks confirm only that the caller holds the generic USER_EDIT permission, never that the caller is authorized to manage the targeted account. No public exploit identified at time of analysis, but the GHSA advisory from the vendor (thorsten) publicly documents the exact vulnerable code path, making weaponization trivial.
Stored cross-site scripting in phpMyFAQ 4.1.1 lets any authenticated user with a registered account persist JavaScript inside FAQ or News comments by submitting a URL containing an unescaped double quote, which Utils::parseUrl() injects unescaped into an href attribute. Payloads execute for every visitor - including admins viewing the comments panel - enabling session cookie theft and full application takeover. Publicly available exploit code exists in the GHSA advisory, though EPSS is only 0.01% and SSVC categorizes exploitation as POC rather than active.
Unauthenticated information disclosure in phpMyFAQ before 4.1.2 lets attackers enumerate all FAQ entries, including restricted ones. By iterating solution IDs via the /solution_id_{id}.html endpoint, the application leaks the existence, internal ID, language, category, and title of every FAQ through HTTP 301 redirect headers and page canonical links. No user interaction is required, and a public proof-of-concept exists, though the CVE is not yet listed in CISA's Known Exploited Vulnerabilities catalog.
Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and SMTP secrets by sending a crafted User-Agent header to the public GET /api/captcha endpoint. The flaw sits in BuiltinCaptcha::garbageCollector() and BuiltinCaptcha::saveCaptcha(), which interpolate the header into DELETE and INSERT statements via sprintf with no escaping. No public exploit identified at time of analysis, though VulnCheck has published a detailed reachability writeup and a verified time-based blind PoC payload appears in the GHSA advisory.
Authorization bypass in phpMyFAQ versions prior to 4.1.2 allows any authenticated administrative user to access all permission-protected admin pages, regardless of their assigned privileges. The flaw resides in AbstractAdministrationController::userHasPermission() which sends a forbidden response but fails to terminate execution, leaking admin logs, user data, system information, and configuration. Publicly available exploit details exist via the GHSA advisory, though EPSS exploitation probability remains very low at 0.04%.
Stored cross-site scripting in phpMyFAQ before 4.1.2 lets FAQ editors persist HTML-entity-encoded JavaScript that survives sanitization and executes in every visitor's browser, including administrators. The flaw stems from Twig's `| raw` filter being applied to `result.question` and `result.answerPreview` in `search.twig`, combined with a `html_entity_decode(strip_tags())` round-trip in SearchController.php that resurrects encoded tags. Publicly available exploit code exists (POC per SSVC), though EPSS is 0.01% and the issue is not on the CISA KEV list.
SQL injection in phpMyFAQ prior to 4.1.2 allows attackers authenticating through Azure AD/Entra ID OAuth to execute arbitrary database queries by embedding SQL metacharacters in their identity provider display name or JWT claims. The CurrentUser::setTokenData() method interpolates OAuth token fields into an UPDATE statement via sprintf without calling the database escape routine, while sibling methods in the same file correctly escape input. Publicly available exploit code exists per VulnCheck and the GHSA advisory, though EPSS is low (0.03%, 9th percentile) and the issue is not in CISA KEV.
Two-factor authentication bypass in phpMyFAQ before 4.1.2 lets unauthenticated remote attackers brute-force any administrator's six-digit TOTP code by submitting sequential POST requests to the /admin/check endpoint, which lacks session binding and rate limiting. CVSS 4.0 scores this 9.3 with no public exploit identified at time of analysis, though a proof-of-concept is described in the GHSA advisory and SSVC marks exploitation as 'poc' with total technical impact. EPSS is low at 0.12%, reflecting limited observed scanning despite the trivial 10^6 keyspace exhaustible in minutes.
Arbitrary directory deletion in phpMyFAQ before 4.1.2 allows authenticated admins with the INSTANCE_DELETE permission to recursively delete directories outside the multisite clientFolder by submitting path traversal sequences in the client URL parameter. The flaw stems from Client::deleteClientFolder() stripping only the https:// scheme without canonicalizing or validating ../ segments before passing the path to Filesystem::deleteDirectory(). Publicly available exploit code exists (VulnCheck advisory and GHSA write-up include a PoC), though EPSS remains low at 0.04% and the issue is not listed in CISA KEV.
Stored cross-site scripting in phpMyFAQ before 4.1.8 allows authenticated FAQ editors to plant persistent JavaScript payloads that execute in every visitor's browser. The root cause is FaqHelper::convertOldInternalLinks() calling html_entity_decode() on content that was previously sanitized via entity encoding - effectively undoing the protection and re-introducing executable HTML. The impact extends beyond the attacker's own session to all users who subsequently view the poisoned FAQ pages, confirmed by the scope-change metrics in the CVSS 4.0 vector. No public exploit or KEV listing exists at time of analysis.
Authorization bypass in phpMyFAQ before 4.1.8 allows unauthenticated network attackers to submit questions through the question/create API endpoint regardless of guest-restriction settings. The root cause is an incomplete two-setting access control check: isAddingQuestionsAllowed() enforces only the main.enableAskQuestions feature flag while silently ignoring the records.allowQuestionsForGuests restriction, nullifying administrator intent. The practical result is spam injection into the admin moderation queue; no code execution or data exfiltration is achievable through this path alone. No public exploit code has been identified at time of analysis.
Missing authorization in phpMyFAQ's admin dashboard API exposes aggregate search statistics and content-health counters to any authenticated user, regardless of their assigned role or privilege level. All versions before 4.2.0-alpha.2 are affected, with the /searches and /content-health admin API endpoints enforcing only authentication - not permission checks - as the access gate. No public exploit has been identified, and the impact is confined to confidentiality of internal operational statistics.
phpMyFAQ versions before 4.1.8 expose TOTP shared secrets in plaintext within user data export ZIP archives, enabling two-factor authentication bypass. Any authenticated user who generates their own data export - or any party who obtains such an archive through secondary means (e.g., misconfigured storage, insider access, or a separate file-disclosure vulnerability) - can extract the raw TOTP seed and compute valid one-time codes indefinitely. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Incorrect authorization (CWE-863) in phpMyFAQ before 4.1.8 allows authenticated low-privileged editors to read draft and inactive content that is intentionally withheld from public view. Users holding only 'add' permissions can directly invoke the news-edit and FAQ-translate admin endpoints, bypassing the intended role separation and exposing unpublished material. No public exploit has been identified at time of analysis, and exploitation requires a valid account in the target phpMyFAQ installation.
CAPTCHA validation in phpMyFAQ before 4.1.8 is completely skipped when the `store` parameter is set to `now` in question submission requests, exposing any publicly accessible instance to unauthenticated spam automation. Attackers exploiting this bypass can flood the FAQ database with arbitrary question entries and force outbound email notifications to administrators for each submission. No public exploit code or active exploitation has been identified, but the bypass is trivially reproducible through a single parameter manipulation.
Missing authorization in phpMyFAQ before 4.1.7 exposes restricted FAQ child resources - comments and attachments - to unauthenticated network attackers via unguarded API endpoints. The system applies visibility restrictions to parent FAQ records but omits equivalent checks when those records' associated comments and attachments are queried directly, leaking comment text, commenter email addresses, and attachment filenames. No public exploit code has been identified at time of analysis, and it is not listed in CISA KEV; the CVSS 4.0 score of 6.9 reflects the network-accessible, zero-authentication nature of the flaw tempered by its limited, low-confidentiality impact.
Wildcard injection in phpMyFAQ before 4.1.7 allows unauthenticated attackers to cause denial of service via the public FAQ search form when the application is running against PostgreSQL through PHP's native pgsql extension. The underlying defect is a character mismatch in LIKE escape handling: Search/Database/Pgsql.php declares '=' as the LIKE ESCAPE character but escapeLikeWildcards() prefixes user input with '|', making wildcard sanitization entirely inert. Submitted % and _ characters pass through as active SQL wildcards, forcing PostgreSQL into maximally broad sequential table scans. No public exploit has been identified at time of analysis, and the vulnerability explicitly does not enable SQL injection or data exfiltration.
Broken access control in phpMyFAQ before 4.1.7 exposes sensitive infrastructure configuration to any authenticated user, regardless of permission level. Admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration fail to enforce the CONFIGURATION_EDIT permission check, meaning a low-privileged account holder can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics. No public exploit or CISA KEV listing exists at time of analysis, but the low attack complexity and broad exposure to all authenticated users make this a meaningful reconnaissance risk in environments with LDAP or Elastic integrations.
Registration restriction bypass in phpMyFAQ before v4.1.6 enables network attackers to create user accounts even when administrators have explicitly disabled self-registration via the security.enableRegistration configuration flag. The REST API endpoints POST /api/register and POST /api/v3.1/register lack the server-side authorization check present in the HTML registration page, creating a security control gap (CWE-862). No public exploit has been identified and the vulnerability is not listed in CISA KEV; however, the mechanically trivial nature of the bypass - a standard HTTP POST - makes it low-effort to abuse once an attacker identifies an exposed phpMyFAQ instance.
phpMyFAQ before version 4.1.7 fails to validate the active/published status of FAQ entries in its PDF export endpoint, enabling unauthenticated remote attackers to retrieve metadata for draft and unpublished FAQ items. By iterating sequential FAQ identifiers against the publicly accessible PDF export route, an attacker can harvest titles, solution IDs, author names, and last-update timestamps of content not yet approved for public release. No public exploit code or active exploitation has been identified at time of analysis, and no CISA KEV listing exists for this vulnerability.
phpMyFAQ before v4.1.6 exposes database credentials by writing backup ZIP archives to the publicly accessible document root at a predictable path (`content.zip`), enabling credential theft via two distinct attack chains. Unauthenticated attackers can race concurrent HTTP requests against the brief window between archive creation and deletion, while a second path chains a stored XSS in the admin panel to force an authenticated backup and retrieve the resulting archive. No public exploit code has been identified at time of analysis, though the concrete credential disclosure impact warrants prompt remediation for all internet-facing deployments.
Authentication bypass in phpMyFAQ's SetupController prior to version 4.1.7 allows unauthenticated network attackers to invoke privileged database setup API endpoints whenever the application is in maintenance mode. By sending unauthenticated POST requests to /api/setup/update-database and /api/setup/backup, an attacker can execute database schema migrations, toggle maintenance mode off, and retrieve plaintext database credentials bundled inside a generated ZIP archive. No public exploit has been identified at time of analysis, but the concrete endpoint paths and trivial HTTP-based trigger make independent rediscovery straightforward for any attacker monitoring a maintenance window.
Missing authorization in four write API endpoints of phpMyFAQ prior to version 4.1.4 allows any holder of the shared API key to create categories, create or update FAQs, and post questions regardless of their assigned role permissions. The vulnerability is a partial remediation gap: CVE-2026-24421 previously added `userHasPermission` checks to BackupController, but that fix was not consistently applied to CategoryController::create, FaqController::create, FaqController::update, and QuestionController::create. No public exploit code has been identified and this CVE is not listed in CISA KEV at time of analysis.
Weak cryptographic hashing of attachment passwords in phpMyFAQ prior to 4.1.4 exposes protected attachment credentials to offline cracking or collision-based forgery. The application stored SHA-1 hashes of per-attachment passwords in the database column `password_hash`, computed via `sha1((string) $key)` in `AbstractAttachment::setKey()`. Because SHA-1 has been cryptographically broken since the 2017 SHAttered collision attack, an attacker who obtains these database-stored hashes faces significantly weakened resistance compared to a modern algorithm. No active exploitation is confirmed (CISA KEV: no; exploit status E:U per CVSS 4.0), and the CVSS 4.0 base score of 2.7 reflects limited real-world impact.
Authenticated users without administrative privileges can delete FAQ tags via phpMyFAQ's DELETE /admin/api/content/tags/{tagId} endpoint. The vulnerability affects versions before 4.1.2 and stems from missing authorization checks that allow any logged-in user, including regular frontend users, to permanently delete arbitrary tags using only a valid session cookie. While CVSS rates this 5.4 (Medium), the permanent data loss and FAQ organization disruption represent material operational impact. No active exploitation confirmed (not in CISA KEV), but publicly available exploit code exists per VulnCheck advisory and GitHub security advisory GHSA-7cx3-2qx2-3g6w, lowering exploitation barriers for authenticated attackers.
Stored cross-site scripting in phpMyFAQ versions prior to 4.1.2 allows authenticated users with FAQ_ADD permission to inject malicious JavaScript into FAQ questions and answers that execute in all visitors' browsers. The vulnerability exploits an encode-decode cycle where FILTER_SANITIZE_SPECIAL_CHARS encoding is immediately reversed by html_entity_decode(), bypassing Filter::removeAttributes() which only strips HTML attributes but not tags like <script>. Twig templates render this content with the |raw filter, executing stored payloads. CVSS 5.4 indicates network-accessible attack requiring low-privilege authentication and user interaction, with changed scope enabling cross-user impact. EPSS data not provided; no CISA KEV listing indicates no confirmed widespread exploitation at time of analysis.
Authenticated users with FAQ_EDIT permission in phpMyFAQ can bypass SVG sanitization and execute arbitrary JavaScript in victims' browsers by exploiting recursive entity decoding limits. By nesting ampersand encoding five levels deep around numeric HTML entities in SVG href attributes (e.g., &amp;amp;amp;amp;#106; for 'j'), attackers reconstruct javascript: URLs that the decodeAllEntities() method fails to detect but browsers fully decode. The malicious SVG uploads persist on the server and execute JavaScript when other users click the embedded links. Fixed in version 4.1.2. EPSS and KEV data not available; VulnCheck reported this issue with vendor-confirmed details and proof-of-concept in GitHub security advisory GHSA-whqh-9pq5-c7r3.
Authorization bypass in phpMyFAQ versions before 4.1.2 allows authenticated frontend users to access admin-only API endpoints and retrieve sensitive backend configuration data. The vulnerability stems from admin-api routes checking only login status (isLoggedIn) without verifying administrative privileges, enabling any valid user account to query dashboard versions, LDAP configuration details, Elasticsearch statistics, and health-check data. While this is an information disclosure issue rather than direct write access, it exposes internal infrastructure details useful for reconnaissance. The low CVSS score (4.3) reflects limited confidentiality impact, but defenders should prioritize remediation in environments where backend configuration exposure aids broader attack campaigns. Vendor patch available in version 4.1.2.
Insufficient authorization in phpMyFAQ 4.1.1 and earlier allows any authenticated user to enumerate sensitive system configuration metadata through 12 admin API endpoints. The ConfigurationTabController improperly uses userIsAuthenticated() instead of userHasPermission(CONFIGURATION_EDIT), enabling low-privilege users to query /admin/api/configuration endpoints and discover the permission model, active template, cache backend, mail provider, translation settings, and other deployment details that should require administrative access. This information disclosure violates least privilege principles and aids reconnaissance for subsequent attacks. EPSS data not available; no active exploitation confirmed at time of analysis. Vendor-released patch available in version 4.1.2.