Skip to main content

phpMyFAQ CVE-2026-111898

| EUVDEUVD-2026-103321 HIGH
Improper Authentication (CWE-287)
2026-10-17 VulnCheck GHSA-8rmr-jc2p-xv7g
7.7
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Control Keycloak identity with colliding username/email
  2. Exploit
    Initiate login via /auth/keycloak/authorize
  3. Execution
    Implicit linking binds attacker subject to local account
  4. Impact
    Inherit targeted account's superadmin privileges

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK

2 techniques across 2 tactics: Defense Evasion, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires that the phpMyFAQ instance be explicitly configured to use Keycloak as an SSO identity provider (the /auth/keycloak/authorize flow must be active) and that implicit account linking matches identities by preferred_username or email. The attacker must control a Keycloak identity whose preferred_username collides with, or whose unverified email matches, an existing local phpMyFAQ account - ideally a superadmin - so a pre-existing privileged local account is a prerequisite. Exploitation is strictly limited to versions 4.2.0-alpha up to (not including) 4.2.0-beta, which are pre-release builds, substantially reducing the realistic attack surface. Limiting factors: non-default deployment (Keycloak must be wired in), attacker must already possess or provision a Keycloak account (PR:L), and the username/email collision condition (AT:P/AC:H) must be satisfiable.

Impact

This is a medium-high severity authentication bypass (CVSS 4.0 base 7.7) in phpMyFAQ's Keycloak SSO integration, enabling full account takeover and superadmin escalation. The signals are mixed and point to a real-but-conditional issue rather than a mass-exploitation emergency. The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L) correctly reflects meaningful friction: network reachable, but high attack complexity and an attack requirement (AT:P), plus the attacker must already control a Keycloak identity (PR:L). No EPSS score was provided, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no public POC is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The impact triad is high (VC:H/VI:H/VA:H) because success yields superadmin control, but the scope-subsequent metrics are N, indicating no spillover to other systems. The single most important limiting factor - understated by raw severity - is that only pre-release builds (4.2.0-alpha through before 4.2.0-beta) are affected AND the deployment must have Keycloak SSO configured, drastically narrowing the real-world exploitable population. Net assessment: a legitimate priority for the specific organizations running phpMyFAQ 4.2.0 pre-release with Keycloak, but low urgency for the broader population.

Exploit ScenarioDerived

An organization runs phpMyFAQ 4.2.0-alpha configured to use Keycloak for SSO, with an existing local superadmin account. An attacker who can register or control a Keycloak identity sets their preferred_username or an unverified email to match the superadmin's, then logs in through /auth/keycloak/authorize; phpMyFAQ implicitly links the attacker's Keycloak subject to the privileged local account, granting superadmin access. No public exploit code is referenced, so exploitation would currently require independent development against this specific pre-release.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 17, 2026

Account takeover in phpMyFAQ's Keycloak single sign-on integration allows a holder of a Keycloak identity whose preferred_username collides with, or whose unverified email matches, an existing local phpMyFAQ account to bind that local account to their own Keycloak subject and inherit its privileges, including superadmin. Only pre-release builds from 4.2.0-alpha up to but not including 4.2.0-beta are affected, and exploitation additionally requires Keycloak to be explicitly configured as an identity provider with the /auth/keycloak/authorize flow and implicit account linking active, so the realistic attack surface is limited to non-default test and staging deployments (CVSS 4.0 base 7.7; PR:L, AC:H, AT:P per the assessed vector). No public exploit code has been identified at time of analysis, and the flaw is not listed in CISA KEV.

RemediationAI

