CVE-2026-76209

Executive Summary

CVE-2026-76209 is a broken access-control vulnerability affecting phpMyFAQ versions prior to v4.1.6. The flaw resides in the API layer, where the security.enableRegistration configuration flag — which is enforced by the HTML registration page — is not validated in the account-registration API endpoints. An authenticated attacker can create new user accounts on a phpMyFAQ instance even when the administrator has explicitly disabled self-registration, violating the intended access-control policy.

The vulnerability is rated CVSS 4.3 (medium severity) and is currently unpatched, with no public exploit code or advisory confirmed. Given the low technical complexity of the flaw (the endpoint exists and simply lacks a configuration check), the exploitation risk is elevated once the API endpoints are discovered. The primary impact is an integrity breach — unauthorized accounts created on a system where the operator has intentionally restricted membership — which can subsequently enable further attacks such as privilege escalation if account roles are misconfigured at creation time.

Technical Analysis

The vulnerability class is CWE-862: Missing Authorization. The NVD description indicates that phpMyFAQ's security.enableRegistration setting is evaluated on the server-side HTML registration flow (the traditional web form), which blocks new registrations when the flag is set to false. However, the equivalent API endpoints — specifically POST /api/register and POST /api/v3.1/register — do not perform this check.

This is a classic server-side enforcement gap where two distinct code paths implement the same business logic (user registration) but only one path enforces the configuration constraint. The HTML form and the API controller are implemented independently, and the API route handlers were evidently written without a call to the configuration service that reads security.enableRegistration.

Functionally, the request flow is as follows:

1. An attacker determines the target phpMyFAQ version (v4.1.x or earlier) and confirms the API is reachable.
2. The attacker submits a standard POST /api/register or POST /api/v3.1/register request with a JSON payload containing the desired username, email, and password.
3. The API controller accepts the payload, validates the field format (email syntax, password length), but does NOT inspect the security.enableRegistration configuration value.
4. A new user account is persisted in the database with the role assigned by the default registration role configuration (frequently basicuser or similar low-privilege role). The email field is likely set to the attacker-supplied value, and no verification step is enforced because the "verification required" configuration is also bypassed (since it is typically tied to the same registration flag mechanism).

The attack surface is a public-facing web application that exposes REST-style API endpoints. The endpoints are documented in the phpMyFAQ API documentation for v3.x and v4.x, meaning any attacker who can fingerprint the application can identify the exact routes. The vulnerability is not directly exploitable by unauthenticated actors in the standard sense, because the CVSS vector specifies PR:L (low privileges required). This creates an interesting nuance — the attacker needs some pre-existing access to the application. This could be a read-only level account (e.g., a user who was created before the registration was disabled), or the attacker could chain this with another vulnerability that provides low-level access. It is also possible that in certain deployments the API endpoints are accessible without authentication for the registration action (some APIs treat registration as a public endpoint), which would effectively downgrade the privilege requirement to PR:N. The NVD vector, however, explicitly states PR:L, so the report assumes an authenticated attacker.

The discrepancy between the CVSS PR:L and the endpoint's apparent public accessibility is worth noting for SOC analysts: the CVSS scoring may reflect the vendor's assessment that the API is behind an authentication layer in the default configuration, or that the attacker must already possess a low-privilege account to reach the registration route.

Exploitation Scenarios

Prerequisites:

• A phpMyFAQ instance running version < 4.1.6.
• An attacker with at least low privileges on the application (per CVSS PR:L), OR the API registration endpoint is reachable without an auth token (in which case the actual exploit requires no prior access).
• The security.enableRegistration setting is set to false on the target instance.

Attack Chain (inferred from vulnerability class; no public PoC available):

1. Reconnaissance / Target Identification: The attacker fingerprints the target as phpMyFAQ. This can be accomplished by examining the login page HTML source (which contains phpMyFAQ-specific meta tags and assets), inspecting the robots.txt for /api/ paths, or observing the X-Powered-By header. Shodan queries such as http.title:"phpMyFAQ" can identify internet-facing instances.

2. Pre-authentication / Authentication: The attacker authenticates with an existing low-privilege account (e.g., a user created prior to the registration disable), or determines that the API endpoint POST /api/register does not mandate a Bearer token (this behavior is inconsistent across phpMyFAQ versions; in v3.x the register route is public by design until disabled). If the latter, the attacker skips this step.

