Grav Login Plugin: Unauthenticated Privilege Escalation via Missing Server-Side Validation of User Metadata Fields

Vulnerability Analysis

1. Root Cause & Vulnerability Class

This is a missing server-side input validation vulnerability in the Login::register() method. The plugin performs conditional logic that only sets groups and access fields to configured defaults if they are absent from user-supplied POST data. If an attacker includes these fields in the registration request, the defaults are bypassed entirely. The only defensive layer is an admin-level configuration allowlist (fields), which is a policy control, not a hardcoded security boundary. No validation occurs to reject or sanitize attacker-controlled privilege-bearing metadata, resulting in unauthenticated privilege escalation to admin.super.

2. PoC Significance for Defenders

This PoC disclosure demonstrates a complete authentication context bypass: an unauthenticated user can register a new account and immediately assume administrative role without requiring email verification, admin approval, or privilege grant workflows. The vulnerability is highly reliable if registration is enabled and groups or access are in the allowed fields list. The precondition (registration enabled + specific config) is common in development/staging environments and non-hardened deployments. The PoC confirms that the plugin trusts client-supplied user metadata wholesale, a fundamental architectural flaw.

3. Detection Guidance

Log Indicators:

• Registration requests containing groups[] or access[] parameters with values like admin, super, or admin.super
• User creation events where groups field is set to privileged roles immediately after registration
• POST requests to /login.html or registration endpoint with unexpected metadata fields in payload

Signatures & Monitoring:

• Monitor for HTTP POST bodies in registration forms containing groups, access, or roles parameters
• Alert on newly registered users with admin.super or equivalent privileges without manual grant
• Track Grav user database (accounts/) for accounts created via registration with non-default group assignments
• YARA: Search plugin source for patterns like isset($data['groups']) without subsequent validation logic

4. Mitigation Steps (Defense Recommendations)

Immediate Actions:

• Disable registration in production if not required: set plugins.login.user_registration.enabled: false in Grav configuration
• Remove sensitive fields from allowed registration fields: ensure groups and access are NOT in plugins.login.user_registration.fields configuration
• Apply patches: upgrade to Grav Login plugin version > 3.8.0 when available (implement hardcoded validation that rejects/ignores attacker-supplied privilege fields)

Hardening:

• Implement server-side whitelist validation that explicitly rejects groups and access fields during registration, regardless of config
• Force user creation to use only configured defaults for metadata, disallowing override from POST data
• Add email verification before account activation as an additional friction layer
• Implement admin approval workflow for registration or require manual privilege grants
• Audit existing user accounts created via registration; flag any with unexpected privilege levels

5. Risk Assessment

Likelihood: High in development and minimally-hardened deployments. Moderate in production environments where registration is enabled but misconfigured. Threat Actor Interest: Significant—this provides direct path to account takeover (create admin account → full CMS control). Exploit is trivial requiring only HTTP client and knowledge of registration endpoint; no advanced exploitation techniques needed. In-The-Wild Exploitation: Probable; vulnerability likely discovered during security assessment phases. Mitigation Complexity: Low—configuration change or plugin update resolves issue.