Getgrav
Monthly
An allowlist bypass in Grav CMS 2.0.15 through 2.2.12 lets an authenticated account holding page-edit permission (api.pages.write, or admin.pages in the classic admin) invoke arbitrary public static PHP methods by smuggling a data-*@ directive past Grav's Class::method allowed-callable check inside a page-authored Flex form override; methods such as Folder::delete, Folder::move, Folder::copy or Utils::download can then delete directories, move or overwrite files, and read files outside the page tree. The crafted directive fires when the page's Flex form is built, for example when an administrator opens the page on the site, so the payload is planted by the lower-privileged editor and executed in an administrator's request. The vendor shipped a complete fix in 2.2.13; the earlier 2.2.2 patch (GHSA-9rq7-4cch-f22j) only closed the replace-name@ spelling and leaves installations exploitable, and no public exploit code was identified at time of analysis.
Authenticated page editors in Grav CMS 2.0.0 through 2.2.4 can abuse flex-*@ frontmatter directives to invoke Flex object methods in another editor's session when that editor opens a crafted page, allowing unauthorized deletion of protected pages. The flaw is an access-control/confused-deputy issue in FlexDirectory::dynamicFlexField() and carries a High CVSS 4.0 score of 7.0, though exploitation requires an existing page-edit account plus a second editor opening the page. No public exploit code or confirmed active exploitation was identified at time of analysis.
Authorization bypass in the Grav Flex Objects plugin 1.4.0 through 1.4.16 lets authenticated, non-super users holding api.access plus either admin.pages or admin.configuration.pages read page source and frontmatter, modify content, and delete pages they are explicitly denied, because the generic /api/v1/flex-objects/pages routes enforce only directory-level admin.pages checks instead of the Pages API's api.pages.read/write and page-level permission rules. Scored 7.1 with an independent assessment of high confidentiality and high integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), the flaw is a privilege-escalation problem past intended per-page restrictions rather than an anonymous compromise path - the attacker must already hold a valid restricted admin or editor account, and super-user accounts are unaffected. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so this is a moderate-priority remediation item rather than a drop-everything emergency.
Privilege escalation in the Grav Login plugin (3.6.0 before 3.9.13) allows page authors to obtain super-user accounts by defining an invitation form in page frontmatter and submitting the login.invite task without authentication. The missing authorization check requires an existing authenticated page-author foothold (PR:L) to plant the invitation form, so it is not exploitable by a fully anonymous outsider; no public exploit code or CISA KEV entry was identified at time of analysis. This is a credible, actionable privilege-escalation issue rather than a drop-everything remote-root flaw.
Denial of service in Grav CMS 1.7.53 before 1.7.53.5 and 2.0.0-rc.8 before 2.2.2 lets unauthenticated remote attackers exhaust server memory by bypassing the system.images.max_pixels safeguard when system.images.url_actions is enabled. Attackers use single-dimension or percentage forceResize, zoomCrop, or chained image actions to force PHP's GD library to allocate multi-gigabyte canvases and take the site down. No public exploit identified at time of analysis; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms this is an availability-only threat requiring the url_actions setting to be enabled.
Information disclosure in Grav CMS 2.0.0 through 2.2.1 allows authenticated page editors to expose protected configuration - including security.salt, plugin credentials, and Redis passwords - to every visitor of the affected page by inserting config-*@ directives into a page's frontmatter form. The bypass defeats the Twig sandbox's config_denied_paths redaction, so values the CMS intends to keep internal are rendered into public page output. Our assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N rather than the advisory's 8.7 CVSS:4.0 vector, because exploitation requires an account already holding page-edit rights; no public exploit code or confirmed active exploitation was identified at time of analysis, and real-world impact depends on whether the deployment actually stores secrets in flat-file configuration.
Grav CMS 2.0.15 through 2.1.x (before 2.2.2) allows authenticated users with page-edit permission to bypass the Flex form callable allowlist and invoke arbitrary public static methods such as Folder::delete, Folder::move, and Utils::download. By renaming a Flex form field using the replace-name@ syntax, an editor can smuggle data-*@ directives past validation, enabling directory deletion, file overwrite, and arbitrary file reads. No public exploit code has been identified at time of analysis, and exploitation requires an authenticated editor account rather than anonymous access.
Unauthenticated resource exhaustion in the Grav API plugin (grav-plugin-api) before 1.0.42 allows any remote attacker who can reach GET /api/v1/translations/{lang} to make the plugin cache a full ~560 KB translation dictionary for each well-formed language code, potentially filling disk or APCu; separately, authenticated accounts with api.pages.write can bypass target/destination page rules in the sync and batch copy endpoints to overwrite translations or create pages that page-level rules deny. The plugin is an optional add-on rather than part of a default Grav install, which limits exposure, and no public exploit has been identified at time of analysis.
Information disclosure in Grav CMS before 2.1.7 lets unauthenticated remote attackers retrieve Git metadata from nested repositories - for example /user/.git/ - exposing git config, refs, and object files that can be used to reconstruct unpublished history or recover committed secrets. The flaw exists because the web-server configurations bundled with Grav for nginx, lighttpd, IIS, and Caddy 2 block dot-prefixed paths such as .git only at the document root, so repositories created below the root (a version-controlled user/ directory, or git-installed plugins and themes) remain web-readable. No authentication or user interaction is required; no public exploit code or confirmed active exploitation was identified at time of analysis, and real-world impact is gated by the deployment precondition that a web-reachable nested Git repository actually exists and contains private history or sensitive commits. The vendor advisory (GHSA-5vx9-x8f2-f55w) points to the 2.1.7 release as the fix.
Unauthenticated information disclosure in Grav CMS 2.0.22 through 2.1.6 lets attackers read sensitive Clockwork profiler records - including system and plugin configuration, secrets, request metadata, and database queries - when the profiler is active and the site sits behind a same-host HTTP proxy. The flaw is an authentication bypass: the profiler treats any request whose REMOTE_ADDR is a loopback address (e.g. 127.0.0.1) as an authorized local client, so requests forwarded through a co-located proxy inherit that trust. Exploitation is conditional rather than trivial - the profiler is a debug feature and must be enabled, and the attacker must be able to reach the application through the loopback-presenting proxy path; no public exploit code was identified at time of analysis, and this is not a CISA KEV entry. The impact is confidentiality-only (no integrity or availability effect) and is best characterized as a genuine but conditional disclosure flaw rather than a blanket high-severity emergency.
Memory exhaustion denial of service affects Grav CMS versions before 2.1.7, where an authenticated user with media-author upload privileges can submit a highly compressed oversized raster image that, when referenced through a Twig or Markdown image transform, is fully decoded by GD or Imagick without source-dimension validation. Once the transformed image is embedded in published content, unauthenticated page requests repeatedly trigger the decode-and-allocate behavior, causing sustained page unavailability; the assessed CVSS 4.0 base score is 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VA:H), and no public exploit code was identified at time of analysis.
Authentication bypass in the Grav Login OAuth plugin before 1.4.3 lets unauthenticated remote attackers derive valid credentials for OAuth-provisioned accounts and take administrative control. The plugin assigns each auto-provisioned user a deterministic '<provider>.<id>' username and an unsalted MD5 hash of the provider identifier as the password, and it leaves password login enabled; anyone who learns or guesses the provider identifier can reproduce the login. No public exploit identified at time of analysis; the vendor-assigned CVSS 4.0 score is 9.3 Critical and the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
Privilege escalation in the Grav API plugin (grav-plugin-api) before 1.0.36 allows an account that already holds the api.users.write capability - a delegated user manager rather than a super-admin - to obtain full super-admin API access. The attacker edits account access maps or pending invitations so that a positive scalar value is stored on an 'admin' or 'api' parent grant; the plugin's inheriting permission resolver then treats that grant as satisfying its requireSuper checks, exposing super-only API endpoints. Exploitation is authenticated and requires the high-privilege api.users.write capability (CVSS vectors show PR:H, scope unchanged), so the flaw matters mainly where user-management rights have been delegated below super-admin; no public exploit code or confirmed active exploitation was identified at time of analysis.
Page editors on Grav CMS versions 2.0.22 through 2.1.6 can render the Clockwork debugger's system.debugger.token via editor-authored Twig and replay it as the X-Clockwork-Auth header, disclosing profiler records that contain configuration values, request metadata, and database queries. The flaw is an authenticated, page-editor-level information disclosure (CVSS 4.0 base 7.1; independent assessment CVSS 3.1 AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N) that requires the Clockwork debugger to be enabled so that a token and profiler records exist; it is not anonymously reachable. Exploitation status: no public exploit identified at time of analysis, and the issue is remediated by upgrading to 2.1.7, which adds system.debugger.token to the Twig sandbox redaction list. This is a moderate-priority information disclosure flaw, not a critical emergency, because it needs valid editor credentials and Twig authoring rights and yields read-only exposure.
Password-reset token disclosure in the Grav Login plugin (versions 1.2.0 up to but not including 3.9.9) allows any user holding a publisher-level account to hijack more privileged accounts. A publisher authors a page at the plugin's password-reset route so that Login::getPage() renders attacker-controlled content on that route; when a higher-privileged victim opens an emailed reset link, the rendered page exposes the victim's username and bearer reset token, which the attacker can redeem to take over the account. Exploitation requires an existing publisher account plus victim interaction (clicking the emailed reset link), and no public exploit code or CISA KEV entry has been identified at time of analysis.
Two-factor authentication bypass in the Grav Login plugin versions 2.7.0 through before 3.9.9 allows an authenticated remote attacker who already possesses a valid password to restore a remember-me cookie issued after the password step and obtain a fully authorized session without completing the second factor, yielding high confidentiality and integrity impact. This is a genuine elevated-priority issue for environments using the plugin with 2FA and remember-me enabled, though not a mass-exploitation emergency; no public exploit identified at time of analysis.
Authentication bypass in Grav Login plugin versions 2.7.0 before 3.9.9 allows attackers who already know a victim's password to disable two-factor authentication (2FA) and take over the account by invoking the update_user task through a published page form without an access rule. The flaw resides in processUserProfile(), which verifies that a session user exists but fails to confirm that a pending front-end 2FA session is fully authorized. Exploitation requires three conditions: the attacker must possess the victim's password, have an in-progress front-end login that has reached the 2FA step, and be able to publish a Grav page form lacking an access rule; no public exploit has been identified at time of analysis.
Stored cross-site scripting in the Grav Data Manager plugin (getgrav/grav-plugin-datamanager) versions 1.0.1 through 1.4.4 allows an unauthenticated visitor to plant an HTML/JavaScript payload through a front-end form whose submissions are written into the user/data store; that payload is later rendered unescaped in the classic admin panel's item-detail view and executes in the administrator's browser session and origin, with access to that administrator's privileges and CSRF token. Exploitation requires a specific but realistic configuration chain: the site must route front-end form submissions into user/data, and the administrator must open the malicious entry in the classic Grav admin panel - sites running the Grav 2.0 Admin Next interface are not affected because it renders the same data through a separate, correctly escaping code path. The initial injection is unauthenticated (CVSS PR:N), while the privilege-boundary crossing needs administrator interaction (UI:R); payloads in list-type values such as checkboxes or multi-selects fire on view with no further interaction, whereas ordinary text fields fire on hover. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is fixed in Data Manager 1.4.5.
Unauthenticated information disclosure in the getgrav/grav-plugin-comments plugin (through 1.2.10) lets a remote attacker retrieve every comment posted to a Grav site in the last 7 days, including each commenter's email address and the absolute server filesystem path of the underlying data file, simply by sending a GET request to /admin/comments/page:<n> (for example page:0.001). The vulnerable admin handler performs its authorization check against isAdmin(), which only signals that the admin service is registered on the current route rather than that the visitor is authenticated, and it emits the JSON response and calls exit() during the plugins stage before the classic Admin plugin can render its login screen. Exploitation requires the site to run the classic Grav Admin plugin with the Comments plugin enabled (the default configuration), and is a genuine but bounded risk: no public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the assessed impact is limited to confidentiality (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), with no write or code-execution capability - the 8.7 CVSS 4.0 score published with the CVE reflects a higher-confidence confidentiality weighting than this assessment supports. The issue is fixed in 1.2.11.
Session cookie theft in Grav CMS 2.0.19 through 2.0.24 lets an authenticated user with only page-write permission capture the session identifier of any administrator who views their published page, because the Twig sandbox exposes get_cookie() and the post-Twig page cache is keyed without any session or request dimension. The poisoned cache then serves the stolen identifier to unauthenticated visitors, who can replay the cookie to authenticate as the administrator, yielding full confidentiality, integrity and availability impact on the instance. Exploitation is confirmed against default configurations in 2.0.19-2.0.24 (security.twig_content.process_enabled defaults to true and Security::applyTwigContentDefault() enables process.twig on every page), while 2.0.0-2.0.18 and 1.7.x are only affected if content Twig was explicitly enabled. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor-released fix is Grav 2.0.25, and 1.7.x is outside the backport scope.
Privilege escalation in Grav CMS 2.0.14 through 2.0.24 allows an authenticated backend operator who already holds the admin.users permission - but not admin.super - to grant super-admin rights to their own account or to a group they belong to via the flex accounts backend. The bypass works because the security guard is resolved against a field's exact blueprint path, so a crafted flat dot-notation key such as access.admin.super evades the rule match and is later reconstructed into a genuine nested value when the object is saved. No public exploit code has been identified at time of analysis, and because the attacker must already possess privileged but non-super backend access, this is an insider or post-compromise escalation vector rather than a remote unauthenticated one - but the resulting super-admin control over configuration, plugin and theme installation, the file manager, and all accounts makes it a genuine, high-value escalation rather than a high-CVSS-but-low-real-risk issue.
Information disclosure in Grav CMS before 2.0.25 lets unauthenticated remote attackers read sensitive files - configuration secrets and account password hashes - when the site is served by Microsoft IIS using the bundled webserver-configs/web.config over a case-insensitive filesystem such as NTFS, simply by varying the case of a folder name or extension (for example GET /user/CONFIG/system.YAML) so that none of the case-sensitive URL Rewrite deny rules match. The practical blast radius is narrower than the raw path-bypass suggests: whether a bypassed file is actually returned depends on MIME registration, with .json served by default while .yaml/.yml return HTTP 404.3 on a stock IIS unless a YAML MIME mapping has been added; the equivalent gap in webserver-configs/lighttpd.conf is lower risk because lighttpd typically runs on case-sensitive filesystems, and deployments behind Apache (.htaccess), nginx, Caddy, or the PHP built-in server are not affected. No public exploit identified at time of analysis, and while the vendor-released patch is Grav 2.0.25, upgrading alone is insufficient because the .htaccess installer heal does not rewrite web.config or lighttpd.conf, so operators must manually re-copy the corrected sample files.
An authenticated user who can author raw Twig in page content on Grav CMS 2.0.0 through 2.0.24 can escape the Twig content sandbox and read the site's entire configuration tree, exposing plugin credentials, SMTP and OAuth secrets, Redis passwords, proxy URLs, and the security.* subtree that the sandbox's redaction is designed to hide. The escape works because the `array` filter and its function form are allowlisted in the sandbox without the needs_is_sandboxed guard carried by print_r, vardump, json_encode, yaml_encode and string, and its implementation calls toArray() or an (array) cast without consulting the sandbox method allowlist, so `grav|array` unwraps the raw Pimple dependency-injection container and its private $values. Because the payload is stored in page content, the disclosed configuration is rendered to unauthenticated visitors; exploitation requires the authoring privilege (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and no public exploit was identified at time of analysis. Grav 1.7 is not affected because it has no Twig content sandbox, and the issue is fixed in Grav 2.0.25.
Grav CMS 2.0.0-rc.1 through 2.0.21 discloses its entire merged configuration - including plugin-level secrets such as SMTP credentials, API tokens, webhook secrets and cache backend passwords - to an authenticated user with page-edit rights who renders a dump/serialize filter such as {{ config|print_r }} in page content that has Twig processing enabled. The Twig content sandbox guard introduced in GHSA-mc5q-6hpj-rp7j never fires because GravExtension::assertSandboxDumpSafe() calls SandboxExtension::isSandboxed() without a Source argument, which reports only the global sandbox flag that Grav never enables; this is a privilege-to-secrets escalation rather than an unauthenticated exposure, since editor-level access is a prerequisite. Vendor-released patch: 2.0.22, where the affected filters are registered with Twig's needs_is_sandboxed flag; Grav 1.7 is not affected because it ships no Twig content sandbox, and no public exploit identified at time of analysis.
Unauthenticated information disclosure in Grav CMS 1.7.0 through 1.7.53.2 and 2.0.0 through 2.0.21 allows any remote attacker who can reach the site to read stored request cookies, plaintext login credentials, and the complete system and plugin configuration - including operator-saved SMTP credentials, third-party API keys, and licence keys - whenever the optional debugger (system.debugger.enabled: true, not the shipped default) has been left enabled. Rated CVSS 4.0 base 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) and consistent with the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, exploitation is network-based, low-complexity, and requires no privileges, authentication, or user interaction, with high confidentiality impact and no integrity or availability effect. Exposure is limited to development, staging, or misconfigured production installs where the debugger was deliberately turned on; no public exploit code was identified at time of analysis.
Host header injection in the Grav API plugin's forgot-password endpoint allows unauthenticated remote attackers to redirect password-reset tokens to attacker-controlled domains, enabling full account takeover including super-admin accounts. The plugin blindly incorporates the HTTP Host header when constructing reset links dispatched to victims' inboxes; an attacker who spoofs this header and induces the target to click the resulting email link captures the token and seizes the account. All Grav API plugin deployments running versions prior to 1.0.20 are affected; no public exploit code or CISA KEV listing has been identified at time of analysis, though the attack is straightforward to execute.
Privilege escalation in grav-plugin-api before 1.0.20 allows a low-privileged API manager to self-create a super-admin account by exploiting a logic gap in the InvitationsController's stripSuperFlags() method, which strips nested super flags but ignores dot-keyed equivalents such as 'api.super'. The attacker crafts an invitation payload containing the dot-keyed flag, which persists through sanitization into the new account, then self-accepts the invitation via the public acceptance endpoint - no real invitee participation required - and immediately receives a valid JWT granting full Grav site control. No public exploit or CISA KEV listing is present at time of analysis, but the attack is fully self-contained and conceptually trivial for any account already holding api.users.write permissions.
Privilege escalation in grav-plugin-api before 1.0.20 allows authenticated API users holding api.access and api.users.write permissions to overwrite the password of super-admin accounts whose elevated status is inherited through group membership rather than direct assignment. The user-management guard fails to evaluate group-inherited super status, treating those accounts as unprotected targets. An attacker who successfully exploits this gains full Grav CMS administrative control. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.7 reflects high impact across confidentiality and integrity.
Remote code execution in Grav CMS (versions ≤2.0.17) lets authenticated users holding only page-write rights achieve arbitrary PHP execution on the web server by exploiting a Twig sandbox bypass in the |sort filter. The sortFunc wrapper in GravExtension.php incorrectly hardcodes isSandboxed=false-unlike |map, |filter, and |reduce-allowing |sort to resolve plain PHP callable names including spl_autoload, which is absent from the function denylist and performs a PHP include operation. A content editor can deliver a crafted payload through mechanisms such as form frontmatter rendered by the Email plugin, resulting in code execution as the web server user. A vendor-released patch is available in version 2.0.19, and no active exploitation appears in CISA KEV at time of analysis.
Path traversal in Grav CMS before 1.10.55 allows an authenticated admin user with the admin.pages.create permission to write arbitrary Markdown files outside the intended pages directory by embedding traversal sequences in the lang POST parameter of the admin plugin's Save As action. The vulnerability gives an attacker-controlled write primitive constrained to .md file extensions, which - depending on Grav's template and plugin layout - may be chained to persistent backdoor placement or secondary code execution. No public exploit has been identified at time of analysis, and exploitation is bounded by requiring a valid authenticated admin session.
reCAPTCHA v3 bot protection in the Grav Form plugin (getgrav/grav-plugin-form) 8.0.6 through 9.1.19 can be fully bypassed by an anonymous remote attacker who submits a token under the wrong field name. Because the plugin picks which reCAPTCHA validation branch to run based only on which response field key appears in the payload, sending a v3 token in the v2 field (g-recaptcha-response) forces the v2 code path, which never checks the risk score threshold or the expected action. There is publicly available advisory detail from VulnCheck but no public exploit identified at time of analysis and no evidence of active exploitation.
Broken authorization in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.18 lets a holder of a scoped API key view - and potentially edit - a page's security/permission blueprint section beyond the scope their key was granted. The flaw lives in injectSecurityTab() of BlueprintController, which decides editability using raw isSuperAdmin()/hasPermission() checks and never calls scopeAllows(), so the per-key scope cap is silently bypassed. There is no public exploit identified at time of analysis and no KEV listing; the reporter (VulnCheck) explicitly could not confirm the end-to-end write-time impact, so confirmed effect is at least unauthorized disclosure of permission fields.
Broken authorization in getgrav/grav-plugin-api before 1.0.18 lets a scoped API key that belongs to a super-admin account perform privileged user-management actions it was never scoped for. Across seven sensitive endpoints the requireNotSuperTarget() guard in UsersController.php checks isSuperAdmin() on the underlying account instead of whether the presented key carries super authority (isSuperWithinScope()), so a deliberately down-scoped key can act against other super-admin accounts-disabling their 2FA, deleting avatars, and minting or deleting their API keys. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not on CISA KEV.
Information disclosure in Grav CMS before 2.0.16 enables authenticated users holding page-edit permission to retrieve sensitive system configuration values - including Redis passwords and other stored credentials - by invoking `config.get()` or `config.toArray()` within Twig templates. The root cause is an incomplete default denylist in the Twig sandbox configuration that fails to block access to the `config` object when the `config_access` feature is enabled. No public exploit has been identified and the vulnerability is not confirmed actively exploited at time of analysis.
Credential extraction in Grav CMS before 2.0.16 allows authenticated users with page-edit permissions to read hashed passwords and two-factor authentication secrets from User objects via insufficiently filtered Twig template sandbox methods. The allow-listed offsetGet() and offsetExists() methods on User objects expose sensitive fields that should be restricted within the sandboxed template context, enabling offline password cracking and subsequent authentication bypass. No public exploit has been identified at time of analysis, but the exploit technique is straightforward for any attacker holding page-edit rights.
Server-Side Template Injection in the Grav Email plugin (getgrav/grav-plugin-email) before 4.2.2 permits authenticated remote code execution on the host running PHP. Any account holding only api.access and api.pages.write permissions - typical content-editor roles - can embed a Twig payload in the header.form.process.email.body Email action parameter, publish the page, and trigger arbitrary OS command execution by submitting the associated form. No active exploitation has been confirmed by CISA KEV and no public exploit has been identified at time of analysis, but the low privilege bar and well-understood SSTI attack class make this a high-priority remediation target.
Origin validation bypass in Grav CMS before 2.0.16 lets remote attackers defeat the Referer-based same-origin check used by the Uri::referrer() and Pages::referrerRoute() methods. Because the check uses an unanchored str_starts_with() prefix match without a trailing delimiter, a request bearing a Referer from an attacker-controlled look-alike domain (e.g. https://example.com.attacker.tld) is accepted as same-origin, undermining CSRF/origin protections on protected routes. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV.
Password reset and account activation token comparison in Grav Login Plugin before 3.9.1 uses PHP's non-constant-time === operator instead of hash_equals(), exposing a CWE-208 timing oracle in both taskReset() (classes/Controller.php) and the activation handler (login.php). Combined with the absence of rate limiting on the token-submission endpoint, an unauthenticated network attacker can submit high-volume repeated token guesses against a known username and statistically recover a valid reset token via timing discrepancy. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the vendor itself characterizes practical exploitability as low, and no end-to-end network exploitation has been demonstrated.
Email address enumeration in the Grav Login plugin (getgrav/grav-plugin-login) before 3.9.1 lets unauthenticated remote attackers determine which email addresses are registered on a Grav CMS site. The register() method returns a distinct EMAIL_NOT_AVAILABLE error for already-registered addresses while proceeding normally otherwise, and because the registration endpoint enforces no rate limiting, an attacker can test addresses at scale, one per request. No public exploit identified at time of analysis; the assigned CVSS 4.0 score of 9.3 appears substantially inflated for what is fundamentally an information-disclosure weakness.
Configuration secret disclosure in Grav CMS before 2.0.16 allows authenticated content editors to extract sensitive values - including cache credentials - from system, site, and theme configuration arrays via the Twig templating engine. The sandboxed Twig render context fails to filter these configuration objects, permitting attackers to bypass the intended config_denied_paths restrictions using standard dot-notation syntax. No public exploit code or CISA KEV listing has been identified at time of analysis, though the CVSS 4.0 score of 7.1 reflects a high confidentiality impact for installations where editor access is not fully trusted.
Path traversal in Grav CMS before 2.0.16 exposes arbitrary server-side files to authenticated page authors through the `media_directory()` Twig function, which fails to validate attacker-supplied filesystem paths. Users holding page authoring privileges can supply arbitrary paths to `media_directory()` and then invoke the allow-listed filepath accessor on the resulting Medium object to read the contents of any file accessible to the web server process whose extension matches the CMS media allow-list. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the low privilege requirement and high confidentiality impact make this a meaningful risk in any multi-author or externally-accessible Grav deployment.
Symlink following in Grav CMS Scheduler's Job::createLockFile() enables local attackers to overwrite arbitrary files writable by the web server process, affecting all versions prior to 2.0.16. The flaw arises because lock files are written to predictable paths inside a world-writable temp directory with no verification that the target path is not an attacker-controlled symlink; the next scheduled job execution blindly writes the job ID string to whatever the symlink points at. No public exploit has been identified at time of analysis, but the predictable path and world-writable directory make the conditions straightforward to stage on shared-hosting or multi-tenant systems.
Arbitrary file deletion in Grav CMS before 2.0.16 allows authenticated users holding media management permissions to delete files anywhere on the server filesystem via path traversal sequences in filenames passed to MediaUploadTrait::deleteFile(). The root cause is that deleteFile() validates only the basename of a supplied filename while passing the full, unvalidated path - including ../ sequences - directly to PHP's unlink(). No public exploit or CISA KEV listing exists at time of analysis, but the low attack complexity makes this straightforward to weaponize for any user who holds media upload/delete rights.
Broken authorization in the Grav Login plugin before 1.0.16 lets an operator holding the api.users.write permission clear login lockout counters on admin.super accounts through the onApiUserListRowAction unlock handler, which never checks the target account's privilege tier. This strips brute-force protection from the highest-privilege accounts, enabling a lower-privileged user to set up password-guessing against super-admin credentials. Reported by VulnCheck with no public exploit identified at time of analysis and no CISA KEV listing.
Host header injection in Grav CMS before 3.9.2 allows attackers to poison outgoing invitation emails, replacing the legitimate site URL with an attacker-controlled domain in token-bearing links sent via the sendInvitationEmail() function. The vulnerability exploits a gap in Grav's existing Host header defenses: the require_trusted_host protection was applied only to password reset flows, leaving invitation emails without equivalent validation. When a poisoned invitation email is delivered and the recipient clicks the link, the one-time invitation token is transmitted to the attacker's server rather than the legitimate site. No public exploit has been identified at time of analysis, and the CVE is not listed in the CISA KEV catalog, though the reported CVSS 4.0 score of 8.7 reflects high confidentiality risk from token capture.
Authorization bypass in the Grav Flex Objects plugin (versions 1.4.0-1.4.7) allows any user holding page-edit access to render arbitrary registered Flex collections - including the full user account directory - by embedding a shortcode in published pages. The shortcode rendering path entirely omits the `authorize` ACL checks enforced in the admin panel, meaning lower-privileged editors can extract sensitive data that would otherwise be restricted to administrators. No public exploit or CISA KEV listing exists at time of analysis, but the low privilege bar and network accessibility make this a credible insider or compromised-account threat on multi-author Grav installations.
Remote code execution in Grav CMS prior to 2.0.7 allows low-privileged page editors to execute arbitrary OS commands as the web server user via a callable-injection flaw in Blueprint::dynamicData(). An account holding admin.pages or api.pages.write permission can embed a malicious data-options@ blueprint directive in page frontmatter that chains through Utils::arrayFilterRecursive() as a trampoline into PHP's system() function, executing the command when the page is rendered. No CISA KEV listing or public exploit code is identified at time of analysis; the full attack technique is documented in GitHub Security Advisory GHSA-fj2p-qj2f-74v5.
Stored XSS in Grav Shortcode Core Plugin (prior to 6.2.2) allows an authenticated user with admin.pages permission to inject arbitrary JavaScript into page content by supplying a crafted shortcode attribute value that breaks out of an HTML attribute context. The plugin's shortcode syntax bypasses Grav's save-time XSS filter because shortcode notation never contains a literal less-than character, and multiple attribute handlers (ColorShortcode, DivShortcode, ColumnsShortcode, and others) then concatenate the raw parameter directly into rendered HTML. The stored payload executes in the browser of any visitor or administrator who subsequently views the affected page. No public exploit or CISA KEV listing is identified at time of analysis.
JWT bearer token leakage in the Grav API Plugin for Grav CMS (prior to 1.0.0-rc.16) exposes valid access tokens to any party with access to server logs, proxy logs, CDN logs, browser history, or Referer headers. The JwtAuthenticator::extractBearerToken() method accepted tokens supplied via the ?token= URL query parameter on every /api/v1 route - including state-changing endpoints - rather than restricting token-in-URL to the file-download routes where it is technically necessary. An attacker who obtains a token from those secondary log sources can replay it with the full API privileges of the original token owner. No active exploitation (CISA KEV) or public exploit code has been identified at time of analysis.
Permissive CORS misconfiguration in the Grav API Plugin (all versions prior to 1.0.0-rc.16) allows cross-origin JavaScript on any attacker-controlled website to submit a stolen JWT via Authorization or X-API-Token headers and read full authenticated API responses, enabling data exfiltration and account modification with the token owner's privileges. The wildcard Access-Control-Allow-Origin: * header was returned by default for all /api/v1 endpoints - including authenticated ones - bypassing browser Same-Origin Policy protections entirely. A secondary vector existed via URL query-string token acceptance (?token=) on general API routes, leaking JWTs into server logs and Referer headers where they could be harvested and then weaponized via the CORS bypass. No public exploit code has been identified at time of analysis, and no CISA KEV listing is present.
Case-sensitivity bypass in Grav's Apache .htaccess rules prior to version 2.0.4 allows unauthenticated remote attackers to retrieve password hashes and security configuration files by requesting uppercase or mixed-case path variants (e.g., `/USER/accounts/admin.yaml`) on case-insensitive filesystems. The protection boundary - Apache mod_rewrite RewriteRule directives blocking access to user/accounts, user/config, user/data, and user/env - fails entirely when the underlying filesystem resolves uppercase URLs to the same protected files that lowercase rules would block. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack requires no authentication and no user interaction, making it trivially repeatable against eligible deployments.
Scope enforcement is entirely absent in the Grav API Plugin prior to 1.0.6, meaning any scoped API key silently exercises its issuing account's full permissions rather than the declared restricted subset. Holders of keys deliberately issued narrow read-only scopes - including third-party integrations and external services - can perform all write, delete, and administrative operations that the key's owning account is authorized for. No public exploit has been identified at time of analysis, but the vulnerability is exploitable by any valid API key holder over the network without user interaction, making supply-chain and insider-threat scenarios the primary risk vectors.
Two-factor authentication bypass in Grav Login Plugin prior to 3.8.11 allows an attacker who possesses a victim's password to completely circumvent TOTP enforcement. By invoking the taskRegenerate2FASecret() endpoint during the pending login window - when the session exists but is not yet authorized - the attacker overwrites the victim's 2FA secret, reads the replacement from the server response, computes a valid code, and completes authentication without the victim's physical device. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack primitive is explicitly confirmed by vendor advisory GHSA-7mgc-c7pq-3rr3 and the commit diff.
Privilege escalation in Grav API Plugin (all versions before 1.0.6) allows any authenticated user holding the api.users.write permission to mint API keys bound to super-administrator accounts, bypass key scope enforcement, and gain full persistent super-admin access - including the ability to rotate or disable two-factor authentication on targeted accounts. Three endpoints in UsersController - createApiKey(), generate2fa(), and disable2fa() - omitted the accessGrantsSuper() target authorization check that all sibling user mutation endpoints correctly enforced, creating an unguarded escalation path. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis, though the fix commit is publicly visible and the attack path is structurally a single authenticated API call.
Server-Side Request Forgery in the Grav API plugin (grav-plugin-api) for Grav CMS before 1.0.6 lets a caller holding the api.webhooks.write permission register webhook URLs that the server dereferences with no protocol allow-listing. Because WebhookController.php validates the URL only with FILTER_VALIDATE_URL and WebhookDispatcher.php builds cURL without CURLOPT_PROTOCOLS/CURLOPT_REDIR_PROTOCOLS, an attacker can force the server to fetch file://, gopher://, dict://, and private/link-local targets, exfiltrating local files and internal HTTP responses including cloud metadata credentials. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the root cause and fix are confirmed in the vendor advisory and commit.
Vertical privilege escalation in Grav CMS before 2.0.14 lets a delegated administrator holding only the admin.users permission promote an account to super-admin by saving a group with access[admin][super]=true. The core group blueprint omits the required security@: admin.super guard on the access field, so the operator inherits full super-admin capabilities including the task scheduler and arbitrary Twig template evaluation - effectively code execution on the host. No public exploit identified at time of analysis and the issue is not in CISA KEV, but the fix is confirmed in the vendor GHSA advisory.
Missing authorization enforcement in the Grav API plugin before 1.0.14 allows any authenticated user holding the api.access permission to invoke privileged menubar actions - bypassing per-action authorize field evaluation in MenubarController::executeAction(). The POST /api/v1/menubar/actions/{plugin}/{action} endpoint checks only the baseline api.access gate while the parallel GET listing endpoint correctly calls userPassesAuthorize(), creating an asymmetric enforcement gap (CWE-862). On stock Grav installs the impact is currently latent because no bundled core plugin registers a privileged authorize handler, but any environment deploying third-party plugins that rely on the documented authorize contract is exposed to privilege escalation. No public exploit has been identified at time of analysis and no CISA KEV listing exists.
Broken API-key scope enforcement in the Grav CMS API plugin (getgrav/grav-plugin-api) before 1.0.14 lets an authenticated holder of a restricted, scoped API key read authorize-gated administrative UI metadata that their scope should forbid. Because userPassesAuthorize() checks the underlying account's super-admin flag and ACL grants instead of the presenting key's declared scopes, a low-privilege key minted on a privileged account inherits the account's full authorization, exposing sidebar/menubar/widget item definitions and users-list columns, row-actions, and filter-tabs. No public exploit identified at time of analysis; impact is information disclosure only, and the published CVSS 4.0 9.3 appears materially overstated versus the described effect.
Open redirect in the Grav API plugin (grav-plugin-api) before 1.0.14, bundled with Grav 2.0's admin-next/API stack, allows post-login phishing via a backslash normalization bypass in SsoController::sanitizeReturnTo(). An attacker who can send a crafted OAuth login URL to an authenticated admin victim can supply a returnTo value such as '/\evil.com' that passes the guard rejecting '//' prefixes but is silently normalized by the browser into the protocol-relative URL '//evil.com', redirecting the victim to an attacker-controlled site immediately after a legitimate login. No public exploit has been identified at time of analysis, though the backslash-normalization technique is a well-documented browser behavior; the vendor advisory references a fix in version 1.0.14.
Authorization bypass in the Grav API plugin (getgrav/grav-plugin-api, bundled with Grav 2.0) before 1.0.15 lets a holder of a narrowly-scoped API key act outside its granted scope. Because BlueprintPathResolver::resolveUserScope() checks the underlying account's raw super-admin ACL flag (access.api.super) rather than the scope actually minted into the presented key, an attacker with a key limited to api.media.write on a super-admin account can write files into other users' account directories and enumerate their file listings without holding api.users.write. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Path traversal in Grav Plugin API versions 1.0.0-beta.10 through 1.0.14 enables an authenticated editor-level user to write attacker-controlled page content and media to arbitrary filesystem locations accessible to the web server process. The root cause is an incomplete fix for a prior related path traversal (GHSA-qjq4-jp55-4mx2) that left the 'suffix' parameter of the PagesController::batchCopy() method unvalidated against directory escape sequences. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch version 1.0.15 resolves the issue.
Server-side template injection in grav-plugin-api before 1.0.15 enables remote code execution for any attacker holding api.pages.write permission. The translate() endpoint accepts unsanitized Twig template syntax in header and content parameters, which can be persisted to a page with process.twig enabled and evaluated by the Twig engine at render time. No public exploit or CISA KEV listing has been identified at time of analysis, but the combination of network-reachable exploitation path and high confidentiality and integrity impact from full server-side template evaluation makes this a serious risk for any Grav installation exposing the plugin API to lower-trust users.
Stored cross-site scripting in Grav CMS before 2.0.15 lets authenticated editors smuggle JavaScript event handlers past the detectXss() sanitizer, which fails to flag event handlers (e.g. onerror=) placed in unquoted HTML attribute values containing unpaired quotes. The malicious payload is persisted in page content and executes in the browser of any visitor who later renders that page. Reported by VulnCheck with a CVSS 4.0 base score of 9.3; no public exploit identified at time of analysis and not listed in CISA KEV.
Remote code execution in Grav CMS before 2.0.15 allows attackers holding page-edit or blueprint-config privileges to write arbitrary PHP into web-accessible files and execute it. The flaw lives in the Blueprint dynamic-data 'bare-function' validation, which relies on an incomplete denylist rather than a positive allowlist, letting the error_log function be invoked through a data directive to append attacker-controlled PHP payloads. Reported by VulnCheck; no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Path traversal in Grav CMS before 2.0.15 allows unauthenticated remote attackers to read arbitrary files from sibling directories outside the intended asset root by exploiting a string prefix collision in the static asset handler. The index.php front controller validates asset paths using a simple string prefix check rather than normalized directory-boundary logic, so a request for /assets-private/credentials.yaml passes validation when /assets is the configured base. No public exploit code has been identified and this vulnerability is not in the CISA KEV catalog; the CVSS 4.0 score of 8.2 reflects high confidentiality risk conditioned on a specific deployment layout (AT:P) rather than universal exploitability.
Privilege escalation in getgrav/grav-plugin-api versions 1.0.6 through 1.0.11 allows any holder of a scoped, read-only API key to perform super-admin write operations - including rewriting group ACL maps to elevate arbitrary accounts to super-admin. The flaw exists because four privileged write endpoints (GroupsController, AccountsConfigController, PreferencesController, DashboardWidgetController) authorize via an isSuperAdmin() early-return that entirely skips requirePermission(), the only function that enforces scope caps on API keys. A leaked CI or monitoring key with a minimal scope such as api.pages.read is sufficient to achieve full administrative compromise. No public exploit code has been identified at time of analysis, and a patch is available in version 1.0.13.
Privilege escalation in Grav's Flex Objects plugin (through version 1.4.6, confirmed against Grav 2.0.11) allows an authenticated low-privileged admin to achieve full site takeover by exploiting a missing authorization check in FlexApiController::update(). The generic /api/v1/flex-objects/user-accounts and /api/v1/flex-objects/user-groups API endpoints omit the field-level, target, and super-admin guards enforced by the dedicated Users and Groups controllers, so an account holding only api.access, admin.login, and users.update can overwrite a super administrator's password or self-grant admin.super group membership. No public exploit is identified at time of analysis; vendor-released patch Flex Objects 1.4.7 is available.
Remote code execution in Grav API plugin versions before 1.0.13 is achievable by any attacker holding a scoped api.config.write API key. The ConfigController fails to enforce its super-scope gates, permitting scoped keys to overwrite scheduler.custom_jobs configuration that Grav subsequently executes via the Symfony Process component. A public exploit exists per SSVC data, the attack is rated automatable, and technical impact is assessed as total - making this a high-priority patching target despite a low EPSS score.
Privilege escalation in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.13 allows an authenticated API key holder with api.users.write scope to silently bypass the scope-cap enforcement and self-elevate to super-administrator. The flaw lies in UsersController's create() and update() methods, which validate scope caps only for api.users.write actions but fall back to a bare isSuperAdmin() check - reading access.api.super from the parent account rather than the key's own scope - when granting super privileges, allowing a limited key on a super account to mint or promote unrestricted admin accounts. A proof-of-concept exists per SSVC assessment, CISA rates exploitation as automatable with total technical impact, and a vendor-released patch is available at version 1.0.13.
Privilege escalation in Grav Plugin API before 1.0.13 allows an attacker controlling a minimal api.users.write API key - issued under a super admin account - to craft invitation records that embed super-admin access flags, which are written verbatim to any account that accepts the invitation. The root cause is CWE-269 improper privilege management: InvitationsController's strip-super and accept-groups decisions evaluate isSuperAdmin() against the owning account rather than against the API key's declared scope, so a deliberately restricted key silently retains the owner's super-admin authority for these checks. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Server-side template injection in Grav CMS before 2.0.13 allows low-privileged page editors to execute arbitrary operating-system commands via the Twig templating engine. Attackers exploit the unsandboxed `find` filter in email-action form parameters - injecting Twig payloads into subject, body, to, or from fields - which are evaluated server-side upon form submission, yielding full RCE. No public exploit code or CISA KEV listing has been identified at time of analysis, though the CVSS 4.0 score of 8.7 (VC:H/VI:H/VA:H) reflects full-compromise potential on the vulnerable system for any actor holding a page editor account.
Privilege escalation in the getgrav/grav-plugin-api plugin before 1.0.13 allows an authenticated attacker holding only a minimal api.access-scoped key on a super account to mint a full-access, unscoped super key by exploiting missing scope-subset enforcement in createApiKey. The self-target path of requireApiKeyPermission() enforces only the baseline api.access scope, while the new key's scopes are taken verbatim from the attacker-controlled request body with no validation that they fall within the caller's granted scopes. Submitting an empty scopes array produces a key with unrestricted super privileges, directly enabling further attack chains including configuration-write-to-RCE. No public exploit code or CISA KEV listing is confirmed at time of analysis; EPSS is 0.30% (23rd percentile). Vendor-released patch version 1.0.13 is available.
Scope-cap bypass in grav-plugin-api before 1.0.13 allows a holder of a least-privilege api.config.write API key issued on a super-admin account to append arbitrary tokens to Grav's Twig sandbox allowlist (persisted to user/config/security.yaml) via the POST /reports/twig-content/allowlist endpoint. Widening the allowlist eliminates the Twig sandbox boundary, converting any subsequent content render into a server-side template injection (SSTI) sink and ultimately enabling remote code execution on the host. No public exploit has been confirmed and the CVE does not appear in CISA KEV at time of analysis, but the two-step primitive - allowlist poisoning followed by SSTI/RCE - is a well-understood attack class in CMS security research.
Server-side template injection (SSTI) leading to remote code execution in the Grav CMS API plugin (getgrav/grav-plugin-api) before version 1.0.13 is reachable by any low-privilege API key holder whose key was minted on a super-admin account. The root flaw is in PagesController::guardTwigContent(), which gates Twig processing via a bare isSuperAdmin() call that ignores the api_key_scopes array, allowing a key deliberately scoped to api.pages.write to enable process.twig on page save despite admin.pages_twig being intentionally excluded from that scope. A public proof-of-concept exists per SSVC data; exploitation is classified as automatable with total technical impact, making this a high-priority patch target for any Grav deployment where the required non-default configuration is active.
Force-disabling of two-factor authentication on Grav CMS user accounts is achievable through a missing scope enforcement check in the grav-plugin-api Composer package before version 1.0.13. Any holder of a low-privilege API key carrying api.users.write permission - or any scoped key on a super account - can POST to /api/v1/users/{user}/2fa/disable without supplying a TOTP code, stripping 2FA from any non-super target account and enabling direct account takeover. No active exploitation is currently confirmed (SSVC Exploitation: none; EPSS 0.34%), but SSVC rates this automatable with total technical impact, making prompt patching critical for any instance exposing the API with delegated keys.
Remote code execution in Grav CMS before 2.0.13 allows authenticated low-privilege users to plant and execute arbitrary PHP files on the server by exploiting a validation bypass in the Flex Objects plugin. The attacker crafts a ZIP archive containing PHP code, circumvents routine-name validation by substituting array notation for the expected string notation, and triggers the unZip routine to write the payload directly into the web root where it becomes immediately executable via HTTP. No public exploit has been identified at time of analysis, but the precise bypass technique disclosed in the advisory substantially lowers the barrier to exploitation for any attacker holding valid credentials.
Path traversal in Grav CMS versions before 2.0.11 enables authenticated editors to disclose arbitrary server-side files to unauthenticated visitors through the image watermark feature. The function ImageMedium::watermark() forwards unsanitized editor-controlled input to the resource locator, whose file:// scheme handler normalizes paths using only lexical '..' collapsing - never verifying containment within the media sandbox - so a crafted Markdown image directive causes the CMS to composite a traversed file into a cached image served at a public, unauthenticated URL. No public exploit has been identified at time of analysis; however, the high confidentiality impact and ease of exploitation once editor access is obtained make this a priority patch for multi-tenant Grav deployments with untrusted editors.
Arbitrary public static PHP method invocation in Grav CMS 2.0.7-2.0.10 allows any account holding page-editing rights (admin.pages) to read arbitrary server-readable files and create or copy files and directories under the web-server account. The flaw lies in Blueprint::isSafeDynamicCall(), which skips its dangerous-callable denylist entirely for strings containing '::' - meaning fully-qualified Class::method notation in blueprint dynamic-field directives is never checked against the blocklist. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code is identified at time of analysis, but the low-privilege requirement and high-impact outcome make this a credible internal threat in multi-tenant or shared Grav deployments.
Open redirect in Grav's form plugin (getgrav/grav-plugin-form) versions 9.1.11 through 9.1.12 allows unauthenticated form submitters to cause the server to issue a 302 redirect to an arbitrary external URL, enabling phishing attacks against site visitors. The vulnerability exists because the redirect process action, introduced in v9.1.11, evaluates user-supplied form field values through Twig expressions without sanitizing the resulting URL, and Grav::redirect() passes that output to the browser without origin validation. No public exploit code has been identified at time of analysis, and no active exploitation is confirmed in CISA KEV, though the low attack complexity and zero-authentication requirement make this straightforward to abuse against any site with a susceptible form blueprint.
Privilege escalation in the Grav CMS Login plugin (grav-plugin-login) <= 3.8.11 lets a low-privilege authenticated user promote their own account to super-admin by injecting privilege fields into a profile self-update request. The flaw lives in processUserProfile() (the update_user task), which — unlike the registration handler — fails to strip 'groups' and 'access' from user-submitted form data before persisting it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but exploitation is trivial once the exposing configuration is present, and gaining super-admin unlocks admin panel access, scheduler-driven RCE, and Twig evaluation.
Remote code execution in Grav CMS 2.0.4 (fixed in 2.0.7) lets an authenticated user holding the admin.pages or api.pages.write permission plant a malicious Class::method callable directive in page frontmatter, which Blueprint::dynamicData() feeds unfiltered into call_user_func_array(). The injected command then executes as the web-server user for any subsequent visitor to the page, including unauthenticated ones. Reported by VulnCheck (CWE-94, CVSS 4.0 base 9.3); no public exploit identified at time of analysis and it is not listed in CISA KEV.
Broken authorization in the Grav api plugin (grav-plugin-api) before 1.0.8 lets any authenticated panel user holding the baseline admin.login permission forge persistent API keys bound to arbitrary accounts, resulting in impersonation and privilege escalation up to account takeover. The plugin intercepts the apiKeyGenerate/apiKeyRevoke admin tasks ahead of the account-management ACL, so a low-privilege operator can mint a key that inherits a higher-privileged account's API permissions. Reported by VulnCheck with a fix in 1.0.8; no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
Cross-origin data exposure in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 stems from a hardcoded 'Access-Control-Allow-Origin: *' header returned on every response, including authenticated endpoints and preflight (OPTIONS) responses. Because the plugin authenticates via the Authorization and X-API-Token request headers rather than cookies, any malicious website scripting a leaked access token can read the response bodies of authenticated endpoints and perform write actions as that token's user. Reported by VulnCheck with no public exploit identified at time of analysis; not listed in CISA KEV.
Sensitive token exposure in the Grav CMS API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 allows attackers to hijack valid admin sessions after JWT access tokens leak from URLs. Because JwtAuthenticator::extractBearerToken accepts tokens via the ?token= query string on every API route, those tokens are written verbatim into web server access logs, Referer headers, browser history, and upstream proxy/CDN logs, and any captured token grants full admin API access. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the CVSS 4.0 score of 8.2 reflects the high value of the leaked admin credentials.
Server-side request forgery in Grav CMS before 2.0.4 allows authenticated users holding the api.webhooks.write permission to register webhooks with dangerous cURL protocol handlers (file://, dict://, gopher://) that fire when webhook events trigger. By abusing these unrestricted protocols an attacker can read local files, enumerate process and service information, and pivot to internal-only network services from the trust position of the Grav server. No public exploit has been identified at time of analysis and it is not listed in CISA KEV; risk is driven by the CWE-918 primitive rather than confirmed in-the-wild activity.
Privilege escalation in the getgrav grav-plugin-api before 1.0.6 allows a low-privileged manager holding the api.users.write permission to become a super-admin. The createApiKey, generate2fa, and disable2fa endpoints never re-check super-admin status, so an attacker can mint API keys bound to super-admin accounts or strip 2FA from super-admin users and take over the entire Grav instance. No public exploit identified at time of analysis, but the vendor GHSA advisory and VulnCheck confirm the flaw.
Two-factor authentication bypass in Grav CMS before 2.0.4 lets an attacker who already knows a victim's password overwrite that user's TOTP secret and log in with full 2FA protection stripped away. During the pending TOTP challenge window the login plugin's regenerate2FASecret task verifies only that the user exists — not that the caller is authorized — and requires no CSRF nonce, so the attacker sets an attacker-chosen secret, computes a valid code, and completes login. VulnCheck-reported and CVSS 4.0 scored 9.1; no public exploit identified at time of analysis.
Authorization bypass in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.6 lets any valid API key perform actions far beyond its intended scope. Although keys can be provisioned with a restricted scopes array (e.g. read-only), the ApiKeyAuthenticator class never reads or enforces those scopes and instead returns the owning user's full account object, so a limited key can execute any write, delete, or administrative operation the owner is entitled to. Reported by VulnCheck with no public exploit identified at time of analysis, but the flaw is trivially exploitable by any key holder against default configurations.
Sensitive configuration file disclosure in Grav CMS before 2.0.4 lets unauthenticated remote attackers bypass the bundled .htaccess protections by requesting blocked file types with uppercase or mixed-case extensions (e.g., .YAML, .PHP). The shipped rules omit the Apache [NC] flag, so extension matching is case-sensitive and fails to block case variants on case-insensitive filesystems (Windows/NTFS, macOS/HFS+, Docker volume mounts), exposing files that may hold API keys and credentials. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Authenticated arbitrary file write in the Grav CMS Form plugin (versions before 9.1.8) allows attackers to plant PHP webshells in the web root by abusing the process.save.filename parameter. The filename is checked for path traversal before Twig rendering but never re-validated afterward, so traversal sequences reconstructed during template evaluation bypass the guard. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV; the flaw was disclosed by VulnCheck via a coordinated GitHub security advisory.
An allowlist bypass in Grav CMS 2.0.15 through 2.2.12 lets an authenticated account holding page-edit permission (api.pages.write, or admin.pages in the classic admin) invoke arbitrary public static PHP methods by smuggling a data-*@ directive past Grav's Class::method allowed-callable check inside a page-authored Flex form override; methods such as Folder::delete, Folder::move, Folder::copy or Utils::download can then delete directories, move or overwrite files, and read files outside the page tree. The crafted directive fires when the page's Flex form is built, for example when an administrator opens the page on the site, so the payload is planted by the lower-privileged editor and executed in an administrator's request. The vendor shipped a complete fix in 2.2.13; the earlier 2.2.2 patch (GHSA-9rq7-4cch-f22j) only closed the replace-name@ spelling and leaves installations exploitable, and no public exploit code was identified at time of analysis.
Authenticated page editors in Grav CMS 2.0.0 through 2.2.4 can abuse flex-*@ frontmatter directives to invoke Flex object methods in another editor's session when that editor opens a crafted page, allowing unauthorized deletion of protected pages. The flaw is an access-control/confused-deputy issue in FlexDirectory::dynamicFlexField() and carries a High CVSS 4.0 score of 7.0, though exploitation requires an existing page-edit account plus a second editor opening the page. No public exploit code or confirmed active exploitation was identified at time of analysis.
Authorization bypass in the Grav Flex Objects plugin 1.4.0 through 1.4.16 lets authenticated, non-super users holding api.access plus either admin.pages or admin.configuration.pages read page source and frontmatter, modify content, and delete pages they are explicitly denied, because the generic /api/v1/flex-objects/pages routes enforce only directory-level admin.pages checks instead of the Pages API's api.pages.read/write and page-level permission rules. Scored 7.1 with an independent assessment of high confidentiality and high integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), the flaw is a privilege-escalation problem past intended per-page restrictions rather than an anonymous compromise path - the attacker must already hold a valid restricted admin or editor account, and super-user accounts are unaffected. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so this is a moderate-priority remediation item rather than a drop-everything emergency.
Privilege escalation in the Grav Login plugin (3.6.0 before 3.9.13) allows page authors to obtain super-user accounts by defining an invitation form in page frontmatter and submitting the login.invite task without authentication. The missing authorization check requires an existing authenticated page-author foothold (PR:L) to plant the invitation form, so it is not exploitable by a fully anonymous outsider; no public exploit code or CISA KEV entry was identified at time of analysis. This is a credible, actionable privilege-escalation issue rather than a drop-everything remote-root flaw.
Denial of service in Grav CMS 1.7.53 before 1.7.53.5 and 2.0.0-rc.8 before 2.2.2 lets unauthenticated remote attackers exhaust server memory by bypassing the system.images.max_pixels safeguard when system.images.url_actions is enabled. Attackers use single-dimension or percentage forceResize, zoomCrop, or chained image actions to force PHP's GD library to allocate multi-gigabyte canvases and take the site down. No public exploit identified at time of analysis; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms this is an availability-only threat requiring the url_actions setting to be enabled.
Information disclosure in Grav CMS 2.0.0 through 2.2.1 allows authenticated page editors to expose protected configuration - including security.salt, plugin credentials, and Redis passwords - to every visitor of the affected page by inserting config-*@ directives into a page's frontmatter form. The bypass defeats the Twig sandbox's config_denied_paths redaction, so values the CMS intends to keep internal are rendered into public page output. Our assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N rather than the advisory's 8.7 CVSS:4.0 vector, because exploitation requires an account already holding page-edit rights; no public exploit code or confirmed active exploitation was identified at time of analysis, and real-world impact depends on whether the deployment actually stores secrets in flat-file configuration.
Grav CMS 2.0.15 through 2.1.x (before 2.2.2) allows authenticated users with page-edit permission to bypass the Flex form callable allowlist and invoke arbitrary public static methods such as Folder::delete, Folder::move, and Utils::download. By renaming a Flex form field using the replace-name@ syntax, an editor can smuggle data-*@ directives past validation, enabling directory deletion, file overwrite, and arbitrary file reads. No public exploit code has been identified at time of analysis, and exploitation requires an authenticated editor account rather than anonymous access.
Unauthenticated resource exhaustion in the Grav API plugin (grav-plugin-api) before 1.0.42 allows any remote attacker who can reach GET /api/v1/translations/{lang} to make the plugin cache a full ~560 KB translation dictionary for each well-formed language code, potentially filling disk or APCu; separately, authenticated accounts with api.pages.write can bypass target/destination page rules in the sync and batch copy endpoints to overwrite translations or create pages that page-level rules deny. The plugin is an optional add-on rather than part of a default Grav install, which limits exposure, and no public exploit has been identified at time of analysis.
Information disclosure in Grav CMS before 2.1.7 lets unauthenticated remote attackers retrieve Git metadata from nested repositories - for example /user/.git/ - exposing git config, refs, and object files that can be used to reconstruct unpublished history or recover committed secrets. The flaw exists because the web-server configurations bundled with Grav for nginx, lighttpd, IIS, and Caddy 2 block dot-prefixed paths such as .git only at the document root, so repositories created below the root (a version-controlled user/ directory, or git-installed plugins and themes) remain web-readable. No authentication or user interaction is required; no public exploit code or confirmed active exploitation was identified at time of analysis, and real-world impact is gated by the deployment precondition that a web-reachable nested Git repository actually exists and contains private history or sensitive commits. The vendor advisory (GHSA-5vx9-x8f2-f55w) points to the 2.1.7 release as the fix.
Unauthenticated information disclosure in Grav CMS 2.0.22 through 2.1.6 lets attackers read sensitive Clockwork profiler records - including system and plugin configuration, secrets, request metadata, and database queries - when the profiler is active and the site sits behind a same-host HTTP proxy. The flaw is an authentication bypass: the profiler treats any request whose REMOTE_ADDR is a loopback address (e.g. 127.0.0.1) as an authorized local client, so requests forwarded through a co-located proxy inherit that trust. Exploitation is conditional rather than trivial - the profiler is a debug feature and must be enabled, and the attacker must be able to reach the application through the loopback-presenting proxy path; no public exploit code was identified at time of analysis, and this is not a CISA KEV entry. The impact is confidentiality-only (no integrity or availability effect) and is best characterized as a genuine but conditional disclosure flaw rather than a blanket high-severity emergency.
Memory exhaustion denial of service affects Grav CMS versions before 2.1.7, where an authenticated user with media-author upload privileges can submit a highly compressed oversized raster image that, when referenced through a Twig or Markdown image transform, is fully decoded by GD or Imagick without source-dimension validation. Once the transformed image is embedded in published content, unauthenticated page requests repeatedly trigger the decode-and-allocate behavior, causing sustained page unavailability; the assessed CVSS 4.0 base score is 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VA:H), and no public exploit code was identified at time of analysis.
Authentication bypass in the Grav Login OAuth plugin before 1.4.3 lets unauthenticated remote attackers derive valid credentials for OAuth-provisioned accounts and take administrative control. The plugin assigns each auto-provisioned user a deterministic '<provider>.<id>' username and an unsalted MD5 hash of the provider identifier as the password, and it leaves password login enabled; anyone who learns or guesses the provider identifier can reproduce the login. No public exploit identified at time of analysis; the vendor-assigned CVSS 4.0 score is 9.3 Critical and the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
Privilege escalation in the Grav API plugin (grav-plugin-api) before 1.0.36 allows an account that already holds the api.users.write capability - a delegated user manager rather than a super-admin - to obtain full super-admin API access. The attacker edits account access maps or pending invitations so that a positive scalar value is stored on an 'admin' or 'api' parent grant; the plugin's inheriting permission resolver then treats that grant as satisfying its requireSuper checks, exposing super-only API endpoints. Exploitation is authenticated and requires the high-privilege api.users.write capability (CVSS vectors show PR:H, scope unchanged), so the flaw matters mainly where user-management rights have been delegated below super-admin; no public exploit code or confirmed active exploitation was identified at time of analysis.
Page editors on Grav CMS versions 2.0.22 through 2.1.6 can render the Clockwork debugger's system.debugger.token via editor-authored Twig and replay it as the X-Clockwork-Auth header, disclosing profiler records that contain configuration values, request metadata, and database queries. The flaw is an authenticated, page-editor-level information disclosure (CVSS 4.0 base 7.1; independent assessment CVSS 3.1 AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N) that requires the Clockwork debugger to be enabled so that a token and profiler records exist; it is not anonymously reachable. Exploitation status: no public exploit identified at time of analysis, and the issue is remediated by upgrading to 2.1.7, which adds system.debugger.token to the Twig sandbox redaction list. This is a moderate-priority information disclosure flaw, not a critical emergency, because it needs valid editor credentials and Twig authoring rights and yields read-only exposure.
Password-reset token disclosure in the Grav Login plugin (versions 1.2.0 up to but not including 3.9.9) allows any user holding a publisher-level account to hijack more privileged accounts. A publisher authors a page at the plugin's password-reset route so that Login::getPage() renders attacker-controlled content on that route; when a higher-privileged victim opens an emailed reset link, the rendered page exposes the victim's username and bearer reset token, which the attacker can redeem to take over the account. Exploitation requires an existing publisher account plus victim interaction (clicking the emailed reset link), and no public exploit code or CISA KEV entry has been identified at time of analysis.
Two-factor authentication bypass in the Grav Login plugin versions 2.7.0 through before 3.9.9 allows an authenticated remote attacker who already possesses a valid password to restore a remember-me cookie issued after the password step and obtain a fully authorized session without completing the second factor, yielding high confidentiality and integrity impact. This is a genuine elevated-priority issue for environments using the plugin with 2FA and remember-me enabled, though not a mass-exploitation emergency; no public exploit identified at time of analysis.
Authentication bypass in Grav Login plugin versions 2.7.0 before 3.9.9 allows attackers who already know a victim's password to disable two-factor authentication (2FA) and take over the account by invoking the update_user task through a published page form without an access rule. The flaw resides in processUserProfile(), which verifies that a session user exists but fails to confirm that a pending front-end 2FA session is fully authorized. Exploitation requires three conditions: the attacker must possess the victim's password, have an in-progress front-end login that has reached the 2FA step, and be able to publish a Grav page form lacking an access rule; no public exploit has been identified at time of analysis.
Stored cross-site scripting in the Grav Data Manager plugin (getgrav/grav-plugin-datamanager) versions 1.0.1 through 1.4.4 allows an unauthenticated visitor to plant an HTML/JavaScript payload through a front-end form whose submissions are written into the user/data store; that payload is later rendered unescaped in the classic admin panel's item-detail view and executes in the administrator's browser session and origin, with access to that administrator's privileges and CSRF token. Exploitation requires a specific but realistic configuration chain: the site must route front-end form submissions into user/data, and the administrator must open the malicious entry in the classic Grav admin panel - sites running the Grav 2.0 Admin Next interface are not affected because it renders the same data through a separate, correctly escaping code path. The initial injection is unauthenticated (CVSS PR:N), while the privilege-boundary crossing needs administrator interaction (UI:R); payloads in list-type values such as checkboxes or multi-selects fire on view with no further interaction, whereas ordinary text fields fire on hover. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is fixed in Data Manager 1.4.5.
Unauthenticated information disclosure in the getgrav/grav-plugin-comments plugin (through 1.2.10) lets a remote attacker retrieve every comment posted to a Grav site in the last 7 days, including each commenter's email address and the absolute server filesystem path of the underlying data file, simply by sending a GET request to /admin/comments/page:<n> (for example page:0.001). The vulnerable admin handler performs its authorization check against isAdmin(), which only signals that the admin service is registered on the current route rather than that the visitor is authenticated, and it emits the JSON response and calls exit() during the plugins stage before the classic Admin plugin can render its login screen. Exploitation requires the site to run the classic Grav Admin plugin with the Comments plugin enabled (the default configuration), and is a genuine but bounded risk: no public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the assessed impact is limited to confidentiality (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), with no write or code-execution capability - the 8.7 CVSS 4.0 score published with the CVE reflects a higher-confidence confidentiality weighting than this assessment supports. The issue is fixed in 1.2.11.
Session cookie theft in Grav CMS 2.0.19 through 2.0.24 lets an authenticated user with only page-write permission capture the session identifier of any administrator who views their published page, because the Twig sandbox exposes get_cookie() and the post-Twig page cache is keyed without any session or request dimension. The poisoned cache then serves the stolen identifier to unauthenticated visitors, who can replay the cookie to authenticate as the administrator, yielding full confidentiality, integrity and availability impact on the instance. Exploitation is confirmed against default configurations in 2.0.19-2.0.24 (security.twig_content.process_enabled defaults to true and Security::applyTwigContentDefault() enables process.twig on every page), while 2.0.0-2.0.18 and 1.7.x are only affected if content Twig was explicitly enabled. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor-released fix is Grav 2.0.25, and 1.7.x is outside the backport scope.
Privilege escalation in Grav CMS 2.0.14 through 2.0.24 allows an authenticated backend operator who already holds the admin.users permission - but not admin.super - to grant super-admin rights to their own account or to a group they belong to via the flex accounts backend. The bypass works because the security guard is resolved against a field's exact blueprint path, so a crafted flat dot-notation key such as access.admin.super evades the rule match and is later reconstructed into a genuine nested value when the object is saved. No public exploit code has been identified at time of analysis, and because the attacker must already possess privileged but non-super backend access, this is an insider or post-compromise escalation vector rather than a remote unauthenticated one - but the resulting super-admin control over configuration, plugin and theme installation, the file manager, and all accounts makes it a genuine, high-value escalation rather than a high-CVSS-but-low-real-risk issue.
Information disclosure in Grav CMS before 2.0.25 lets unauthenticated remote attackers read sensitive files - configuration secrets and account password hashes - when the site is served by Microsoft IIS using the bundled webserver-configs/web.config over a case-insensitive filesystem such as NTFS, simply by varying the case of a folder name or extension (for example GET /user/CONFIG/system.YAML) so that none of the case-sensitive URL Rewrite deny rules match. The practical blast radius is narrower than the raw path-bypass suggests: whether a bypassed file is actually returned depends on MIME registration, with .json served by default while .yaml/.yml return HTTP 404.3 on a stock IIS unless a YAML MIME mapping has been added; the equivalent gap in webserver-configs/lighttpd.conf is lower risk because lighttpd typically runs on case-sensitive filesystems, and deployments behind Apache (.htaccess), nginx, Caddy, or the PHP built-in server are not affected. No public exploit identified at time of analysis, and while the vendor-released patch is Grav 2.0.25, upgrading alone is insufficient because the .htaccess installer heal does not rewrite web.config or lighttpd.conf, so operators must manually re-copy the corrected sample files.
An authenticated user who can author raw Twig in page content on Grav CMS 2.0.0 through 2.0.24 can escape the Twig content sandbox and read the site's entire configuration tree, exposing plugin credentials, SMTP and OAuth secrets, Redis passwords, proxy URLs, and the security.* subtree that the sandbox's redaction is designed to hide. The escape works because the `array` filter and its function form are allowlisted in the sandbox without the needs_is_sandboxed guard carried by print_r, vardump, json_encode, yaml_encode and string, and its implementation calls toArray() or an (array) cast without consulting the sandbox method allowlist, so `grav|array` unwraps the raw Pimple dependency-injection container and its private $values. Because the payload is stored in page content, the disclosed configuration is rendered to unauthenticated visitors; exploitation requires the authoring privilege (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and no public exploit was identified at time of analysis. Grav 1.7 is not affected because it has no Twig content sandbox, and the issue is fixed in Grav 2.0.25.
Grav CMS 2.0.0-rc.1 through 2.0.21 discloses its entire merged configuration - including plugin-level secrets such as SMTP credentials, API tokens, webhook secrets and cache backend passwords - to an authenticated user with page-edit rights who renders a dump/serialize filter such as {{ config|print_r }} in page content that has Twig processing enabled. The Twig content sandbox guard introduced in GHSA-mc5q-6hpj-rp7j never fires because GravExtension::assertSandboxDumpSafe() calls SandboxExtension::isSandboxed() without a Source argument, which reports only the global sandbox flag that Grav never enables; this is a privilege-to-secrets escalation rather than an unauthenticated exposure, since editor-level access is a prerequisite. Vendor-released patch: 2.0.22, where the affected filters are registered with Twig's needs_is_sandboxed flag; Grav 1.7 is not affected because it ships no Twig content sandbox, and no public exploit identified at time of analysis.
Unauthenticated information disclosure in Grav CMS 1.7.0 through 1.7.53.2 and 2.0.0 through 2.0.21 allows any remote attacker who can reach the site to read stored request cookies, plaintext login credentials, and the complete system and plugin configuration - including operator-saved SMTP credentials, third-party API keys, and licence keys - whenever the optional debugger (system.debugger.enabled: true, not the shipped default) has been left enabled. Rated CVSS 4.0 base 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) and consistent with the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, exploitation is network-based, low-complexity, and requires no privileges, authentication, or user interaction, with high confidentiality impact and no integrity or availability effect. Exposure is limited to development, staging, or misconfigured production installs where the debugger was deliberately turned on; no public exploit code was identified at time of analysis.
Host header injection in the Grav API plugin's forgot-password endpoint allows unauthenticated remote attackers to redirect password-reset tokens to attacker-controlled domains, enabling full account takeover including super-admin accounts. The plugin blindly incorporates the HTTP Host header when constructing reset links dispatched to victims' inboxes; an attacker who spoofs this header and induces the target to click the resulting email link captures the token and seizes the account. All Grav API plugin deployments running versions prior to 1.0.20 are affected; no public exploit code or CISA KEV listing has been identified at time of analysis, though the attack is straightforward to execute.
Privilege escalation in grav-plugin-api before 1.0.20 allows a low-privileged API manager to self-create a super-admin account by exploiting a logic gap in the InvitationsController's stripSuperFlags() method, which strips nested super flags but ignores dot-keyed equivalents such as 'api.super'. The attacker crafts an invitation payload containing the dot-keyed flag, which persists through sanitization into the new account, then self-accepts the invitation via the public acceptance endpoint - no real invitee participation required - and immediately receives a valid JWT granting full Grav site control. No public exploit or CISA KEV listing is present at time of analysis, but the attack is fully self-contained and conceptually trivial for any account already holding api.users.write permissions.
Privilege escalation in grav-plugin-api before 1.0.20 allows authenticated API users holding api.access and api.users.write permissions to overwrite the password of super-admin accounts whose elevated status is inherited through group membership rather than direct assignment. The user-management guard fails to evaluate group-inherited super status, treating those accounts as unprotected targets. An attacker who successfully exploits this gains full Grav CMS administrative control. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 4.0 score of 8.7 reflects high impact across confidentiality and integrity.
Remote code execution in Grav CMS (versions ≤2.0.17) lets authenticated users holding only page-write rights achieve arbitrary PHP execution on the web server by exploiting a Twig sandbox bypass in the |sort filter. The sortFunc wrapper in GravExtension.php incorrectly hardcodes isSandboxed=false-unlike |map, |filter, and |reduce-allowing |sort to resolve plain PHP callable names including spl_autoload, which is absent from the function denylist and performs a PHP include operation. A content editor can deliver a crafted payload through mechanisms such as form frontmatter rendered by the Email plugin, resulting in code execution as the web server user. A vendor-released patch is available in version 2.0.19, and no active exploitation appears in CISA KEV at time of analysis.
Path traversal in Grav CMS before 1.10.55 allows an authenticated admin user with the admin.pages.create permission to write arbitrary Markdown files outside the intended pages directory by embedding traversal sequences in the lang POST parameter of the admin plugin's Save As action. The vulnerability gives an attacker-controlled write primitive constrained to .md file extensions, which - depending on Grav's template and plugin layout - may be chained to persistent backdoor placement or secondary code execution. No public exploit has been identified at time of analysis, and exploitation is bounded by requiring a valid authenticated admin session.
reCAPTCHA v3 bot protection in the Grav Form plugin (getgrav/grav-plugin-form) 8.0.6 through 9.1.19 can be fully bypassed by an anonymous remote attacker who submits a token under the wrong field name. Because the plugin picks which reCAPTCHA validation branch to run based only on which response field key appears in the payload, sending a v3 token in the v2 field (g-recaptcha-response) forces the v2 code path, which never checks the risk score threshold or the expected action. There is publicly available advisory detail from VulnCheck but no public exploit identified at time of analysis and no evidence of active exploitation.
Broken authorization in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.18 lets a holder of a scoped API key view - and potentially edit - a page's security/permission blueprint section beyond the scope their key was granted. The flaw lives in injectSecurityTab() of BlueprintController, which decides editability using raw isSuperAdmin()/hasPermission() checks and never calls scopeAllows(), so the per-key scope cap is silently bypassed. There is no public exploit identified at time of analysis and no KEV listing; the reporter (VulnCheck) explicitly could not confirm the end-to-end write-time impact, so confirmed effect is at least unauthorized disclosure of permission fields.
Broken authorization in getgrav/grav-plugin-api before 1.0.18 lets a scoped API key that belongs to a super-admin account perform privileged user-management actions it was never scoped for. Across seven sensitive endpoints the requireNotSuperTarget() guard in UsersController.php checks isSuperAdmin() on the underlying account instead of whether the presented key carries super authority (isSuperWithinScope()), so a deliberately down-scoped key can act against other super-admin accounts-disabling their 2FA, deleting avatars, and minting or deleting their API keys. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not on CISA KEV.
Information disclosure in Grav CMS before 2.0.16 enables authenticated users holding page-edit permission to retrieve sensitive system configuration values - including Redis passwords and other stored credentials - by invoking `config.get()` or `config.toArray()` within Twig templates. The root cause is an incomplete default denylist in the Twig sandbox configuration that fails to block access to the `config` object when the `config_access` feature is enabled. No public exploit has been identified and the vulnerability is not confirmed actively exploited at time of analysis.
Credential extraction in Grav CMS before 2.0.16 allows authenticated users with page-edit permissions to read hashed passwords and two-factor authentication secrets from User objects via insufficiently filtered Twig template sandbox methods. The allow-listed offsetGet() and offsetExists() methods on User objects expose sensitive fields that should be restricted within the sandboxed template context, enabling offline password cracking and subsequent authentication bypass. No public exploit has been identified at time of analysis, but the exploit technique is straightforward for any attacker holding page-edit rights.
Server-Side Template Injection in the Grav Email plugin (getgrav/grav-plugin-email) before 4.2.2 permits authenticated remote code execution on the host running PHP. Any account holding only api.access and api.pages.write permissions - typical content-editor roles - can embed a Twig payload in the header.form.process.email.body Email action parameter, publish the page, and trigger arbitrary OS command execution by submitting the associated form. No active exploitation has been confirmed by CISA KEV and no public exploit has been identified at time of analysis, but the low privilege bar and well-understood SSTI attack class make this a high-priority remediation target.
Origin validation bypass in Grav CMS before 2.0.16 lets remote attackers defeat the Referer-based same-origin check used by the Uri::referrer() and Pages::referrerRoute() methods. Because the check uses an unanchored str_starts_with() prefix match without a trailing delimiter, a request bearing a Referer from an attacker-controlled look-alike domain (e.g. https://example.com.attacker.tld) is accepted as same-origin, undermining CSRF/origin protections on protected routes. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV.
Password reset and account activation token comparison in Grav Login Plugin before 3.9.1 uses PHP's non-constant-time === operator instead of hash_equals(), exposing a CWE-208 timing oracle in both taskReset() (classes/Controller.php) and the activation handler (login.php). Combined with the absence of rate limiting on the token-submission endpoint, an unauthenticated network attacker can submit high-volume repeated token guesses against a known username and statistically recover a valid reset token via timing discrepancy. No public exploit code has been identified and the vulnerability is not listed in CISA KEV; the vendor itself characterizes practical exploitability as low, and no end-to-end network exploitation has been demonstrated.
Email address enumeration in the Grav Login plugin (getgrav/grav-plugin-login) before 3.9.1 lets unauthenticated remote attackers determine which email addresses are registered on a Grav CMS site. The register() method returns a distinct EMAIL_NOT_AVAILABLE error for already-registered addresses while proceeding normally otherwise, and because the registration endpoint enforces no rate limiting, an attacker can test addresses at scale, one per request. No public exploit identified at time of analysis; the assigned CVSS 4.0 score of 9.3 appears substantially inflated for what is fundamentally an information-disclosure weakness.
Configuration secret disclosure in Grav CMS before 2.0.16 allows authenticated content editors to extract sensitive values - including cache credentials - from system, site, and theme configuration arrays via the Twig templating engine. The sandboxed Twig render context fails to filter these configuration objects, permitting attackers to bypass the intended config_denied_paths restrictions using standard dot-notation syntax. No public exploit code or CISA KEV listing has been identified at time of analysis, though the CVSS 4.0 score of 7.1 reflects a high confidentiality impact for installations where editor access is not fully trusted.
Path traversal in Grav CMS before 2.0.16 exposes arbitrary server-side files to authenticated page authors through the `media_directory()` Twig function, which fails to validate attacker-supplied filesystem paths. Users holding page authoring privileges can supply arbitrary paths to `media_directory()` and then invoke the allow-listed filepath accessor on the resulting Medium object to read the contents of any file accessible to the web server process whose extension matches the CMS media allow-list. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the low privilege requirement and high confidentiality impact make this a meaningful risk in any multi-author or externally-accessible Grav deployment.
Symlink following in Grav CMS Scheduler's Job::createLockFile() enables local attackers to overwrite arbitrary files writable by the web server process, affecting all versions prior to 2.0.16. The flaw arises because lock files are written to predictable paths inside a world-writable temp directory with no verification that the target path is not an attacker-controlled symlink; the next scheduled job execution blindly writes the job ID string to whatever the symlink points at. No public exploit has been identified at time of analysis, but the predictable path and world-writable directory make the conditions straightforward to stage on shared-hosting or multi-tenant systems.
Arbitrary file deletion in Grav CMS before 2.0.16 allows authenticated users holding media management permissions to delete files anywhere on the server filesystem via path traversal sequences in filenames passed to MediaUploadTrait::deleteFile(). The root cause is that deleteFile() validates only the basename of a supplied filename while passing the full, unvalidated path - including ../ sequences - directly to PHP's unlink(). No public exploit or CISA KEV listing exists at time of analysis, but the low attack complexity makes this straightforward to weaponize for any user who holds media upload/delete rights.
Broken authorization in the Grav Login plugin before 1.0.16 lets an operator holding the api.users.write permission clear login lockout counters on admin.super accounts through the onApiUserListRowAction unlock handler, which never checks the target account's privilege tier. This strips brute-force protection from the highest-privilege accounts, enabling a lower-privileged user to set up password-guessing against super-admin credentials. Reported by VulnCheck with no public exploit identified at time of analysis and no CISA KEV listing.
Host header injection in Grav CMS before 3.9.2 allows attackers to poison outgoing invitation emails, replacing the legitimate site URL with an attacker-controlled domain in token-bearing links sent via the sendInvitationEmail() function. The vulnerability exploits a gap in Grav's existing Host header defenses: the require_trusted_host protection was applied only to password reset flows, leaving invitation emails without equivalent validation. When a poisoned invitation email is delivered and the recipient clicks the link, the one-time invitation token is transmitted to the attacker's server rather than the legitimate site. No public exploit has been identified at time of analysis, and the CVE is not listed in the CISA KEV catalog, though the reported CVSS 4.0 score of 8.7 reflects high confidentiality risk from token capture.
Authorization bypass in the Grav Flex Objects plugin (versions 1.4.0-1.4.7) allows any user holding page-edit access to render arbitrary registered Flex collections - including the full user account directory - by embedding a shortcode in published pages. The shortcode rendering path entirely omits the `authorize` ACL checks enforced in the admin panel, meaning lower-privileged editors can extract sensitive data that would otherwise be restricted to administrators. No public exploit or CISA KEV listing exists at time of analysis, but the low privilege bar and network accessibility make this a credible insider or compromised-account threat on multi-author Grav installations.
Remote code execution in Grav CMS prior to 2.0.7 allows low-privileged page editors to execute arbitrary OS commands as the web server user via a callable-injection flaw in Blueprint::dynamicData(). An account holding admin.pages or api.pages.write permission can embed a malicious data-options@ blueprint directive in page frontmatter that chains through Utils::arrayFilterRecursive() as a trampoline into PHP's system() function, executing the command when the page is rendered. No CISA KEV listing or public exploit code is identified at time of analysis; the full attack technique is documented in GitHub Security Advisory GHSA-fj2p-qj2f-74v5.
Stored XSS in Grav Shortcode Core Plugin (prior to 6.2.2) allows an authenticated user with admin.pages permission to inject arbitrary JavaScript into page content by supplying a crafted shortcode attribute value that breaks out of an HTML attribute context. The plugin's shortcode syntax bypasses Grav's save-time XSS filter because shortcode notation never contains a literal less-than character, and multiple attribute handlers (ColorShortcode, DivShortcode, ColumnsShortcode, and others) then concatenate the raw parameter directly into rendered HTML. The stored payload executes in the browser of any visitor or administrator who subsequently views the affected page. No public exploit or CISA KEV listing is identified at time of analysis.
JWT bearer token leakage in the Grav API Plugin for Grav CMS (prior to 1.0.0-rc.16) exposes valid access tokens to any party with access to server logs, proxy logs, CDN logs, browser history, or Referer headers. The JwtAuthenticator::extractBearerToken() method accepted tokens supplied via the ?token= URL query parameter on every /api/v1 route - including state-changing endpoints - rather than restricting token-in-URL to the file-download routes where it is technically necessary. An attacker who obtains a token from those secondary log sources can replay it with the full API privileges of the original token owner. No active exploitation (CISA KEV) or public exploit code has been identified at time of analysis.
Permissive CORS misconfiguration in the Grav API Plugin (all versions prior to 1.0.0-rc.16) allows cross-origin JavaScript on any attacker-controlled website to submit a stolen JWT via Authorization or X-API-Token headers and read full authenticated API responses, enabling data exfiltration and account modification with the token owner's privileges. The wildcard Access-Control-Allow-Origin: * header was returned by default for all /api/v1 endpoints - including authenticated ones - bypassing browser Same-Origin Policy protections entirely. A secondary vector existed via URL query-string token acceptance (?token=) on general API routes, leaking JWTs into server logs and Referer headers where they could be harvested and then weaponized via the CORS bypass. No public exploit code has been identified at time of analysis, and no CISA KEV listing is present.
Case-sensitivity bypass in Grav's Apache .htaccess rules prior to version 2.0.4 allows unauthenticated remote attackers to retrieve password hashes and security configuration files by requesting uppercase or mixed-case path variants (e.g., `/USER/accounts/admin.yaml`) on case-insensitive filesystems. The protection boundary - Apache mod_rewrite RewriteRule directives blocking access to user/accounts, user/config, user/data, and user/env - fails entirely when the underlying filesystem resolves uppercase URLs to the same protected files that lowercase rules would block. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack requires no authentication and no user interaction, making it trivially repeatable against eligible deployments.
Scope enforcement is entirely absent in the Grav API Plugin prior to 1.0.6, meaning any scoped API key silently exercises its issuing account's full permissions rather than the declared restricted subset. Holders of keys deliberately issued narrow read-only scopes - including third-party integrations and external services - can perform all write, delete, and administrative operations that the key's owning account is authorized for. No public exploit has been identified at time of analysis, but the vulnerability is exploitable by any valid API key holder over the network without user interaction, making supply-chain and insider-threat scenarios the primary risk vectors.
Two-factor authentication bypass in Grav Login Plugin prior to 3.8.11 allows an attacker who possesses a victim's password to completely circumvent TOTP enforcement. By invoking the taskRegenerate2FASecret() endpoint during the pending login window - when the session exists but is not yet authorized - the attacker overwrites the victim's 2FA secret, reads the replacement from the server response, computes a valid code, and completes authentication without the victim's physical device. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack primitive is explicitly confirmed by vendor advisory GHSA-7mgc-c7pq-3rr3 and the commit diff.
Privilege escalation in Grav API Plugin (all versions before 1.0.6) allows any authenticated user holding the api.users.write permission to mint API keys bound to super-administrator accounts, bypass key scope enforcement, and gain full persistent super-admin access - including the ability to rotate or disable two-factor authentication on targeted accounts. Three endpoints in UsersController - createApiKey(), generate2fa(), and disable2fa() - omitted the accessGrantsSuper() target authorization check that all sibling user mutation endpoints correctly enforced, creating an unguarded escalation path. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis, though the fix commit is publicly visible and the attack path is structurally a single authenticated API call.
Server-Side Request Forgery in the Grav API plugin (grav-plugin-api) for Grav CMS before 1.0.6 lets a caller holding the api.webhooks.write permission register webhook URLs that the server dereferences with no protocol allow-listing. Because WebhookController.php validates the URL only with FILTER_VALIDATE_URL and WebhookDispatcher.php builds cURL without CURLOPT_PROTOCOLS/CURLOPT_REDIR_PROTOCOLS, an attacker can force the server to fetch file://, gopher://, dict://, and private/link-local targets, exfiltrating local files and internal HTTP responses including cloud metadata credentials. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the root cause and fix are confirmed in the vendor advisory and commit.
Vertical privilege escalation in Grav CMS before 2.0.14 lets a delegated administrator holding only the admin.users permission promote an account to super-admin by saving a group with access[admin][super]=true. The core group blueprint omits the required security@: admin.super guard on the access field, so the operator inherits full super-admin capabilities including the task scheduler and arbitrary Twig template evaluation - effectively code execution on the host. No public exploit identified at time of analysis and the issue is not in CISA KEV, but the fix is confirmed in the vendor GHSA advisory.
Missing authorization enforcement in the Grav API plugin before 1.0.14 allows any authenticated user holding the api.access permission to invoke privileged menubar actions - bypassing per-action authorize field evaluation in MenubarController::executeAction(). The POST /api/v1/menubar/actions/{plugin}/{action} endpoint checks only the baseline api.access gate while the parallel GET listing endpoint correctly calls userPassesAuthorize(), creating an asymmetric enforcement gap (CWE-862). On stock Grav installs the impact is currently latent because no bundled core plugin registers a privileged authorize handler, but any environment deploying third-party plugins that rely on the documented authorize contract is exposed to privilege escalation. No public exploit has been identified at time of analysis and no CISA KEV listing exists.
Broken API-key scope enforcement in the Grav CMS API plugin (getgrav/grav-plugin-api) before 1.0.14 lets an authenticated holder of a restricted, scoped API key read authorize-gated administrative UI metadata that their scope should forbid. Because userPassesAuthorize() checks the underlying account's super-admin flag and ACL grants instead of the presenting key's declared scopes, a low-privilege key minted on a privileged account inherits the account's full authorization, exposing sidebar/menubar/widget item definitions and users-list columns, row-actions, and filter-tabs. No public exploit identified at time of analysis; impact is information disclosure only, and the published CVSS 4.0 9.3 appears materially overstated versus the described effect.
Open redirect in the Grav API plugin (grav-plugin-api) before 1.0.14, bundled with Grav 2.0's admin-next/API stack, allows post-login phishing via a backslash normalization bypass in SsoController::sanitizeReturnTo(). An attacker who can send a crafted OAuth login URL to an authenticated admin victim can supply a returnTo value such as '/\evil.com' that passes the guard rejecting '//' prefixes but is silently normalized by the browser into the protocol-relative URL '//evil.com', redirecting the victim to an attacker-controlled site immediately after a legitimate login. No public exploit has been identified at time of analysis, though the backslash-normalization technique is a well-documented browser behavior; the vendor advisory references a fix in version 1.0.14.
Authorization bypass in the Grav API plugin (getgrav/grav-plugin-api, bundled with Grav 2.0) before 1.0.15 lets a holder of a narrowly-scoped API key act outside its granted scope. Because BlueprintPathResolver::resolveUserScope() checks the underlying account's raw super-admin ACL flag (access.api.super) rather than the scope actually minted into the presented key, an attacker with a key limited to api.media.write on a super-admin account can write files into other users' account directories and enumerate their file listings without holding api.users.write. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Path traversal in Grav Plugin API versions 1.0.0-beta.10 through 1.0.14 enables an authenticated editor-level user to write attacker-controlled page content and media to arbitrary filesystem locations accessible to the web server process. The root cause is an incomplete fix for a prior related path traversal (GHSA-qjq4-jp55-4mx2) that left the 'suffix' parameter of the PagesController::batchCopy() method unvalidated against directory escape sequences. No public exploit code or CISA KEV listing has been identified at time of analysis; vendor-released patch version 1.0.15 resolves the issue.
Server-side template injection in grav-plugin-api before 1.0.15 enables remote code execution for any attacker holding api.pages.write permission. The translate() endpoint accepts unsanitized Twig template syntax in header and content parameters, which can be persisted to a page with process.twig enabled and evaluated by the Twig engine at render time. No public exploit or CISA KEV listing has been identified at time of analysis, but the combination of network-reachable exploitation path and high confidentiality and integrity impact from full server-side template evaluation makes this a serious risk for any Grav installation exposing the plugin API to lower-trust users.
Stored cross-site scripting in Grav CMS before 2.0.15 lets authenticated editors smuggle JavaScript event handlers past the detectXss() sanitizer, which fails to flag event handlers (e.g. onerror=) placed in unquoted HTML attribute values containing unpaired quotes. The malicious payload is persisted in page content and executes in the browser of any visitor who later renders that page. Reported by VulnCheck with a CVSS 4.0 base score of 9.3; no public exploit identified at time of analysis and not listed in CISA KEV.
Remote code execution in Grav CMS before 2.0.15 allows attackers holding page-edit or blueprint-config privileges to write arbitrary PHP into web-accessible files and execute it. The flaw lives in the Blueprint dynamic-data 'bare-function' validation, which relies on an incomplete denylist rather than a positive allowlist, letting the error_log function be invoked through a data directive to append attacker-controlled PHP payloads. Reported by VulnCheck; no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Path traversal in Grav CMS before 2.0.15 allows unauthenticated remote attackers to read arbitrary files from sibling directories outside the intended asset root by exploiting a string prefix collision in the static asset handler. The index.php front controller validates asset paths using a simple string prefix check rather than normalized directory-boundary logic, so a request for /assets-private/credentials.yaml passes validation when /assets is the configured base. No public exploit code has been identified and this vulnerability is not in the CISA KEV catalog; the CVSS 4.0 score of 8.2 reflects high confidentiality risk conditioned on a specific deployment layout (AT:P) rather than universal exploitability.
Privilege escalation in getgrav/grav-plugin-api versions 1.0.6 through 1.0.11 allows any holder of a scoped, read-only API key to perform super-admin write operations - including rewriting group ACL maps to elevate arbitrary accounts to super-admin. The flaw exists because four privileged write endpoints (GroupsController, AccountsConfigController, PreferencesController, DashboardWidgetController) authorize via an isSuperAdmin() early-return that entirely skips requirePermission(), the only function that enforces scope caps on API keys. A leaked CI or monitoring key with a minimal scope such as api.pages.read is sufficient to achieve full administrative compromise. No public exploit code has been identified at time of analysis, and a patch is available in version 1.0.13.
Privilege escalation in Grav's Flex Objects plugin (through version 1.4.6, confirmed against Grav 2.0.11) allows an authenticated low-privileged admin to achieve full site takeover by exploiting a missing authorization check in FlexApiController::update(). The generic /api/v1/flex-objects/user-accounts and /api/v1/flex-objects/user-groups API endpoints omit the field-level, target, and super-admin guards enforced by the dedicated Users and Groups controllers, so an account holding only api.access, admin.login, and users.update can overwrite a super administrator's password or self-grant admin.super group membership. No public exploit is identified at time of analysis; vendor-released patch Flex Objects 1.4.7 is available.
Remote code execution in Grav API plugin versions before 1.0.13 is achievable by any attacker holding a scoped api.config.write API key. The ConfigController fails to enforce its super-scope gates, permitting scoped keys to overwrite scheduler.custom_jobs configuration that Grav subsequently executes via the Symfony Process component. A public exploit exists per SSVC data, the attack is rated automatable, and technical impact is assessed as total - making this a high-priority patching target despite a low EPSS score.
Privilege escalation in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.13 allows an authenticated API key holder with api.users.write scope to silently bypass the scope-cap enforcement and self-elevate to super-administrator. The flaw lies in UsersController's create() and update() methods, which validate scope caps only for api.users.write actions but fall back to a bare isSuperAdmin() check - reading access.api.super from the parent account rather than the key's own scope - when granting super privileges, allowing a limited key on a super account to mint or promote unrestricted admin accounts. A proof-of-concept exists per SSVC assessment, CISA rates exploitation as automatable with total technical impact, and a vendor-released patch is available at version 1.0.13.
Privilege escalation in Grav Plugin API before 1.0.13 allows an attacker controlling a minimal api.users.write API key - issued under a super admin account - to craft invitation records that embed super-admin access flags, which are written verbatim to any account that accepts the invitation. The root cause is CWE-269 improper privilege management: InvitationsController's strip-super and accept-groups decisions evaluate isSuperAdmin() against the owning account rather than against the API key's declared scope, so a deliberately restricted key silently retains the owner's super-admin authority for these checks. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Server-side template injection in Grav CMS before 2.0.13 allows low-privileged page editors to execute arbitrary operating-system commands via the Twig templating engine. Attackers exploit the unsandboxed `find` filter in email-action form parameters - injecting Twig payloads into subject, body, to, or from fields - which are evaluated server-side upon form submission, yielding full RCE. No public exploit code or CISA KEV listing has been identified at time of analysis, though the CVSS 4.0 score of 8.7 (VC:H/VI:H/VA:H) reflects full-compromise potential on the vulnerable system for any actor holding a page editor account.
Privilege escalation in the getgrav/grav-plugin-api plugin before 1.0.13 allows an authenticated attacker holding only a minimal api.access-scoped key on a super account to mint a full-access, unscoped super key by exploiting missing scope-subset enforcement in createApiKey. The self-target path of requireApiKeyPermission() enforces only the baseline api.access scope, while the new key's scopes are taken verbatim from the attacker-controlled request body with no validation that they fall within the caller's granted scopes. Submitting an empty scopes array produces a key with unrestricted super privileges, directly enabling further attack chains including configuration-write-to-RCE. No public exploit code or CISA KEV listing is confirmed at time of analysis; EPSS is 0.30% (23rd percentile). Vendor-released patch version 1.0.13 is available.
Scope-cap bypass in grav-plugin-api before 1.0.13 allows a holder of a least-privilege api.config.write API key issued on a super-admin account to append arbitrary tokens to Grav's Twig sandbox allowlist (persisted to user/config/security.yaml) via the POST /reports/twig-content/allowlist endpoint. Widening the allowlist eliminates the Twig sandbox boundary, converting any subsequent content render into a server-side template injection (SSTI) sink and ultimately enabling remote code execution on the host. No public exploit has been confirmed and the CVE does not appear in CISA KEV at time of analysis, but the two-step primitive - allowlist poisoning followed by SSTI/RCE - is a well-understood attack class in CMS security research.
Server-side template injection (SSTI) leading to remote code execution in the Grav CMS API plugin (getgrav/grav-plugin-api) before version 1.0.13 is reachable by any low-privilege API key holder whose key was minted on a super-admin account. The root flaw is in PagesController::guardTwigContent(), which gates Twig processing via a bare isSuperAdmin() call that ignores the api_key_scopes array, allowing a key deliberately scoped to api.pages.write to enable process.twig on page save despite admin.pages_twig being intentionally excluded from that scope. A public proof-of-concept exists per SSVC data; exploitation is classified as automatable with total technical impact, making this a high-priority patch target for any Grav deployment where the required non-default configuration is active.
Force-disabling of two-factor authentication on Grav CMS user accounts is achievable through a missing scope enforcement check in the grav-plugin-api Composer package before version 1.0.13. Any holder of a low-privilege API key carrying api.users.write permission - or any scoped key on a super account - can POST to /api/v1/users/{user}/2fa/disable without supplying a TOTP code, stripping 2FA from any non-super target account and enabling direct account takeover. No active exploitation is currently confirmed (SSVC Exploitation: none; EPSS 0.34%), but SSVC rates this automatable with total technical impact, making prompt patching critical for any instance exposing the API with delegated keys.
Remote code execution in Grav CMS before 2.0.13 allows authenticated low-privilege users to plant and execute arbitrary PHP files on the server by exploiting a validation bypass in the Flex Objects plugin. The attacker crafts a ZIP archive containing PHP code, circumvents routine-name validation by substituting array notation for the expected string notation, and triggers the unZip routine to write the payload directly into the web root where it becomes immediately executable via HTTP. No public exploit has been identified at time of analysis, but the precise bypass technique disclosed in the advisory substantially lowers the barrier to exploitation for any attacker holding valid credentials.
Path traversal in Grav CMS versions before 2.0.11 enables authenticated editors to disclose arbitrary server-side files to unauthenticated visitors through the image watermark feature. The function ImageMedium::watermark() forwards unsanitized editor-controlled input to the resource locator, whose file:// scheme handler normalizes paths using only lexical '..' collapsing - never verifying containment within the media sandbox - so a crafted Markdown image directive causes the CMS to composite a traversed file into a cached image served at a public, unauthenticated URL. No public exploit has been identified at time of analysis; however, the high confidentiality impact and ease of exploitation once editor access is obtained make this a priority patch for multi-tenant Grav deployments with untrusted editors.
Arbitrary public static PHP method invocation in Grav CMS 2.0.7-2.0.10 allows any account holding page-editing rights (admin.pages) to read arbitrary server-readable files and create or copy files and directories under the web-server account. The flaw lies in Blueprint::isSafeDynamicCall(), which skips its dangerous-callable denylist entirely for strings containing '::' - meaning fully-qualified Class::method notation in blueprint dynamic-field directives is never checked against the blocklist. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code is identified at time of analysis, but the low-privilege requirement and high-impact outcome make this a credible internal threat in multi-tenant or shared Grav deployments.
Open redirect in Grav's form plugin (getgrav/grav-plugin-form) versions 9.1.11 through 9.1.12 allows unauthenticated form submitters to cause the server to issue a 302 redirect to an arbitrary external URL, enabling phishing attacks against site visitors. The vulnerability exists because the redirect process action, introduced in v9.1.11, evaluates user-supplied form field values through Twig expressions without sanitizing the resulting URL, and Grav::redirect() passes that output to the browser without origin validation. No public exploit code has been identified at time of analysis, and no active exploitation is confirmed in CISA KEV, though the low attack complexity and zero-authentication requirement make this straightforward to abuse against any site with a susceptible form blueprint.
Privilege escalation in the Grav CMS Login plugin (grav-plugin-login) <= 3.8.11 lets a low-privilege authenticated user promote their own account to super-admin by injecting privilege fields into a profile self-update request. The flaw lives in processUserProfile() (the update_user task), which — unlike the registration handler — fails to strip 'groups' and 'access' from user-submitted form data before persisting it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but exploitation is trivial once the exposing configuration is present, and gaining super-admin unlocks admin panel access, scheduler-driven RCE, and Twig evaluation.
Remote code execution in Grav CMS 2.0.4 (fixed in 2.0.7) lets an authenticated user holding the admin.pages or api.pages.write permission plant a malicious Class::method callable directive in page frontmatter, which Blueprint::dynamicData() feeds unfiltered into call_user_func_array(). The injected command then executes as the web-server user for any subsequent visitor to the page, including unauthenticated ones. Reported by VulnCheck (CWE-94, CVSS 4.0 base 9.3); no public exploit identified at time of analysis and it is not listed in CISA KEV.
Broken authorization in the Grav api plugin (grav-plugin-api) before 1.0.8 lets any authenticated panel user holding the baseline admin.login permission forge persistent API keys bound to arbitrary accounts, resulting in impersonation and privilege escalation up to account takeover. The plugin intercepts the apiKeyGenerate/apiKeyRevoke admin tasks ahead of the account-management ACL, so a low-privilege operator can mint a key that inherits a higher-privileged account's API permissions. Reported by VulnCheck with a fix in 1.0.8; no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
Cross-origin data exposure in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 stems from a hardcoded 'Access-Control-Allow-Origin: *' header returned on every response, including authenticated endpoints and preflight (OPTIONS) responses. Because the plugin authenticates via the Authorization and X-API-Token request headers rather than cookies, any malicious website scripting a leaked access token can read the response bodies of authenticated endpoints and perform write actions as that token's user. Reported by VulnCheck with no public exploit identified at time of analysis; not listed in CISA KEV.
Sensitive token exposure in the Grav CMS API plugin (getgrav/grav-plugin-api) before 1.0.0-rc.16 allows attackers to hijack valid admin sessions after JWT access tokens leak from URLs. Because JwtAuthenticator::extractBearerToken accepts tokens via the ?token= query string on every API route, those tokens are written verbatim into web server access logs, Referer headers, browser history, and upstream proxy/CDN logs, and any captured token grants full admin API access. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the CVSS 4.0 score of 8.2 reflects the high value of the leaked admin credentials.
Server-side request forgery in Grav CMS before 2.0.4 allows authenticated users holding the api.webhooks.write permission to register webhooks with dangerous cURL protocol handlers (file://, dict://, gopher://) that fire when webhook events trigger. By abusing these unrestricted protocols an attacker can read local files, enumerate process and service information, and pivot to internal-only network services from the trust position of the Grav server. No public exploit has been identified at time of analysis and it is not listed in CISA KEV; risk is driven by the CWE-918 primitive rather than confirmed in-the-wild activity.
Privilege escalation in the getgrav grav-plugin-api before 1.0.6 allows a low-privileged manager holding the api.users.write permission to become a super-admin. The createApiKey, generate2fa, and disable2fa endpoints never re-check super-admin status, so an attacker can mint API keys bound to super-admin accounts or strip 2FA from super-admin users and take over the entire Grav instance. No public exploit identified at time of analysis, but the vendor GHSA advisory and VulnCheck confirm the flaw.
Two-factor authentication bypass in Grav CMS before 2.0.4 lets an attacker who already knows a victim's password overwrite that user's TOTP secret and log in with full 2FA protection stripped away. During the pending TOTP challenge window the login plugin's regenerate2FASecret task verifies only that the user exists — not that the caller is authorized — and requires no CSRF nonce, so the attacker sets an attacker-chosen secret, computes a valid code, and completes login. VulnCheck-reported and CVSS 4.0 scored 9.1; no public exploit identified at time of analysis.
Authorization bypass in the Grav API plugin (getgrav/grav-plugin-api) before 1.0.6 lets any valid API key perform actions far beyond its intended scope. Although keys can be provisioned with a restricted scopes array (e.g. read-only), the ApiKeyAuthenticator class never reads or enforces those scopes and instead returns the owning user's full account object, so a limited key can execute any write, delete, or administrative operation the owner is entitled to. Reported by VulnCheck with no public exploit identified at time of analysis, but the flaw is trivially exploitable by any key holder against default configurations.
Sensitive configuration file disclosure in Grav CMS before 2.0.4 lets unauthenticated remote attackers bypass the bundled .htaccess protections by requesting blocked file types with uppercase or mixed-case extensions (e.g., .YAML, .PHP). The shipped rules omit the Apache [NC] flag, so extension matching is case-sensitive and fails to block case variants on case-insensitive filesystems (Windows/NTFS, macOS/HFS+, Docker volume mounts), exposing files that may hold API keys and credentials. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Authenticated arbitrary file write in the Grav CMS Form plugin (versions before 9.1.8) allows attackers to plant PHP webshells in the web root by abusing the process.save.filename parameter. The filename is checked for path traversal before Twig rendering but never re-validated afterward, so traversal sequences reconstructed during template evaluation bypass the guard. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV; the flaw was disclosed by VulnCheck via a coordinated GitHub security advisory.