Upgrade to phpMyFAQ 4.2.0-beta or later - the vendor-released patch, documented in GHSA-rg4w-2j3r-2hhp (https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-rg4w-2j3r-2hhp) and the VulnCheck advisory, closes the implicit-linking path by no longer auto-binding accounts on preferred_username or email matches. If upgrading is not immediately possible, remove Keycloak from the SSO configuration (or block the /auth/keycloak/authorize endpoint at the reverse proxy or web server) so the vulnerable linking flow cannot be reached - the trade-off is that federated logins fail and affected users must fall back to local credentials. Where Keycloak must stay live, require verified email addresses in every realm (Keycloak's 'Verify Email' setting) and strip or normalize the preferred_username claim for users whose addresses are unverified; this reduces but does not eliminate collisions, since a verified email can still legitimately equal a local account's address. Restrict SSO mapper claims to an immutable, administrator-controlled attribute such as the Keycloak subject UUID rather than user-editable usernames, and audit the existing user table for unexpected Keycloak subject bindings and for superadmin assignments that cannot be traced to intended administrators - reverting any suspicious link requires manual database review because the binding persists after patching.

Affected VersionsENISA

phpMyFAQ 4.2.0-alpha <4.2.0-beta

Affected Packages

euvd phpmyfaq fix: 4.2.0-beta

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

phpMyFAQ is a PHP-based FAQ and knowledge-base application; in the 4.2.0 pre-release line it gained a Keycloak SSO integration that handles OpenID Connect/SAML-style logins through the /auth/keycloak/authorize endpoint. The vulnerable behavior is an 'implicit account linking' design: when a Keycloak-authenticated user arrives, the application looks for an existing local account whose preferred_username equals the incoming preferred_username claim, or whose email equals the incoming email claim, and then permanently binds the Keycloak subject (sub) to that local record. Because preferred_username is often mutable or user-chosen in Keycloak realms and because email claims are not always verified, an attacker can satisfy the collision condition with a low-privileged self-provisioned Keycloak account and inherit the matched local account's role set. Root cause is CWE-287 (Improper Authentication) - the application trusts an unverified, non-unique claim as proof of identity and performs the link without requiring email verification, an administrator-approved link, or an already-established subject-to-account mapping. The CPE cpe:2.3:a:thorsten:phpmyfaq:*:*:*:*:*:*:*:*: covers the phpMyFAQ product family; the code path at issue exists only in the 4.2.0 pre-release builds.

Know when Phpmyfaq gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 7.7 HIGH
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 7.5 HIGH

Network-facing login flow (AV:N) but attacker must control a Keycloak identity (PR:L) and engineer a username/email collision against an existing account (AC:H); success grants full superadmin control (C/I/A:H).

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
High
Attack Requirements
Present
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 17, 2026 - 20:16 EUVD
CVE Published
Oct 17, 2026 - 18:46 cve.org
HIGH 7.7

DescriptionCVE.org

phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an authentication bypass vulnerability that allows Keycloak users to take over local accounts by matching preferred_username or email. Attackers controlling a Keycloak identity with a colliding username or unverified email can log in through /auth/keycloak/authorize to bind their subject and gain superadmin privileges.

Technical POC Analysis

CWE-287 (Improper Authentication): implicit, unverified account linking in phpMyFAQ's Keycloak SSO integration.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

phpMyFAQ pre-release 4.2.0-alpha builds expose an account-takeover path through the Keycloak SSO integration, potentially granting superadmin rights to an attacker who can bind a Keycloak identity to an existing local account. The risk is concentrated in non-default test and staging deployments where Keycloak is explicitly configured with implicit account linking, so leadership should treat this as a limited but serious exposure if those environments hold production-like data or credentials. No public exploit has been identified at time of analysis, and no vendor-released patch has been identified.

Business Impact: Medium
Compensating Controls

No vendor-released patch identified; disable Keycloak SSO and implicit account linking, remove affected 4.2.0-alpha pre-release builds from sensitive environments, restrict access, and monitor account-linking and authentication logs.

Threat Intelligence Overview

EPSS Score
0.3%
Top 74% exploitable
Prevalence
Low
niche open-source FAQ software; only unreleased 4.2.0 pre-release builds affected
Social Media
1
Sightings
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment CIRCL GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
Medium
Technical Impact
Total

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

CVE-2025-59943 CRITICAL POC
9.8 Oct 03

Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets una

CVE-2023-5865 CRITICAL POC
9.8 Oct 31

Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8

CVE-2023-1886 CRITICAL POC
9.8 Apr 05

Authentication Bypass by Capture-replay in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity

CVE-2023-1753 CRITICAL POC
9.8 Mar 31

Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity (CVSS 9.8), t

CVE-2022-3754 CRITICAL POC
9.8 Oct 29

Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), th

CVE-2026-46364 CRITICAL POC
9.3 May 15

Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and

CVE-2017-15730 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.ratings.php. Rated high severity (CVS

CVE-2017-15808 HIGH POC
8.8 Oct 23

In phpMyFaq before 2.9.9, there is CSRF in admin/ajax.config.php. Rated high severity (CVSS 8.8), this vulnerability is

CVE-2017-15735 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) for modifying a glossary. Rated high severity (CVSS

CVE-2017-15734 HIGH POC
8.8 Oct 22

In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.main.php. Rated high severity (CVSS 8

CVE-2024-28107 HIGH POC
8.8 Mar 25

phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi

CVE-2024-27299 HIGH POC
8.8 Mar 25

phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy