Phpmyfaq
Monthly
Unauthenticated SQL injection in phpMyFAQ versions prior to 4.1.9 lets remote attackers read credentials and configuration secrets, modify or delete records, or drop tables via the search parameter of the api/autocomplete endpoint. Exploitation is conditional: the backend MySQL or MariaDB instance must be running in NO_BACKSLASH_ESCAPES mode, because PdoMysql::escape() relies on backslash escaping of single quotes that that SQL mode treats literally; the payload additionally uses a Unicode right single quotation mark (U+2019) that the application normalizes to an ASCII quote after escaping has already been applied, bypassing the filter. This is a genuine high-priority issue (CVSS 4.0 base 9.2, AT:P/AC:H reflecting the non-default SQL-mode prerequisite) rather than a high-CVSS artifact, since an attacker who reaches such a deployment needs no authentication and no user interaction; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the primary limiting factor is whether the target database uses the default SQL mode.
SQL injection in phpMyFAQ versions prior to 4.1.6 lets an authenticated administrator inject arbitrary SQL through the stop-word management feature by supplying a crafted "word" value that breaks out of the string literal built in StopWords::add(). The flaw is confined to the add()/INSERT code path - the sibling update() method escapes the same input correctly - and because it requires a high-privileged admin session (PR:H) plus access to the stop-word UI, exposure is bounded to trusted operators or compromised admin credentials rather than unauthenticated attackers. Successful exploitation permits reading, modifying, or deleting arbitrary rows and tables within the phpMyFAQ database; no public exploit code has been identified at time of analysis, and the vendor-released patch is version 4.1.6.
Unauthenticated attackers can bypass TOTP-based two-factor authentication in phpMyFAQ 3.2.0 through 4.1.5 and take over any 2FA-enabled account, including administrator accounts, by submitting a victim's numeric user ID together with a valid or brute-forced six-digit code to the public 2FA verification flow in index.php without ever supplying the account password. The flaw rates CVSS 3.1 base 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H); the high attack complexity reflects the cost of guessing a TOTP code inside its rolling validity window, while the practical enabler pre-patch is the complete absence of any failed-attempt limit and the fact that token verification was never bound to a prior password-authenticated session. There is no public exploit identified at time of analysis and no CISA KEV listing, but exploitation requires only that the targeted account have 2FA enabled, making the exposure significant for deployments that adopted TOTP. Vendor-released patch: 4.1.6.
Stored cross-site scripting in phpMyFAQ versions prior to 4.2.0-alpha allows unauthenticated remote attackers, as well as low-privileged registered users, to plant arbitrary JavaScript in user-submitted FAQ entries that executes in an administrator's browser when the entry is reviewed or edited, enabling admin session theft and full account takeover. The assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N, 8.2 High) reflects that no authentication is needed to submit the payload, but exploitation succeeds only when an administrator later interacts with the attacker-controlled content; the scope change indicates the compromise crosses from the unauthenticated submitter into the privileged admin session. No public exploit code was identified at time of analysis and CISA KEV does not list this CVE, though the default community-submission workflow in affected releases makes the attack path straightforward once a target is identified.
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.
Privilege escalation in phpMyFAQ before 4.1.5 lets a delegated administrator holding USER_ADD/EDIT/DELETE rights mint a full SuperAdmin account through the POST /admin/api/user/add endpoint, resulting in complete instance takeover. The flaw stems from a missing SuperAdmin authorization guard, allowing a lower-privileged operator to submit isSuperAdmin: true with attacker-chosen credentials and then log in as that account. Reported by VulnCheck; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Privilege escalation in phpMyFAQ before 4.1.5 lets a delegated administrator holding the GROUP_EDIT right elevate to full administrative control. Because GroupController::updatePermissions never verifies that the caller already possesses the permissions being assigned, a low-privileged admin can grant high-value rights to a group they belong to and inherit those rights. The flaw was reported by VulnCheck; no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Privilege escalation in phpMyFAQ before 4.1.4 allows authenticated non-SuperAdmin users holding the edit_user permission to promote themselves to SuperAdmin via missing authorization checks in the editUser() and updateUserRights() endpoints. The flaw lets a low-tier administrator set the is_superadmin flag or grant arbitrary rights, fully compromising the FAQ application; publicly available exploit code exists is not asserted, and at time of analysis no public exploit identified at time of analysis.
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.
Unauthenticated account creation in phpMyFAQ versions before 4.0.18 allows remote attackers to register unlimited user accounts through the WebAuthn prepare endpoint without authentication, CSRF protection, or captcha validation, even when registration is disabled. Public exploit code exists for this vulnerability. Update to version 4.0.18 or later to remediate.
Missing authorization in the phpMyFAQ MCP server's faq_search tool allows an authenticated MCP client to read the full question-and-answer text of active FAQs that are restricted to specific users or groups, because the underlying Search::searchDatabase() routine never applies the per-user or per-group permission checks that normally govern FAQ visibility. The flaw affects phpMyFAQ through 4.1.10 and is limited to confidentiality: exploitation requires that the optional MCP server feature is deployed and reachable and that the attacker can connect to phpmyfaq:mcp:server with at least low-privilege access (CVSS PR:L, local attack vector), so this is a modest-priority issue rather than a high-urgency flaw. No public exploit identified at time of analysis and no vendor-released patch identified at time of analysis; the issue is tracked under CWE-862 (Missing Authorization).
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.
Information disclosure of inactive FAQ content in phpMyFAQ before 4.1.5 allows unauthenticated attackers to retrieve draft or review-only FAQs via specific public API endpoints. The flaw exposes non-public titles and full answers or previews through endpoints that inconsistently apply active-status and publication-date filters. Exploit code is publicly available, but no active exploitation has been confirmed.
Path traversal in phpMyFAQ's PDF export pipeline allows authenticated FAQ editors to read arbitrary server-side files by storing HTML with crafted image paths that exploit a type-juggling flaw in concatenatePaths(). When the substring 'content' is absent from an attacker-controlled path, strpos() returns false, which PHP silently coerces to integer 0, causing the full unsanitized path to pass through to file_get_contents() without canonicalization. No active exploitation is confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis, but the root cause is a low-complexity PHP type-juggling antipattern that is straightforward to weaponize once the attack surface is understood.
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.
Insufficient access controls in phpMyFAQ 4.0.16 and below expose sensitive information including user email addresses and non-public content through multiple API endpoints, allowing unauthenticated attackers to harvest data for phishing or access private records. Public exploit code exists for this vulnerability, and no patch is currently available. Upgrading to version 4.0.17 or later is required to remediate the exposure.
Authenticated users in phpMyFAQ 4.0.16 and below can bypass permission checks to download FAQ attachments they should not have access to, due to improper validation of authorization tokens in attachment.php and flawed permission logic. An attacker with valid credentials but without the dlattachment permission can exploit this to retrieve sensitive attachment content. Public exploit code exists for this vulnerability, and no patch is currently available.
phpMyFAQ versions 4.0.16 and below allow authenticated users to access the backup API endpoint without proper authorization checks, enabling them to download configuration files containing sensitive data. The vulnerability stems from incomplete authorization validation in SetupController.php, which only verifies authentication rather than admin permissions. Public exploit code exists for this issue, and no patch is currently available.
Unauthenticated attackers can force phpMyFAQ installations running versions prior to 4.0.16 to generate a full configuration backup ZIP inside a web-accessible directory and then simply download it, exposing database credentials and other configuration secrets. The POST /api/setup/backup endpoint performs no authentication, authorization, or API token verification, and the resulting archive is served from content/core/config/ under a date-stamped filename, so no user interaction or privileges are needed (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Publicly available exploit code exists - the vendor's GitHub advisory publishes a three-step curl proof of concept - and the information disclosed (database.php credentials, integration configuration) is well suited to follow-on compromise, making this a genuine high-priority issue rather than an inflated high-CVSS score.
Stored cross-site scripting in phpMyFAQ 4.0.14 and 4.0.15 allows an unauthenticated attacker (PR:N in the assessed vector) to execute arbitrary JavaScript in an administrator's browser by registering a user account whose display name contains HTML entities, which phpMyFAQ decodes server-side and then renders without escaping in the admin user list. Exploitation is conditional: public self-registration must be enabled (security.enableRegistration = true) and an administrator must actually open the admin user list page (/admin/user/list), so the payload stays inert until viewed (UI:R), giving an overall CVSS of 6.1. A working proof-of-concept with step-by-step reproduction is published in the vendor's GitHub security advisory, but there is no evidence of active exploitation and the issue is not listed in CISA KEV; version 4.0.16 contains the fix.
phpMyFAQ is an open source FAQ web application. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets unauthenticated remote attackers create multiple distinct accounts sharing the same email address because the createUser logic in RegistrationHelper.php and User.php performed no uniqueness check prior to 4.0.13. The practical consequence is account ambiguity rather than immediate compromise: data-integrity loss, colliding password-reset flows, and spam/duplicate pollution, with privilege escalation or account takeover possible only in specific configurations where a privileged account already exists under the targeted email and downstream flows key off the email instead of the unique user ID. A public proof-of-concept and the upstream fix commit are available, EPSS is negligible (0.05%, 16th percentile), and there is no indication of confirmed active exploitation (no CISA KEV), although the NVD headline CVSS of 9.8 substantially overstates real-world risk relative to our assessment of AV:N/AC:H/PR:N/UI:N/C:L/I:L/A:N.
phpMyFAQ is an open source FAQ web application. Rated medium severity (CVSS 5.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
phpMyFAQ is an open source FAQ web application. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated low severity (CVSS 2.7), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an Open Source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.2.1. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.1. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Unrestricted Upload of File with Dangerous Type in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Unrestricted File Upload vulnerability could allow attackers to upload malicious files that can be executed on the server.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.16. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Improper Neutralization of Formula Elements in a CSV File in GitHub repository thorsten/phpmyfaq prior to 3.1.16. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.0-beta.2. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Unauthenticated SQL injection in phpMyFAQ versions prior to 4.1.9 lets remote attackers read credentials and configuration secrets, modify or delete records, or drop tables via the search parameter of the api/autocomplete endpoint. Exploitation is conditional: the backend MySQL or MariaDB instance must be running in NO_BACKSLASH_ESCAPES mode, because PdoMysql::escape() relies on backslash escaping of single quotes that that SQL mode treats literally; the payload additionally uses a Unicode right single quotation mark (U+2019) that the application normalizes to an ASCII quote after escaping has already been applied, bypassing the filter. This is a genuine high-priority issue (CVSS 4.0 base 9.2, AT:P/AC:H reflecting the non-default SQL-mode prerequisite) rather than a high-CVSS artifact, since an attacker who reaches such a deployment needs no authentication and no user interaction; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the primary limiting factor is whether the target database uses the default SQL mode.
SQL injection in phpMyFAQ versions prior to 4.1.6 lets an authenticated administrator inject arbitrary SQL through the stop-word management feature by supplying a crafted "word" value that breaks out of the string literal built in StopWords::add(). The flaw is confined to the add()/INSERT code path - the sibling update() method escapes the same input correctly - and because it requires a high-privileged admin session (PR:H) plus access to the stop-word UI, exposure is bounded to trusted operators or compromised admin credentials rather than unauthenticated attackers. Successful exploitation permits reading, modifying, or deleting arbitrary rows and tables within the phpMyFAQ database; no public exploit code has been identified at time of analysis, and the vendor-released patch is version 4.1.6.
Unauthenticated attackers can bypass TOTP-based two-factor authentication in phpMyFAQ 3.2.0 through 4.1.5 and take over any 2FA-enabled account, including administrator accounts, by submitting a victim's numeric user ID together with a valid or brute-forced six-digit code to the public 2FA verification flow in index.php without ever supplying the account password. The flaw rates CVSS 3.1 base 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H); the high attack complexity reflects the cost of guessing a TOTP code inside its rolling validity window, while the practical enabler pre-patch is the complete absence of any failed-attempt limit and the fact that token verification was never bound to a prior password-authenticated session. There is no public exploit identified at time of analysis and no CISA KEV listing, but exploitation requires only that the targeted account have 2FA enabled, making the exposure significant for deployments that adopted TOTP. Vendor-released patch: 4.1.6.
Stored cross-site scripting in phpMyFAQ versions prior to 4.2.0-alpha allows unauthenticated remote attackers, as well as low-privileged registered users, to plant arbitrary JavaScript in user-submitted FAQ entries that executes in an administrator's browser when the entry is reviewed or edited, enabling admin session theft and full account takeover. The assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N, 8.2 High) reflects that no authentication is needed to submit the payload, but exploitation succeeds only when an administrator later interacts with the attacker-controlled content; the scope change indicates the compromise crosses from the unauthenticated submitter into the privileged admin session. No public exploit code was identified at time of analysis and CISA KEV does not list this CVE, though the default community-submission workflow in affected releases makes the attack path straightforward once a target is identified.
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.
Privilege escalation in phpMyFAQ before 4.1.5 lets a delegated administrator holding USER_ADD/EDIT/DELETE rights mint a full SuperAdmin account through the POST /admin/api/user/add endpoint, resulting in complete instance takeover. The flaw stems from a missing SuperAdmin authorization guard, allowing a lower-privileged operator to submit isSuperAdmin: true with attacker-chosen credentials and then log in as that account. Reported by VulnCheck; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Privilege escalation in phpMyFAQ before 4.1.5 lets a delegated administrator holding the GROUP_EDIT right elevate to full administrative control. Because GroupController::updatePermissions never verifies that the caller already possesses the permissions being assigned, a low-privileged admin can grant high-value rights to a group they belong to and inherit those rights. The flaw was reported by VulnCheck; no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Privilege escalation in phpMyFAQ before 4.1.4 allows authenticated non-SuperAdmin users holding the edit_user permission to promote themselves to SuperAdmin via missing authorization checks in the editUser() and updateUserRights() endpoints. The flaw lets a low-tier administrator set the is_superadmin flag or grant arbitrary rights, fully compromising the FAQ application; publicly available exploit code exists is not asserted, and at time of analysis no public exploit identified at time of analysis.
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.
Unauthenticated account creation in phpMyFAQ versions before 4.0.18 allows remote attackers to register unlimited user accounts through the WebAuthn prepare endpoint without authentication, CSRF protection, or captcha validation, even when registration is disabled. Public exploit code exists for this vulnerability. Update to version 4.0.18 or later to remediate.
Missing authorization in the phpMyFAQ MCP server's faq_search tool allows an authenticated MCP client to read the full question-and-answer text of active FAQs that are restricted to specific users or groups, because the underlying Search::searchDatabase() routine never applies the per-user or per-group permission checks that normally govern FAQ visibility. The flaw affects phpMyFAQ through 4.1.10 and is limited to confidentiality: exploitation requires that the optional MCP server feature is deployed and reachable and that the attacker can connect to phpmyfaq:mcp:server with at least low-privilege access (CVSS PR:L, local attack vector), so this is a modest-priority issue rather than a high-urgency flaw. No public exploit identified at time of analysis and no vendor-released patch identified at time of analysis; the issue is tracked under CWE-862 (Missing Authorization).
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.
Information disclosure of inactive FAQ content in phpMyFAQ before 4.1.5 allows unauthenticated attackers to retrieve draft or review-only FAQs via specific public API endpoints. The flaw exposes non-public titles and full answers or previews through endpoints that inconsistently apply active-status and publication-date filters. Exploit code is publicly available, but no active exploitation has been confirmed.
Path traversal in phpMyFAQ's PDF export pipeline allows authenticated FAQ editors to read arbitrary server-side files by storing HTML with crafted image paths that exploit a type-juggling flaw in concatenatePaths(). When the substring 'content' is absent from an attacker-controlled path, strpos() returns false, which PHP silently coerces to integer 0, causing the full unsanitized path to pass through to file_get_contents() without canonicalization. No active exploitation is confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis, but the root cause is a low-complexity PHP type-juggling antipattern that is straightforward to weaponize once the attack surface is understood.
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.
Insufficient access controls in phpMyFAQ 4.0.16 and below expose sensitive information including user email addresses and non-public content through multiple API endpoints, allowing unauthenticated attackers to harvest data for phishing or access private records. Public exploit code exists for this vulnerability, and no patch is currently available. Upgrading to version 4.0.17 or later is required to remediate the exposure.
Authenticated users in phpMyFAQ 4.0.16 and below can bypass permission checks to download FAQ attachments they should not have access to, due to improper validation of authorization tokens in attachment.php and flawed permission logic. An attacker with valid credentials but without the dlattachment permission can exploit this to retrieve sensitive attachment content. Public exploit code exists for this vulnerability, and no patch is currently available.
phpMyFAQ versions 4.0.16 and below allow authenticated users to access the backup API endpoint without proper authorization checks, enabling them to download configuration files containing sensitive data. The vulnerability stems from incomplete authorization validation in SetupController.php, which only verifies authentication rather than admin permissions. Public exploit code exists for this issue, and no patch is currently available.
Unauthenticated attackers can force phpMyFAQ installations running versions prior to 4.0.16 to generate a full configuration backup ZIP inside a web-accessible directory and then simply download it, exposing database credentials and other configuration secrets. The POST /api/setup/backup endpoint performs no authentication, authorization, or API token verification, and the resulting archive is served from content/core/config/ under a date-stamped filename, so no user interaction or privileges are needed (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Publicly available exploit code exists - the vendor's GitHub advisory publishes a three-step curl proof of concept - and the information disclosed (database.php credentials, integration configuration) is well suited to follow-on compromise, making this a genuine high-priority issue rather than an inflated high-CVSS score.
Stored cross-site scripting in phpMyFAQ 4.0.14 and 4.0.15 allows an unauthenticated attacker (PR:N in the assessed vector) to execute arbitrary JavaScript in an administrator's browser by registering a user account whose display name contains HTML entities, which phpMyFAQ decodes server-side and then renders without escaping in the admin user list. Exploitation is conditional: public self-registration must be enabled (security.enableRegistration = true) and an administrator must actually open the admin user list page (/admin/user/list), so the payload stays inert until viewed (UI:R), giving an overall CVSS of 6.1. A working proof-of-concept with step-by-step reproduction is published in the vendor's GitHub security advisory, but there is no evidence of active exploitation and the issue is not listed in CISA KEV; version 4.0.16 contains the fix.
phpMyFAQ is an open source FAQ web application. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets unauthenticated remote attackers create multiple distinct accounts sharing the same email address because the createUser logic in RegistrationHelper.php and User.php performed no uniqueness check prior to 4.0.13. The practical consequence is account ambiguity rather than immediate compromise: data-integrity loss, colliding password-reset flows, and spam/duplicate pollution, with privilege escalation or account takeover possible only in specific configurations where a privileged account already exists under the targeted email and downstream flows key off the email instead of the unique user ID. A public proof-of-concept and the upstream fix commit are available, EPSS is negligible (0.05%, 16th percentile), and there is no indication of confirmed active exploitation (no CISA KEV), although the NVD headline CVSS of 9.8 substantially overstates real-world risk relative to our assessment of AV:N/AC:H/PR:N/UI:N/C:L/I:L/A:N.
phpMyFAQ is an open source FAQ web application. Rated medium severity (CVSS 5.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
phpMyFAQ is an open source FAQ web application. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated low severity (CVSS 2.7), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 7.2), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an Open Source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.2.1. Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.1. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Unrestricted Upload of File with Dangerous Type in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Unrestricted File Upload vulnerability could allow attackers to upload malicious files that can be executed on the server.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.16. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity.
Improper Neutralization of Formula Elements in a CSV File in GitHub repository thorsten/phpmyfaq prior to 3.1.16. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.0-beta.2. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.