How severe is CVE-2026-75837?

No CVSS score has been assigned to CVE-2026-75837 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-75837?

CVE-2026-75837 affects the following packages: getgrav/grav (Packagist). Ecosystems affected: Packagist.

How do I fix CVE-2026-75837?

Update getgrav/grav to 2.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-75837 is resolved across your whole dependency graph.

How do I detect CVE-2026-75837 in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getgrav/grav, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-75837 if there is no patch (or I can't update yet)?

Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Is CVE-2026-75837 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-75837 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-75837?

CVE-2026-75837 has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 40th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-75837?

CVE-2026-75837 is classified as Improper Privilege Management (CWE-269). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-75837 published, and has it been updated?

CVE-2026-75837 was published on August 18, 2026 and was last updated on September 10, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘 Packagist

Not in CISA KEV

CVE-2026-75837 — getgrav/grav

CVE-2026-75837 is a Improper Privilege Management vulnerability in getgrav/grav. A fix is available for getgrav/grav — see the affected versions and patch details below.

Grav before 2.0.14 Privilege Escalation via Group Access Field

Also known asGHSA-xhfv-7758-r9hx

Published

Aug 18, 2026

Updated

Sep 10, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 1, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-75837.

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk+0.16%

Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐘getgrav/grav

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The core Flex group blueprint system/blueprints/user/group.yaml (access field, lines 48-55) omits the security@: admin.super field guard that its sibling account blueprint carries (account.yaml:131/138/150, added by the CVE-2026-42613 fix). A delegated non-super operator holding admin.users.update can therefore save a group whose access map contains admin.super: true, which UserGroupObject::authorize then grants to every member of that group, a full privilege escalation to super-admin (scheduler/cron RCE, Twig eval). This is a distinct file, sink, and fix from all four related advisories.

Root Cause

The CVE-2026-42613 fix protected the account access/groups fields with a blueprint-level security@: admin.super gate, which Blueprint::dynamicSecurity() (system/src/Grav/Common/Data/Blueprint.php:644-662) uses to mark a field validate.ignore=true for non-super users so BlueprintSchema::filterArray() (BlueprintSchema.php:263-311) drops it. The functionally-identical group access field, a permission map granted to every member of the group, is declared in system/blueprints/user/group.yaml:48-55 with check_authorize: false and NO security@ guard. check_authorize has ZERO PHP enforcement (grep -rn check_authorize across the repo returns 0 PHP consumers; only two YAML blueprints reference it), so security@ is the sole real control. Because the group access field lacks security@, dynamicSecurity never flags it, filterArray retains it, and Validation::filterArray (type: array, value_type: bool) passes the nested admin.super:true leaf through. The core save path (FlexObject::update() then Framework/Flex/FlexObject.php:683 $blueprint->filter($data,true,true) then save()) persists it to user://config/groups.yaml.

Impact

A delegated admin.users operator (strictly below admin.super) escalates to super-admin, gaining the admin panel, the scheduler (cron to RCE) and Twig evaluation. Full read/write/DoS (C:H/I:H/A:H). Even absent self-escalation, arbitrary rewrite of ANY group's ACL is itself a full escalation primitive.

Proof of Concept

As a non-super admin.users operator who is a member of group ops:

POST /admin/accounts/groups/ops   (or groups.json task:save)
data[access][admin][super]=1

user/config/groups.yaml gains ops: { access: { admin: { super: true } } }, so the operator is super-admin on the next request.

Attack Chain

Entry: authenticated delegated admin (admin.users.update, no admin.super) POSTs the group-edit form for a group they belong to (or a new group), body access[admin][super]=true. Guard: FlexAuthorizeTrait::isAuthorizedAction to admin.users.update. Bypass proof: user-groups.yaml exposes groups at admin.users:crudl; operator legitimately holds update.
Check (field guard): Blueprint::dynamicSecurity marks validate.ignore only for security@ fields. Guard: none on group access (no security@). Bypass proof: group.yaml:48-55 has no security@; git log -S 'security@' -- system/blueprints/user/group.yaml is empty.
Filter: BlueprintSchema::filterArray retains the non-ignored field; Validation::filterArray (value_type: bool) passes admin.super:true through. Bypass proof: field not flagged ignore/disabled; nested bool leaf preserved.
Sink (persist): FlexObject::update then filter then save writes to user://config/groups.yaml. Guard: none. Bypass proof: value already survived steps 2/3; storage performs no ACL filtering.
Impact: any member request triggers UserGroupObject::authorize('admin.super') (.../UserGroups/UserGroupObject.php:75) returning true, so the member is super-admin, enabling scheduler/Twig RCE.

Bypass Evidence

system/blueprints/user/group.yaml:48-55: access block with check_authorize: false, no security@ (confirmed live on tag 2.0.12).
git log -S 'security@' -- system/blueprints/user/group.yaml is empty (guard never existed; a permanent gap, not a regression).
git log 2.0.12..HEAD -- system/blueprints/user/group.yaml is empty (no post-release fix).
grep -rn check_authorize (whole repo) returns 0 PHP hits (guard unenforced in PHP).
grep -rn "typePermissions|filterPermissions" system/src/Grav/Common/Data returns 0 (permissions map falls through to array-bool filtering that keeps nested keys).
Guard asymmetry: account.yaml:131/138/150 carry security@: admin.super; group.yaml carries none. GHSA-h33v-82r9-v8pm's own text confirms the blueprint security@ gate is the sole Flex-backend strip for these keys.

Affected Versions

<= 2.0.12 (latest release; the guard never existed on group.yaml, so all 2.x are affected). The missing guard and the strip logic are both in core getgrav/grav; the group-edit UI is provided by the flex-objects/admin plugin, but the fix belongs in core.

Suggested Fix

Add security@: admin.super to the access field in system/blueprints/user/group.yaml (mirroring account.yaml), and/or enforce a super-only strip on group ACL saves in core so all callers are covered.

Reported by zx (Jace) — GitHub: @manus-use

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`getgrav/grav`	all versions	2.0.14`composer require getgrav/grav:^2.0.14`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getgrav/grav, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update getgrav/grav to 2.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-75837 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Frequently Asked Questions

## Summary The core Flex group blueprint `system/blueprints/user/group.yaml` (access field, lines 48-55) omits the `security@: admin.super` field guard that its sibling account blueprint carries (`account.yaml:131/138/150`, added by the CVE-2026-42613 fix). A delegated non-super operator holding `admin.users.update` can therefore save a group whose `access` map contains `admin.super: true`, which `UserGroupObject::authorize` then grants to every member of that group, a full privilege escalation to super-admin (scheduler/cron RCE, Twig eval). This is a distinct file, sink, and fix from all four

O3 Security · Impact-Aware SCA

Is CVE-2026-75837 in your dependencies?

Find it across Packagist, including transitive dependencies.

Scan my dependencies How O3 SCA works