Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
93 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A Reflected Cross-Site Scripting (XSS) vulnerability was identified in the /admin/pages/[page] endpoint of the Grav application. This vulnerability allows attackers to inject malicious scripts into the data[header][content][items] parameter. --- Details Vulnerable Endpoint: GET /admin/pages/[page] Parameter: data[header][content][items] The application fails to properly validate and sanitize user input in the data[header][content][items] parameter. As a result, attackers can craft a malicious URL with an XSS payload. When this URL is accessed, the injected script is reflected back in the HTTP response and executed within the context of the victim's browser session. --- PoC Payload: "<ImG sRc=x OnErRoR=alert('XSS-PoC3') 1. Log in to the Grav Admin Panel and navigate to Pages. 2. Create a new page or edit an existing one. 3. In the Advanced Blog Config Items field (which maps to data[header][content][items]), insert the payload above. 4. Save the page. 5. The malicious payload…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A user with admin panel access and permissions to create or edit pages in Grav CMS can enable Twig processing in the page frontmatter. By injecting malicious Twig expressions, the user can escalate their privileges to admin or execute arbitrary system commands via the scheduler API. This results in both Privilege Escalation (PE) and Remote Code Execution (RCE) vulnerabilities. Details Grav CMS allows Twig to be executed in page templates if enabled in admin panel (process: twig: true). A user with publisher/editor privileges, that can create or edit pages and enable twig processing, can thereby inject arbitrary code that will execute in the context of the page render. This enables exploitation of Grav internal APIs such as: - grav.user.update() and grav.user.save() for escalating the current user to super admin or admin - grav.scheduler.addCommand(), grav.scheduler.save() and grav.scheduler.run() for code execution The Twig sandbox is not enforced in this context, allowing…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Stored Cross-Site Scripting (XSS) vulnerability was identified in the /admin/config/site endpoint of the Grav application. This vulnerability allows attackers to inject malicious scripts into the data[taxonomies] parameter. The injected payload is stored on the server and automatically executed in the browser of any user who accesses the affected site configuration, resulting in a persistent attack vector. --- Details Vulnerable Endpoint: POST /admin/config/site Parameter: data[taxonomies] The application does not properly validate or sanitize input in the data[taxonomies] field. As a result, an attacker can inject JavaScript code, which is stored in the site configuration and later rendered in the administrative interface or site output, causing automatic execution in the user's browser. --- PoC Payload: "<scriptalert('XSS-PoC')</script Steps to Reproduce: 1. Log in to the Grav Admin Panel with sufficient permissions to modify site configuration. 2. Navigate to…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a user with privilege of user creation creates a new user through the Admin UI and supplies a username containing path traversal sequences (for example ..\Nijat or ../Nijat), Grav writes the account YAML file to an unintended path outside user/accounts/. The written YAML can contain account fields such as email, fullname, twofasecret, and hashedpassword. In my tests, I was able to cause the Admin UI to write the following content into arbitrary .yaml files (including files like email.yaml, system.yaml, or other site YAML files like admin.yaml) — demonstrating arbitrary YAML write / overwrite via the Admin UI. Example observed content written by the Admin UI (test data): username: ..\Nijat state: enabled email: EMAIL@gmail.com fullname: 'Nijat Alizada' language: en contenteditor: default twofaenabled: false twofasecret: RWVEIHC2AFVD6FCR6UHCO3DS4HWXKKDT avatar: { } hashedpassword: $2y$10$wl9Ktv3vUmDKCt8o6u2oOuRZr1I04OE0YZf2sJ1QcAherbNnk1XVC access: site: login: true Steps…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Endpoint: admin/config/system Submenu: Languages Parameter: Supported Application: Grav v 1.7.48 --- Summary A Denial of Service (DoS) vulnerability was identified in the "Languages" submenu of the Grav admin configuration panel (/admin/config/system). Specifically, the Supported parameter fails to properly validate user input. If a malformed value is inserted—such as a single forward slash (/) or an XSS test string—it causes a fatal regular expression parsing error on the server. This leads to application-wide failure due to the use of the pregmatch() function with an improperly constructed regular expression, resulting in the following error: pregmatch(): Unknown modifier 'o' File: /system/src/Grav/Common/Language/Language.php line 244 Once triggered, the site becomes completely unavailable to all users. --- Details - Vulnerable Endpoint: POST /admin/config/system - Submenu: Languages - Parameter: Supported The application dynamically constructs a regular expression using the…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An IDOR (Insecure Direct Object Reference) vulnerability in the Grav CMS Admin Panel allows low-privilege users to access sensitive information from other accounts. Although direct account takeover is not possible, admin email addresses and other metadata can be exposed, increasing the risk of phishing, credential stuffing, and social engineering. --- Details Endpoint: /admin/accounts/users/{username} Tested Version: Grav Admin 1.7.48 Affected Accounts: Authenticated users with 0 privileges (non-privileged accounts) Description: Requesting another user’s account details (e.g., /admin/accounts/users/admin) as a low-privilege user returns an HTTP 403 Forbidden response. However, sensitive information such as the admin’s email address is still present in the response source, specifically in the <title tag. system/src/Grav/Common/Flex/Types/Users/UserCollection.php <img width="700" height="327" alt="Screenshot 2025-08-24 021027"…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav v1.7.49.5 / Admin v1.10.49.1 – User Enumeration & Email Disclosure Summary A user enumeration and email disclosure vulnerability exists in Grav v1.7.49.5 with Admin plugin v1.10.49.1. The "Forgot Password" functionality at /admin/forgot leaks information about valid usernames and their associated email addresses through distinct server responses. This allows an attacker to enumerate users and disclose sensitive email addresses, which can be leveraged for targeted attacks such as password spraying, phishing, or social engineering. Details The issue resides in the taskForgot() function, which handles the forgot password workflow. Relevant vulnerable logic: When an attacker submits the password reset form at /admin/forgot with an invalid username, the application responds with: However, when a valid username is supplied, and the attacker repeatedly triggers password reset requests, the application responds with: This discrepancy in responses enables: 1. User Enumeration – Attackers…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Stored Cross-Site Scripting (XSS) vulnerability was identified in the /admin/accounts/groups/Grupo endpoint of the Grav application. This vulnerability allows attackers to inject malicious scripts into the data[readableName] parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. --- Details Vulnerable Endpoint: POST /admin/accounts/groups/Grupo Parameter: data[readableName] The application fails to properly validate and sanitize user input in the data[readableName] parameter. This lack of input handling allows attackers to inject arbitrary script content that is stored in the application and executed in the browser of any user who views the affected group configuration. --- PoC Payload: <ScRipTalert('PoC-XSS')</ScRipT 1. Navigate to Accounts Groups in the administrative panel. 2. Create a new group or edit an existing one. 3. In the Display Name field…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Stored Cross-Site Scripting (XSS) vulnerability was identified in the /admin/pages/[page] endpoint of the Grav application. This vulnerability allows attackers to inject malicious scripts into the data[header][metadata], data[header][taxonomy][category], and data[header][taxonomy][tag] parameters. These scripts are stored in the page frontmatter and executed automatically whenever the affected page is accessed or rendered in the administrative interface. --- Details Vulnerable Endpoint: POST /admin/pages/[page] Parameters: - data[header][metadata] - data[header][taxonomy][category] - data[header][taxonomy][tag] The application fails to properly sanitize user input when saving page metadata or taxonomy fields via the Admin Panel. As a result, an attacker with access to the admin interface can inject a malicious script using these parameters, and the script will be stored in the page's YAML frontmatter. When the page or metadata is rendered (especially in the Admin Panel),…
Recommended action: Upgrade to 1.11.0-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Exposure of Password Hashes Leading to privilege escalation Severity Rating: Medium Vector: Privilege Escalation CVE: XXX CWE: 200 - Exposure of Sensitive Information CVSS Score: 6.2 CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:L Analysis It was observed that if a users is given read access on the user account management section of the admin panel can view the password hashes of all users, including the admin user. This exposure can potentially lead to privilege escalation if an attacker can crack these password hashes. An attacker with read access can: View and potentially crack the password hashes. Gain administrative access by cracking the admin password hash. Escalate privileges and compromise the entire admin panel. Proof of Concept 1) Give read access to user accounts to a random user as shown in the following figures: 2) Log in to the admin panel with an account that has read access to user accounts and navigate to the user account management section. 3) Go to the…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DOS on the admin panel Severity Rating: Medium Vector: Denial Of Service CVE: XXX CWE: 400 - Uncontrolled Resource Consumption CVSS Score: 4.9 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H Analysis A Denial of Service (DoS) vulnerability has been identified in the application related to the handling of scheduledat parameters. Specifically, the application fails to properly sanitize input for cron expressions. By manipulating the scheduledat parameter with a malicious input, such as a single quote, the application admin panel becomes non-functional, causing significant disruptions to administrative operations. The only way to recover from this issue is to manually access the host server and modify the backup.yaml file to correct the corrupted cron expression Proof of Concept 1) Change the value of scheduledat parameter to ' as shown in the following figures at the http://127.0.0.1/admin/tools endpoint, and observe the response in the second figure: Figure: Http request on…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to a broken access control vulnerability in the /admin/pages/{pagename} endpoint, an editor ( user with full permissions to pages ) can change the functionality of a form after submission. Details Due to improper authorization checks when modifying critical fields on a POST request to /admin/pages/{pagename}, an editor with only permissions to change basic content on the form is now able to change the functioning of the form through modifying the content of the data[json][header][form] which is the YAML frontmatter which includes the process section which dictates what happens after a user submits the form which include some important actions that could lead to further vulnerabilities. PoC - Have Admin and Form plugins installed - Connect to panel as admin, create user and give him permission for pages all - Now connect as that user and notice you cant edit any process field in the panel - Change anything in the content of the form and save - Intercept the request: - Now…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- A low privilege user account with page editing privilege can read any server files using "Frontmatter" form. - This includes Grav user account files - /grav/user/accounts/.yaml. This file stores hashed user password, 2FA secret, and the password reset token. - This can allow an adversary to compromise any registered account by resetting a password for a user to get access to the password reset token from the file or by cracking the hashed password. Details The vulnerability can be found in /user/plugins/form/templates/forms/fields/display/display.html.twig PoC 1. This PoC was conducted on Grav CMS version 1.7.46 and Admin Plugin version 1.10.46 2. go to “http://grav.local/admin/pages” then create new page with “Page Template” option set to “Form”. 3. Then go to “Expert” and on Frontmatter input box used to following form template. 4. Save page and go the preview or published page you will see the content of “/etc/passwd” file on the server. Impact This can allow a low…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox. Details Grav CMS uses a custom sandbox to protect the powerful Twig methods such as registerUndefinedFilterCallback(). These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., exec(), passthru(), system(), etc.) within Twig template directives. The current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the isDangerousFunction() method in the file system/src/Grav/Common/Twig.php: In this code, the isDangerousFunction() check is bypassed if the filter defined in the $name variable is considered safe. Only an administrator can mark a function as safe by adding it to the system.twig.safefilters configuration properties (whitelists that are empty by default) in the…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A privilege escalation vulnerability exists in Grav’s Admin plugin due to the absence of username uniqueness validation when creating users. A user with the create user permission can create a new account using the same username as an existing administrator account, set a new password/email, and then log in as that administrator. This effectively allows privilege escalation from limited user-manager permissions to full administrator access. Steps to Reproduce 1. Make sure you have two accounts: an admin and a user with create user privilege 2. In the user account, navigate to /grav-admin/admin/accounts/users and click "Add" 3. Enter the name of the admin, complete registration and observe that the existing admin’s email is changed to the value you provided. 4. Log out from user account log in as admin with new credentials Impact 1. Full admin takeover by any user with create user permission. 2. Ability to change admin credentials, install/remove plugins, read or modify site…
Recommended action: Upgrade to 1.8.0-beta.27 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low privilege user account with page edit privilege can read any server files using Twig Syntax. This includes Grav user account files - /grav/user/accounts/.yaml. This file stores hashed user password, 2FA secret, and the password reset token. This can allow an adversary to compromise any registered account by resetting a password for a user to get access to the password reset token from the file or by cracking the hashed password. Proof Of Concept {{ readfile('/var/www/html/grav/user/accounts/riri.yaml') }} Use the above Twig template syntax in a page and observe that the administrator riri's authentication details are exposed accessible by any unauthenticated user. As an additional proof of concept for reading system files, observe the /etc/passwd file read using the following Twig syntax: {{ readfile('/etc/passwd') }} Impact This can allow a low privileged user to perform a full account takeover of other registered users including Adminsitrators. This can also allow an…
Recommended action: Upgrade to 1.7.46 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to the unrestricted access to twig extension class from grav context, an attacker can redefine the escape function and execute arbitrary commands. Details https://github.com/twigphp/Twig/blob/3.x/src/Extension/EscaperExtension.php#L99 Twig supports the functionality to redefine the escape function through the setEscaper method. However, that method is not originally exposed to the twig environment, but it is accessible through the payload below. At this point, it accepts callable type as an argument, but as there is no validation for the $callable variable, attackers can set dangerous functions like system as the escaper function. PoC Impact Twig processing of static pages can be enabled in the front matter by any administrative user allowed to create or edit pages. As the Twig processor runs unsandboxed, this behavior can be used to gain arbitrary code execution and elevate privileges on the instance.
Recommended action: Upgrade to 1.7.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to the unrestricted access to twig extension class from grav context, an attacker can redefine config variable. As a result, attacker can bypass previous patch. Details The twig context has a function declared called getFunction. This function, if the value of $name does not exist in $this-functions, uses calluserfunc to execute callback functions stored in $this-functionCallbacks. It is possible to register arbitrary function using registerUndefinedFunctionCallback, but a callback that has already been registered exists and new callbacks added will not be executed. The default function callback is as follows: If you look at this function, if the value of system.twig.undefinedfunctions is false, it returns false. In that case, it is possible for our registered callback to be executed. At this time, the Grav\Common\Config\Config class is loaded within the grav context, and access to the set method is allowed, making it possible to set the value of…
Recommended action: Upgrade to 1.7.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav validates accessible functions through the Utils::isDangerousFunction function, but does not impose restrictions on twig functions like twigarraymap, allowing attackers to bypass the validation and execute arbitrary commands. Details When we accessed twigarraymap like this, we confirmed that the twigFunction object is properly returned. Since the callable property is correctly included, we can access twigarraymap without any restrictions. Since there is no validation on twigarraymap itself, it is possible to call arbitrary function using calluserfunc. PoC Impact Twig processing of static pages can be enabled in the front matter by any administrative user allowed to create or edit pages. As the Twig processor runs unsandboxed, this behavior can be used to gain arbitrary code execution and elevate privileges on the instance.
Recommended action: Upgrade to 1.7.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav CMS is vulnerable to a Server-Side Template Injection (SSTI), which allows any authenticated user (editor permissions are sufficient) to execute arbitrary code on the remote server bypassing the existing security sandbox. Details The Grav CMS implements a custom sandbox to protect the powerful Twig methods "registerUndefinedFunctionCallback()" and "registerUndefinedFilterCallback()", in order to avoid SSTI attacks by denying the calling of dangerous PHP functions into the Twig template directives (such as: "exec()", "passthru()", "system()", etc.). The current defenses are based on a blacklist of prohibited functions (PHP, Twig), checked through the "isDangerousFunction()" method called in the file "system/src/Grav/Common/Twig.php": In the code above it can be seen that the calls of the "isDangerousFunction()" are not performed when the method/filter in the "$name" variable has been considered safe. A function can be defined safe only by an administrator user, by adding…
Recommended action: Upgrade to 1.7.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav is vulnerable to a file upload path traversal vulnerability, that can allow an adversary to replace or create files with extensions such as .json, .zip, .css, .gif, etc. This vulnerabiltiy can allow attackers to inject arbitrary code on the server, undermine integrity of backup files by overwriting existing backups or creating new ones, and exfiltrating sensitive data using CSS Injection exfiltration techniques. Installation Configuration - Grav CMS 1.10.44 - Apache web server - php-8.2 Details Vulnerable code location: grav/system/src/Grav/Common/Media/Traits/MediaUploadTrait.php/checkFileMetadata() method public function checkFileMetadata(array $metadata, string $filename = null, array $settings = null): string { // Add the defaults to the settings. $settings = $this-getUploadSettings($settings); // Destination is always needed (but it can be set in defaults). $self = $settings['self'] ?? false; if (!isset($settings['destination']) && $self === false) { throw new…
Recommended action: Upgrade to 1.7.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- Due to insufficient permission verification, user who can write a page use frontmatter feature. - Inadequate File Name Validation Details 1. Insufficient Permission Verification In Grav CMS, "Frontmatter" refers to the metadata block located at the top of a Markdown file. Frontmatter serves the purpose of providing additional information about a specific page or post. In this feature, only administrators are granted access, while regular users who can create pages are not. However, if a regular user adds the data[json][header][form] parameter to the POST Body while creating a page, they can use Frontmatter. The demonstration of this vulnerability is provided in video format. Video Link 2. Inadequate File Name Validation To create a Contact Form, Frontmatter and markdown can be written as follows: Contact Form Example Form Action Save Option When an external user submits the Contact Form after filling it out, the data is stored in the user/data folder. The filename under…
Recommended action: Upgrade to 1.7.43 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for SSTI using |map, |filter and |reduce twigs implemented in the commit 71bbed1 introduces bypass of the denylist due to incorrect return value from isDangerousFunction(), which allows to execute the payload prepending double backslash (\\) Details The isDangerousFunction() check in version 1.7.42 and onwards retuns false value instead of true when the \ symbol is found in the $name. Based on the code where the function is used, it is expected that any dangerous condition would return true when |map('\system') is used in the malicious payload, the single backslash is dropped prior to reaching strpos($name, '\\') check, thus $name variable already has no backslash, and the command is blacklisted because it reaches the if (inarray($name, $commandExecutionFunctions)) { validation step. However if |map('\\system') is used (i.e. double backslash), then the strpos($name, "\\") !== false takes effect, and isDangerousFunction() returns false , in which case the RuntimeError…
Recommended action: Upgrade to 1.7.42.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Hi, actually we have sent the bug report to security@getgrav.org on 27th March 2023 and on 10th April 2023. Grav Server-side Template Injection (SSTI) via Twig Default Filters Summary: | Product | Grav CMS | | ----------------------- | --------------------------------------------- | | Vendor | Grav | | Severity | High - Users with login access to Grav Admin panel and page creation/update permissions are able to obtain remote code/command execution | | Affected Versions | <= v1.7.40 (Commit 685d762) (Latest version as of writing) | | Tested Versions | v1.7.40 | | Internal Identifier | STAR-2023-0008 | | CVE Identifier | TBD | | CWE(s) | CWE-184: Incomplete List of Disallowed Inputs, CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine | CVSS3.1 Scoring System: Base Score: 7.2 (High) Vector String: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H | Metric | Value | | ---------------------------- | --------- | | Attack Vector (AV) | Network | | Attack Complexity…
Recommended action: Upgrade to 1.7.42 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.