22
CVEs
2
Critical
7
High
0
KEV
0
PoC
1
Unpatched C/H
95.5%
Patch Rate
0.3%
Avg EPSS
Severity Breakdown
CRITICAL
2
HIGH
7
MEDIUM
13
LOW
0
Monthly CVE Trend
Affected Products (3)
Top Risky CVEs
| CVE | Summary | Severity | CVSS | EPSS | Priority | Signals |
|---|---|---|---|---|---|---|
| CVE-2026-76214 | 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. | CRITICAL | 9.1 | 0.3% | 46 |
|
| CVE-2026-76213 | 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. | CRITICAL | 9.1 | 0.3% | 46 |
|
| CVE-2026-76208 | 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. | HIGH | 8.8 | 0.3% | 44 |
No patch
|
| CVE-2026-75918 | 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. | HIGH | 8.7 | 0.3% | 44 |
|
| CVE-2026-76207 | 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. | HIGH | 8.6 | 0.3% | 43 |
|
| CVE-2026-76205 | 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. | HIGH | 8.6 | 0.2% | 43 |
|
| CVE-2026-85590 | 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. | HIGH | 7.1 | 0.4% | 36 |
|
| CVE-2026-85591 | 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. | HIGH | 7.1 | 0.3% | 36 |
|
| CVE-2026-76210 | 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. | HIGH | 7.1 | 0.3% | 36 |
|
| CVE-2026-75919 | 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. | MEDIUM | 6.9 | 0.4% | 35 |
|
| CVE-2026-85586 | 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. | MEDIUM | 6.9 | 0.4% | 35 |
|
| CVE-2026-76212 | 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. | MEDIUM | 6.9 | 0.3% | 35 |
|
| CVE-2026-76206 | 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. | MEDIUM | 6.9 | 0.3% | 35 |
|
| CVE-2026-76215 | 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. | MEDIUM | 6.9 | 0.2% | 35 |
|
| CVE-2026-85592 | 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. | MEDIUM | 6.3 | 0.2% | 32 |
|