phpMyFAQ Allows Unauthenticated Account Creation via WebAuthn Prepare EndpointGHSA-w22q-m2fm-x9f4
HIGHFix: thorsten/phpMyFAQ@f2ab673GHSA-w22q-m2fm-x9f4 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.
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 GHSA-w22q-m2fm-x9f4.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
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 |
Affected Products
phpmyfaqphpmyfaqDetection & 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 GHSA-w22q-m2fm-x9f4 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-w22q-m2fm-x9f4 in your dependencies?
Find it across Packagist, including transitive dependencies.