CVE-2026-116019

Grav 2.0.0 through 2.0.24 contain a Twig content sandbox escape. The `array` filter is allowlisted but lacks the sandbox guard, allowing access to the raw DI container and disclosure of the full configuration tree, including credentials and secrets, to anonymous visitors.

Grav before 2.0.14 fails to guard the access field in the core group blueprint with the required security@: admin.super restriction. A delegated admin.users operator can save a group with access[admin][super]=true to escalate to super-admin, gaining scheduler and Twig evaluation capabilities.

Grav 2.0.4 (fixed in 2.0.7) contains a remote code execution vulnerability in Blueprint::dynamicData(). The function passes a Class::method callable string and its arguments directly to call_user_func_array() without any allowlist. Because the form plugin routes page frontmatter through this path, an authenticated account with admin.pages (or api.pages.write) permission can plant a malicious callable directive in a page. The command executes as the web-server user whenever anyone – including an unauthenticated visitor – accesses the page.

Grav before version 2.0.2 contains a Twig sandbox bypass that allows a page author (any admin.pages user, or anyone able to write to user/pages) to exfiltrate configuration secrets. Although the sandbox replaces the 'config' variable with a redacted facade and strips Config::get/toArray from the method allowlist, the raw container remains accessible via the allow-listed grav.offsetGet('config'), which returns the real Config object. Allow-listed object-dumping filters (json_encode, print_r, yaml_encode) then serialize that object at the PHP level without invoking the sandbox method gate, exposing the full config tree including plugin secrets such as SMTP credentials, API keys, and plugin DB credentials.

In grav before 1.7.49.5, a SSRF (Server-Side Request Forgery) vector may be triggered via Twig templates when page content is processed by Twig and the configuration allows undefined PHP functions to be registered.

Grav is a file-based Web platform. Prior to 1.8.0-beta.27, due to improper authorization checks when modifying critical fields on a POST request to /admin/pages/{page_name}, an editor with only permissions to change basic content on the form is now able to change the functioning of the form through modifying the content of the data[_json][header][form] which is the YAML frontmatter which includes the process section which dictates what happens after a user submits the form which include some important actions that could lead to further vulnerabilities. This vulnerability is fixed in 1.8.0-beta.27.

Grav from 1.7.53.3 before 1.7.53.6 contains an authorization bypass in Debugger::isDebuggerRequestAuthorized() that allows unauthenticated visitors to read /__clockwork/ profiler data via a loopback REMOTE_ADDR fallback. Behind a same-host reverse proxy, remote requests appear as loopback, letting attackers read stored records including administrator plaintext passwords and configuration credentials.

Grav from 2.0.0 before 2.2.5 contains an improper access control vulnerability in FlexDirectory::dynamicFlexField() that allows page authors to call arbitrary Flex object methods via flex-*@ directives in page frontmatter. When a user with page edit rights opens the page, directives calling setStorageKey() and delete() run in their session, deleting protected pages neither account may delete.

Grav from 2.0.0 before 2.2.5 contains an information disclosure vulnerability that allows page authors to capture visitors' HTTP Basic credentials through Twig page content. Authors can print the request Uri object, which embeds PHP_AUTH_USER and PHP_AUTH_PW, inside an inline style background image to exfiltrate administrators' credentials to an external host.

Grav 1.7.53 before 1.7.53.5 and 2.0.0-rc.8 before 2.2.2 contain a resource exhaustion vulnerability that allows anonymous visitors to bypass the system.images.max_pixels limit when system.images.url_actions is enabled. Attackers can send single-dimension or percentage forceResize, zoomCrop, or chained image actions to make GD allocate multi-gigabyte canvases, exhausting server memory and taking the site down.