3. Triggering the Flaw: The attacker constructs a standard HTTP request:

   POST /api/v3.1/register HTTP/1.1
   Host: target.example.com
   Content-Type: application/json
   
   {
     "username": "attacker_controlled_username",
     "email": "attacker@example.com",
     "password": "Str0ng!Passw0rd"
   }
   

   The API controller processes the request, validates the payload schema, creates the user record, and returns either 201 Created (success) or 200 OK with the new user object. The controller never consults the security.enableRegistration config value.

4. Post-exploitation Impact: The attacker now holds a valid account on a system where registration was administratively disabled. Leveraging this new account, the attacker can:

   • Access member-only content, forums, or FAQ entries reserved for registered users.
   • Potentially escalate privileges if the instance's "default registration role" is set to a privileged group (e.g., moderator or editor). This is a configuration-dependent impact.
   • Establish persistence: the rogue account remains usable unless an administrator manually audits and removes it.

Vulnerability-class limitations: Because the NVD description does not specify whether the created user receives a default role, elevation to administrator is not guaranteed. The described exploit is limited to bypassing the registration restriction and potentially accessing restricted content.

Impact Assessment

CVSS Analysis: The vulnerability scores 4.3 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N.

• Attack Vector (AV:N): Network-exploitable — the API endpoint is reachable over the network.
• Attack Complexity (AC:L): Low — no specialized conditions, race conditions, or win-the-lottery requirements. The request either succeeds or fails deterministically.
• Privileges Required (PR:L): The attacker needs a low-privilege account. This could be a normal user who registered before the admin disabled registration, or a user provisioned by an administrative import.
• User Interaction (UI:N): None required.
• Scope (S:U): Unchanged — the compromised component (account store) is the same as the vulnerable component.
• Confidentiality Impact (C:N): The attacker does not directly read unauthorized data beyond the capabilities of their newly created low-privilege account.
• Integrity Impact (I:L): A new user record is created without authorization — a low-severity integrity violation.
• Availability Impact (A:N): No denial-of-service impact.

Business Impact:

• Registration policy bypass: The core business control of "closed community" is undermined. Organizations running phpMyFAQ as a members-only knowledge base with registration disabled will find unauthorized personas appearing.
• Content confidentiality erosion: If the FAQ contains member-only entries (e.g., internal procedures, pricing sheets, partner documents), the new accounts can access them, potentially leaking proprietary information.
• Audit and compliance: User lifecycle controls are a standard compliance requirement; undocumented account creation events can fail audit reviews.
• Account hygiene: The rogue accounts consume database slots, and if not cleaned, swell the user table, complicating future audits.

Affected Systems: All phpMyFAQ instances running versions prior to 4.1.6 that expose the API endpoints. This includes both the v1.x (deprecated api/register) and v3.x (api/v3.1/register) API route versions. Instances running behind a reverse proxy that blocks /api/ paths are not exposed to this flaw.

Detection Guidance

Sigma Rule

title: phpMyFAQ Registration API Abuse - Creation with Registration Disabled
id: c5415a2e-8f0f-4b6c-9a5e-7f2d8a1b3c4d
status: experimental
description: Detects POST requests to phpMyFAQ registration API endpoints which bypass the security.enableRegistration configuration flag.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-76209
author: Valters IT Security Team
date: 2026/01/15
logsource:
    category: webserver
    product: apache
    definition: 'Web server access logs for phpMyFAQ application'
detection:
    selection:
        cs-method: 'POST'
        cs-uri-path|contains:
            - '/api/register'
            - '/api/v3.1/register'
    filter_known_good:
        cs-uri-path|endswith: '/api/register'
        cs-username|exists: true
        sc-status: 200
    condition: selection and not filter_known_good
level: medium
falsepositives:
    - Legitimate administrative user registrations via API (rare in locked-down environments)
fields:
    - c-ip
    - cs-username
    - cs-uri-path
    - cs-user-agent
tags:
    - attack.initial-access
    - attack.t1190
    - cve.2026-76209

YARA Rule

rule phpMyFAQ_Registration_Bypass_CVE_2026_76209
{
    meta:
        author = "Valters IT Security"
        description = "Detects HTTP requests targeting phpMyFAQ registration API endpoints with POST method"
        cve = "CVE-2026-76209"
        date = "2026-01-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-76209"
    strings:
        $register_v1 = "/api/register" ascii wide nocase
        $register_v3 = "/api/v3.1/register" ascii wide nocase
        $post_method = "POST" ascii wide nocase
        $content_json = "Content-Type: application/json" ascii wide nocase
        $username_field = "\"username\"" ascii wide nocase
        $password_field = "\"password\"" ascii wide nocase
    condition:
        any of ($register_*) and $post_method and any of ($content_json, $username_field, $password_field)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-76209 - phpMyFAQ Registration API Registration Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/register"; http.uri; content:"/api/v3.1/register"; classtype:attempted-user; sid:7620901; rev:1; metadata:cve CVE-2026-76209, attack_target web_server, deployment perimeter, tag register-bypass;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [network where event.type == "start" and network.protocol == "http" and
     http.request.method == "POST" and
     (http.request.uri like "*api/register*" or http.request.uri like "*api/v3.1/register*")
  ]
  [http where http.request.body from "application/json" and
     http.request.body contains "username" and http.request.body contains "password"
  ]

