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.
An account with the admin.pages permission (or api.pages.write) can run shell commands on the server. The command executes whenever anyone — including an unauthenticated visitor — opens the page. Details Blueprint::dynamicData() (system/src/Grav/Common/Data/Blueprint.php:426) passes a Class::method string and its arguments straight to calluserfuncarray() with no allowlist. The form plugin runs page frontmatter through this path (form/classes/Form.php:432), so a page author controls the input. Grav\Common\Utils::arrayFilterRecursive($source,$fn) (system/src/Grav/Common/Utils.php:1169) is a public static that calls $fn($key,$value), so passing system as $fn and a command as the array key runs the command. PoC Placeholders: <BASEURL the site; <SESSIONCOOKIE an admin session cookie for an account with admin.pages; <ADMINNONCE the admin-nonce on any admin page (window.GravAdmin.config.adminnonce). Save a "form" page whose field carries the callable directive: curl…
Recommended action: Upgrade to 2.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The regexreplace filter and function are allowlisted in Grav's Twig content sandbox. When Twig processing in page content is enabled security.twigcontent.processenabled: true, authenticated page editors can supply a catastrophically backtracking PCRE pattern, causing unbounded CPU consumption and denying service to the entire web server process. --- Details The Twig sandbox allowlists, defined in system/config/security.yaml, explicitly include regexreplace in both the filter and function permission lists: Source: system/config/security.yaml The underlying implementation passes the caller-controlled $pattern directly into PHP's pregreplace() without any pattern complexity validation: Source: system/src/Grav/Common/Twig/Extension/GravExtension.php:1317-1319 When twigcontent.processenabled is true, page body content is sandboxed but can use any allowlisted filter. An editor who embeds a catastrophic backtracking pattern causes the PCRE engine to enter exponential time…
Recommended action: Upgrade to 2.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Grav 2.0 renders editor-authored Twig in page content by default and relies on the Twig content sandbox to contain it. The shipped sandbox policy allowlists addcss and addjs on Grav\Common\Assets (system/src/Grav/Common/Twig/Sandbox/SandboxDefaults.php:307). Because the sandbox arbitrates the call and not its downstream effect, a user holding only page-edit rights can register an arbitrary asset from page content; the theme then emits it into the document head as a <script src / <link href tag. The asset URL is concatenated into that tag without escaping, so it can also break out of its own attribute. The save-time XSS scan cannot see this: Security::detectXssInEditorContent() renders the content body in isolation and inspects the returned string, while assets.addJs() acts by mutating the shared Assets service and returns only an object key. The payload contains no markup for the scanner to flag. This is not a Security::detectXss() bypass. It is content reaching an unescaped…
Recommended action: Upgrade to 2.0.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The default .htaccess shipped with Grav (and the reference webserver-configs/htaccess.txt) contains security rules that block direct HTTP access to sensitive file types (.yaml, .yml, .php, .json, .twig, etc.) under user/ and system/vendor/ directories. However, these rules lack the [NC] (No Case) flag, making them case-sensitive. On case-insensitive filesystems (Windows/NTFS, macOS/HFS+, or Linux with Docker volumes mounted from Windows/macOS), an attacker can bypass these rules by requesting files with uppercase extensions (e.g., .YAML, .PHP, .JSON). Affected Versions - Grav 2.0.1 (latest stable as of June 2026) — confirmed - Grav 1.7.x — likely affected (same .htaccess rules) - All versions shipping the current webserver-configs/htaccess.txt Affected Component File: .htaccess (root of Grav installation) Reference: webserver-configs/htaccess.txt Affected Rules (lines 68, 70, 72) All three rules use [F] without [NC], making the extension match case-sensitive. Steps to…
Recommended action: Upgrade to 2.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated visitor exhausts server memory and CPU by requesting an image with oversized resize dimensions. One request drives a worker to several gigabytes of RAM and tens of seconds of CPU. A few concurrent requests take the host down. Details Grav::fallbackUrl() (system/src/Grav/Common/Grav.php:800-804) loops over every query parameter and, when the name matches ImageMedium::$magicactions, calls that method on the medium with the comma-split value as arguments: forceResize runs with force=true, so it sets the output size to the attacker's values with no clamp against the source or any ceiling. The getgrav/image GD adapter then calls imagecreatetruecolor($w, $h). libgd allocates that buffer outside PHP's emalloc, so memorylimit does not cap it. Grav exposes no system.images.maxwidth/maxheight setting. PoC Any page that serves an image works. With a 200x150 source image: Measured on PHP 8.4.21 with memorylimit=128M: - peak worker RSS 3,109 MB - 21.9 s CPU - HTTP 200,…
Recommended action: Upgrade to 2.0.0-rc.8 (pre-release) or 1.7.53 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for GHSA-r7fx-8g49-7hhr / CVE-2026-42841 (Stored XSS via Markdown media attribute() action) is incomplete. The maintainer patched MediaObjectTrait::attribute() to deny dangerous attribute names (event handlers, style, xmlns, srcdoc, formaction) but the sibling MediaObjectTrait::style() method is reachable through the same Markdown excerpt-action pipeline and writes editor-controlled strings straight into the rendered <img style="…" attribute with no sanitization. Any user with admin.pages permission (e.g. an editor) can save Markdown like: which renders to a stored-CSS payload that any higher-privileged viewer (administrator, super-admin, reviewer) loads in their authenticated session. Same trust boundary, same victim, same attacker, same Markdown input vector as the patched GHSA-r7fx-8g49-7hhr issue — the fix simply patched the attribute() entry point and missed the style() sibling. Affected versions Vulnerable at HEAD across every currently-shipping branch (verified…
Recommended action: Upgrade to 2.0.0-rc.9 (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 authenticated administrator with backup permissions can download a ZIP archive containing the full Grav installation root, including user/accounts/admin.yaml with the admin's bcrypt password hash and email, plus user/config/ with all site configuration. The download endpoint requires only the session-static admin-nonce in the URL, no additional form-level CSRF token, and reveals the server's full filesystem path in a Base64-encoded query parameter. Combined with the absence of login rate limiting on http://{GravURL}/admin, an attacker who obtains a single admin-nonce value (via Referrer leakage, browser history, or XSS) can exfiltrate password hashes for offline cracking and achieve account takeover. Details The vulnerability chain spans three components in the deployed Grav source tree at /var/www/html/grav/: 1. Backup archive scope — Backups::backup() /var/www/html/grav/system/src/Grav/Common/Backup/Backups.php:201-272 The backup() static method creates a ZIP of the…
Recommended action: Upgrade to 1.7.53 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Twig sandbox allow-list permits any user with the admin.pages role to call config.toArray() from within a page body, dumping the entire merged site configuration — including all plugin secrets (SMTP passwords, AWS keys, OAuth client secrets, API tokens) — into the rendered HTML. No administrator privileges are required. Details The Twig sandbox allow-list in system/config/security.yaml explicitly permits Config::toArray() for the Grav\Common\Config\Config class: The config object — which holds the full merged configuration tree including every key under plugins. — is injected into every sandboxed render in system/src/Grav/Common/Twig/Twig.php (line 292): Any editor with admin.pages can save a page with process.twig: true in the frontmatter and the following payload in the body: When the page is rendered, the full config tree is dumped as JSON in the HTML, including all plugin secrets stored under user/config/plugins/.yaml. PoC Impact Any user with the editor role…
Recommended action: Upgrade to 2.0.0-rc.2 (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][title] parameter. --- Details Vulnerable Endpoint: GET /admin/pages/[page] Parameter: data[header][title] The application fails to properly validate and sanitize user input in the data[header][title] 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=1 onerror=alert(1) 1. Log in to the Grav Admin Panel and navigate to Pages. 2. Create a new page or edit an existing one. 3. Edit title of the page to <img src=1 onerror=alert(1) <img width="1897" height="700" alt="image" src="https://github.com/user-attachments/assets/77a129ca-5c2b-4743-8c56-c17fa456eefa" / 4. Save…
Recommended action: Upgrade to 1.7.49.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Grav 2.0.0-beta.2, a low-privileged authenticated API user with api.media.write can abuse /api/v1/blueprint-upload to write an arbitrary YAML file into user/accounts/, then log in as the newly created account with api.super privileges. This results in full administrative compromise of the Grav API. Details The vulnerability is located in the API plugin's blueprint upload flow: - user/plugins/api/classes/Api/ApiRouter.php:261 - user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:32-45 - user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:102-114 - user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:271-308 - user/plugins/api/classes/Api/Controllers/BlueprintUploadController.php:407-417 - user/plugins/api/classes/Api/Controllers/AuthController.php:41-55 The issue exists because /api/v1/blueprint-upload accepts caller-controlled destination and scope values and uses them to resolve the final filesystem write target.…
Recommended action: Upgrade to 2.0.0-beta.4 (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-privileged (with the ability to create a page) user can cause XSS with the injection of svg element. The XSS can further be escalated to dump the entire system information available under /admin/config/info whenever a Super Admin visits the page; which can further be chained with the use of admin-nonce to do a complete server compromise (RCE). Details Affected endpoint: admin/pages/<page Affected code: system/src/Grav/Common/Security.php Specifically the line: assumes that the onevents will always begin with either whitespace, ', " which can easily be bypassed with a simple payload like: <img src=x onload=alert('1') This XSS Filter practice is broken. 1. Blacklisting every possible scenario that leads to XSS isn't possible. 2. Regex can't parse HTML. It would be better to use an HTMLPurifier. PoC Grav Core + Admin Plugin Grav Version: v1.7.49.5 - Admin v1.10.49.1 1. Create a low-privileged user with only enough permission to login and perform CRUD on Pages. 2. Login as…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Dear Grav Security Team, A security vulnerability was discovered in Grav CMS that allows authenticated attackers to read arbitrary files from the server through XML External Entity (XXE) injection. Vulnerability Summary | Field | Details | |-------|---------| | Vulnerability Type | XML External Entity (XXE) Injection | | Severity | High (CVSS 7.5) | | Affected Versions | Grav CMS <= 1.7.x | | Affected Component | SVG file upload/processing | | CWE | CWE-611: Improper Restriction of XML External Entity Reference | | Authentication Required | Yes (Admin panel access) | Technical Details Root Cause The application uses simplexmlloadstring() to process uploaded SVG files without disabling external entity loading. This allows attackers to inject XXE payloads that are processed by the XML parser. Vulnerable Code Pattern Attack Vector 1. Attacker authenticates to Grav admin panel 2. Uploads malicious SVG file via Pages → Media or File Manager plugin 3. Server parses SVG and processes XXE…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Report: Grav CMS Unauthenticated Path Traversal & Arbitrary File Write [ZERO-DAY] Unauthenticated Path Traversal leading to Arbitrary Directory Creation and Configuration Injection Summary Grav CMS (v1.7.49.5 and latest development source) is vulnerable to a Zero-Day Path Traversal vulnerability within the FormFlash core component. By manipulating the sessionid (passed as form-flash-id in POST requests), an unauthenticated attacker can traverse the filesystem to create arbitrary directories and write an index.yaml file containing attacker-controlled data. This vulnerability can lead to unauthorized modification of application behavior, potential data integrity issues, and service disruption in production environments. Affected Component - Versions: Confirmed in Grav v1.7.49.5 (latest stable) and the latest development source (March 2026). - Class: Grav\Framework\Form\FormFlash - Method: construct() / getTmpDir() - Parameter: sessionid (Mapped to form-flash-id in POST…
Recommended action: Upgrade to 2.0.0-beta.2 (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 business logic vulnerability in the Grav Admin Panel allows a low-privileged user (with only user creation permissions) to overwrite existing accounts, including the primary administrator. By creating a new user with a username that already exists, the system updates the existing account's metadata and permissions instead of rejecting the request. This leads to a Denial of Service (DoS) on administrative functions and Privilege De-escalation of the root account. Details The vulnerability stems from an insecure "Create or Update" logic within the user management module. When the admin-addon handles a user creation request, it does not strictly validate whether the username is already taken by a higher-privileged account. Instead of returning a "409 Conflict" or a validation error, the application logic proceeds to overwrite the existing user configuration file (e.g., user/accounts/root0.yaml) with the new, lower-privileged data provided by the attacker. Because the attacker…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Insecure Deserialization in File Cache - Severity: High - CWE: CWE-502 - Location: system/src/Grav/Framework/Cache/Adapter/FileCache.php - Sink: unserialize($value, ['allowedclasses' = true]) Affected version(s) - Affected: = 1.7.44 and <= 1.7.49.5 (verified in current codebase and changelog-covered releases). - Fixed: No upstream fix identified in the reviewed branch at the time of analysis. - Notes: Earlier 1.7.x releases may also be affected, but were not fully back-traced in this review. Notes allowedclasses = true allows object instantiation and does not constrain classes. PoC (Primitive Demonstration) Preconditions - Local PHP runtime. - Goal is to validate the deserialization primitive used in cache retrieval. Steps Expected Result - Output contains: FILECACHEUNSERIALIZETRIGGERED. Interpretation This reproduces the same unsafe primitive used by FileCache::doGet(): unserialize($value, ['allowedclasses' = true]). If cache files are attacker-tampered, object magic methods may…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple RCE vectors were found in Grav CMS. Three are critical, two are high. 1. Unsafe unserialize() in JobQueue — direct RCE gadget (Critical) system/src/Grav/Common/Scheduler/JobQueue.php:465 calls unserialize(base64decode(...)) without restricting allowedclasses. The Job class has calluserfuncarray($this-command, $this-args) in its execution path, which is a direct gadget chain — inject a serialized Job with command = 'system' and args = ['whoami']. The same codebase actually has a Serializable trait that correctly restricts classes, so this inconsistency stands out. 2. Unsafe unserialize() in FileCache — arbitrary class instantiation (Critical) system/src/Grav/Framework/Cache/Adapter/FileCache.php:75 does unserialize($value, ['allowedclasses' = true]). That true allows instantiation of any class. If an attacker can write to the cache directory (via any file write primitive), they get object injection → RCE. 3. Unsafe unserialize() in Session (High)…
Recommended action: Upgrade to 2.0.0-beta.2 (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 in getgrav/grav allows publisher-level accounts to execute arbitrary JavaScript. The issue arises from a blacklist bypass in the detectXss() function when handling unquoted HTML event attributes. Details The detectXss() function relies on a blacklist pattern to filter malicious attributes. The specific regex pattern used to match on events is flawed: This pattern fails to properly identify on event handlers that are constructed without quotation marks. This allows an attacker to completely bypass the filter. Note: It is highly recommended to replace this blacklist approach with a robust, established HTML sanitization library. PoC An attacker with publisher-level access can reproduce this by injecting the following payload into any vulnerable content field: <img width="1889" height="482" alt="image1" src="https://github.com/user-attachments/assets/0f1a339b-25a8-4b6e-91af-8c59e6a39297" / <img width="3055" height="920"…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Information disclosure exists in Grav CMS v1.8.0-beta.29. Despite previous security patches (notably in v1.8.0-beta.27/28) aimed at restricting sensitive object access within the Twig environment, the Accounts Service remains exposed. A low-privileged user (EX: Content Editor with only pages.update permissions) can bypass the existing Twig sandbox restrictions by utilizing the grav['accounts'] service. Attacker can programmatically load administrative user objects and extract sensitive data, including Bcrypt password hashes and the security salt. Affected version Grav CMS: v1.8.0-beta.29 (and earlier 1.8.x beta versions). Note: This vulnerability persists even after the vendor attempted to mitigate similar SSTI vectors in earlier beta releases. Steps to Reproduce 1. Create a low-privileged account (MY CASE IS 'editorchen') with permissions limited to admin.login and basic page management (create, update, list). Ensure all administrative permissions (Configuration, User…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Bug Report: Registration Privilege Escalation via Missing Server-Side Validation of groups/access Summary The Login::register() method in the Login plugin accepts attacker-controlled groups and access fields from the registration POST data without server-side validation. When registration is enabled and groups or access are included in the configured allowed fields list, an unauthenticated user can self-register with admin.super privileges by injecting these fields into the registration request. This is a missing server-side validation issue — the only defense is a config-level fields allowlist, which is an admin-facing setting, not a hardcoded security boundary. Affected Component - File: user/plugins/login/classes/Login.php, lines 246-306 - Method: Login::register() - Validation: Login::validateField(), lines 363-432 - Plugin: Login Plugin 3.8.0 - Grav: 1.8.0-beta.29 Root Cause In register() (lines 254-267), the groups and access fields are only set to config defaults if they are…
Recommended action: Upgrade to 2.0.0-beta.2 (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 exists in the Grav CMS Form plugin's select field template. Taxonomy tag and category values are rendered with the Twig |raw filter in the admin panel, bypassing the global autoescape protection. An editor-level user can inject arbitrary JavaScript that executes in any administrator's browser session when they view or edit any page in the admin panel. Additionally, Grav's built-in XSS detection (Security::detectXss()) can be bypassed by using payloads that close the <option/<select context and use unquoted event handlers - the onevents regex fails to match event handlers without quotes or trailing spaces before . Important - The vulnerability is in the Form plugin (select.html.twig), which is installed by default with Grav - The XSS is cross-page: a malicious taxonomy value on one page executes when an admin edits any page, because taxonomy options are rendered from a shared global pool - An editor can exploit this without any…
Recommended action: Upgrade to 2.0.0-beta.2 (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 authenticated user with page editing permissions can inject an executable JavaScript event-handler attribute into rendered image HTML through Grav's Markdown media action syntax. The issue is caused by Markdown image query parameters being converted into callable media actions. The public attribute() media method can be reached this way, allowing an editor to set an arbitrary HTML attribute name and value on the generated image element. For example, this Markdown: is rendered as an image tag containing an executable onload handler: This results in stored XSS when another user views the affected page. In a multi-user Grav installation, a lower-privileged page editor could use this to target administrators or reviewers who preview or view editor-controlled content. Tested versions: - Grav CMS: 1.7.49.5 - Admin Plugin: 1.10.49.1 Suggested classification: - CWE-79: Improper Neutralization of Input During Web Page Generation - Stored Cross-Site Scripting - Suggested CVSS v4.0…
Recommended action: Upgrade to 2.0.0-beta.2 (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 authenticated user with administrative privileges can achieve Remote Code Execution (RCE) by uploading a specially crafted ZIP file through the "Direct Install" tool. While the system attempts to block direct .php file uploads, it fails to inspect the contents of uploaded ZIP archives. Once a malicious plugin is extracted, it can execute arbitrary PHP code or drop a persistent web shell on the server. Details The vulnerability exists in the handling of the directInstall task within the Admin plugin and the Grav Package Manager (GPM) core. - Vulnerable Endpoints: /admin/tools/direct-install - Vulnerable Logic: AdminController.php (lines 1247-1295) and Gpm.php (lines 214-285). - Root Cause: The function Installer::install() (called in Gpm.php:291) extracts the contents of the ZIP file directly into the /user/ plugins/ or /user/themes/ directories without validating the file extensions or the content of the files inside the archive. PoC 1. Prepare the Malicious Plugin Create…
Recommended action: Upgrade to 2.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Having a simple form on site can reveal the whole Grav configuration details (including plugin configuration details) by using the correct POST payload. Sensitive information may be contained in the configuration details. PoC Create a simple form with two fields, 'registration-number' and 'hp'. Add a submit button and set the method to POST(screenshot attached below). Form name set to 'hero-form'. Send a POST request with the following payload and you will notice a response with a php array listing the whole Grav configuration details - including plugins(screenshot attached). registration-number:d643aaaa hp:vJyifp form-name:hero-form uniqueformid:{{vardump(context|slice(0,7))}} Impact Server-Side Template (SST) vulnerability. The vulnerability affects the latest Grav version as of 25th of Match 2025 (1.7.48) with all plugins installed (including forms plugin v.7.4.2) to their latest versions as well.
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 Server-Side Template Injection (SSTI) vulnerability exists in Grav that allows authenticated attackers with editor permissions to execute arbitrary commands on the server and, under certain conditions, may also be exploited by unauthenticated attackers. This vulnerability stems from weak regex validation in the cleanDangerousTwig method. Important - First of all this vulnerability is due to weak sanitization in the method clearDangerousTwig, so any other class that calls it indirectly through for example $twig-processString to sanitize code is also vulnerable. - For this report, we will need the official Form and Admin plugin installed, also I will be chaining this with another vulnerability to allow an editor which is a user with only pages permissions to edit the process section of a form. - I made another report for the other vulnerability which is a Broken Access Control which allows a user with full permission for pages to change the process section by intercepting 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 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][template] parameter. The script is saved within the page's frontmatter and executed automatically whenever the affected content is rendered in the administrative interface or frontend view. --- Details Vulnerable Endpoint: POST /admin/pages/[page] Parameter: data[header][template] The application fails to properly sanitize user input in the data[header][template] field, which is stored in the YAML frontmatter of the page. An attacker can inject JavaScript code using this field, and the payload is rendered and executed when the page is accessed, especially within the Admin Panel interface. --- PoC Payload: <scriptalert('PoC-XXS73')</script Steps to Reproduce: 1. Log in to the Grav Admin Panel and navigate to Pages. 2. Create a new page or edit an existing one. 3. In…
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.