Splunk SPL Query

index=web earliest=-7d
| where method="POST"
| where like(uri_path, "%api/register%") OR like(uri_path, "%api/v3.1/register%")
| table _time, src_ip, uri_path, method, status, user_agent
| stats count by src_ip, uri_path, status
| where count > 3
| sort - count
| rename src_ip as "Source IP", uri_path as "Endpoint", status as "HTTP Status", count as "Request Count"

Wazuh OSSEC Rule

<group name="phpmyfaq,api,access_control,">
  <rule id="762090" level="8">
    <decoded>web-access</decoded>
    <match>POST</match>
    <regex>^\S+\s+\S+\s+\S+\s+POST\s+\S+\s+(/api/register|/api/v3.1/register)\s+\S+\s+\S+</regex>
    <description>phpMyFAQ registration API endpoint triggered (CVE-2026-76209)</description>
    <group>cve-2026-76209,registration-bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No official patch, vendor advisory, or security release has been identified for CVE-2026-76209 as of this report. The fix is expected in phpMyFAQ v4.1.6, but no public artifacts confirming the patch have surfaced.

1. Immediate Mitigations (do these NOW):

• Network-level restriction: Block access to the /api/register and /api/v3.1/register endpoints at the reverse proxy or WAF level. Since legitimate registrations should be disabled in the affected configuration, no functional loss is expected:
  • Nginx: location ~ ^/api/(v3\.1/)?register { deny all; }
  • Apache: <LocationMatch "^/api/(v3\.1/)?register"> Require all denied </LocationMatch>
• API authentication enforcement: If the API endpoints are not already behind an authentication middleware, add a rule that requires a valid Bearer token for all /api/* requests that are not explicitly whitelisted.
• Disable the API entirely if the phpMyFAQ installation does not rely on it (many small deployments only use the web UI). This is achievable via the configuration file (e.g., api.enabled = false) or by disabling the REST API module in the web server.
• Manual user audit: Review the user database for accounts created after registration was disabled; remove any suspicious records.

2. Patch / Upgrade Steps:

• Monitor the official phpMyFAQ GitHub repository (github.com/thorsten/phpMyFAQ) and the project's release notes. When v4.1.6 (or later) is published:
  • Perform a full backup of the database and web root.
  • Run composer update or composer install to pull the new dependencies, then copy the updated source over the existing web root.
  • Re-run the database migration script (php /path/to/phpmyfaq/setup/update.php).
  • Verify the security.enableRegistration flag now blocks API registration by attempting a test registration after the upgrade (expected result: HTTP 403 or 409).

3. Long-term Hardening:

• Apply least privilege roles: Ensure the default registration role (security.registration.role) is basicuser (or the lowest available role) if registrations are ever re-enabled.
• Enable email verification: Set security.registration.needsActivation = true so any future API-registered accounts are not active until confirmed.
• Harden the API: Ensure all API routes use consistent authorization checks. Consider using an API gateway that enforces a policy that reads the same configuration store as the web application.
• Regular account lifecycle reviews: Schedule a monthly review of all users, flagging accounts that were created outside the window of enabled registration.
• Monitor upstream advisories: Subscribe to the phpMyFAQ security mailing list or GitHub watch notifications to receive patch announcements.

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2026-76209
2. phpMyFAQ Official Website — https://www.phpmyfaq.de/ (project status and release announcements)
3. phpMyFAQ GitHub Repository — https://github.com/thorsten/phpMyFAQ (source code, issue tracker, releases)
4. CWE-862: Missing Authorization — https://cwe.mitre.org/data/definitions/862.html (common weakness reference)
5. CVSS Calculator (FIRST.org) — https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Threat actor activity: No known campaigns or exploit-in-the-wild incidents have been reported for this CVE at the time of writing. The CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. The risk is nonetheless deemed elevated due to the trivial nature of the bypass — the fix merely requires adding a configuration check to the API controller — and the commonality of phpMyFAQ deployments (it is a popular open-source FAQ/knowledge-base system with substantial installed base).