Threat Intelligence Database

**Verified against:** `getgrav/grav` devel branch, `GRAV_VERSION = "2.0.15"`, file `index.php ## Title Unauthenticated Path Traversal via Missing Directory-Boundary Check in `plugin-asset-map.php` Static Asset Server (`index.php`) ## Product / Affected Versions - Product: `getgrav/grav` - File: `index.php` (top-level front controller, runs before Grav itself boots) - Confirmed present in: devel branch, 2.0.15 - **Precondition:** requires `user/config/plugin-asset-map.php` to exist and contain at least one route-prefix mapping ,this is an opt-in mechanism (per the code comment: "Fast static asset serving for plugins that bundle SPA apps"). No core mechanism generates this file automatically; it's created by a plugin that opts into this fast-path. **Not reachable on a stock Grav install with no such plugin.** Where reachable, it requires zero authentication. ## CWE CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') , specific mechanism: a path-prefix containment check performed with plain string comparison (`str_starts_with`) instead of a directory-boundary-aware comparison, allowing escape into any sibling path whose name happens to extend the base directory's name as a string. ## Description `index.php` implements a fast-path static file server that runs *before* Grav's own routing/security stack, gated on the presence of an asset-map file: ```php $assetMapFile = __DIR__ . '/user/config/plugin-asset-map.php'; if (is_file($assetMapFile)) { $assetMap = require $assetMapFile; foreach ($assetMap as $routePrefix => $diskPath) { if (str_starts_with($path, $routePrefix)) { $relPath = substr($path, strlen($routePrefix)); $filePath = __DIR__ . '/' . ltrim($diskPath, '/') . $relPath; $realFile = realpath($filePath); $realBase = realpath(__DIR__ . '/' . ltrim($diskPath, '/')); if ($realFile && $realBase && str_starts_with($realFile, $realBase) && is_file($realFile)) { // ... serves $realFile directly, with Content-Type inferred from extension readfile($realFile); exit; } } } } ``` `realpath()` correctly resolves `..` sequences, so a naive `../../etc/passwd`-style traversal that leaves the filesystem entirely is blocked (it wouldn't share the `$realBase` string prefix). **But the containment check itself, `str_starts_with($realFile, $realBase)`, has no directory-boundary awareness** it's a plain string-prefix test, not "is `$realFile` inside the `$realBase` directory." Any resolved path whose string representation merely *begins with* the same characters as `$realBase` passes, including sibling directories that extend the base directory's name (`assets` → `assets-secret`, `assets.bak`, `assets_old`, `assets2`, etc.) a very common real-world directory-naming pattern (backup dirs, versioned dirs, disabled/legacy dirs sitting alongside the active one). ## Live Proof of Concept **Setup:** the exact code block above, extracted verbatim from `index.php`, executed with PHP 8.3.6 against a realistic directory layout (a plugin's active `assets/` dir sitting next to an unrelated `assets-secret/` dir containing a fake secret): ``` user/plugins/myplugin/assets/app.js <- intended, public user/plugins/myplugin/assets-secret/config.php <- NOT intended to be served user/config/plugin-asset-map.php: return ['/myplugin-assets' => 'user/plugins/myplugin/assets']; ``` **Legitimate request** (`/myplugin-assets/app.js`): ``` realFile: '/home/claude/grav-poc/user/plugins/myplugin/assets/app.js' realBase: '/home/claude/grav-poc/user/plugins/myplugin/assets' >>> WOULD SERVE FILE <<< >>> Content: public asset content ``` **Traversal request** (`/myplugin-assets/../assets-secret/config.php`): ``` realFile: '/home/claude/grav-poc/user/plugins/myplugin/assets-secret/config.php' realBase: '/home/claude/grav-poc/user/plugins/myplugin/assets' >>> WOULD SERVE FILE <<< >>> Content: SECRET_API_KEY=sk_live_totally_secret_12345 ``` `str_starts_with('.../assets-secret/config.php', '.../assets')` evaluates `true` because `assets-secret` literally begins with the characters `assets` there is no separator-boundary check (e.g. requiring `$realBase . '/'` as the actual prefix) to prevent this. ## Trust-boundary framing (per Grav's own SECURITY.md) This code path requires **no Grav account** , it runs before Grav even initializes, directly off the raw request path. Per Grav's own stated criteria: *"An unauthenticated attacker can achieve RCE, exfiltrate site data, or gain admin-equivalent control. No Grav account required"* → this matches the **CRITICAL** bar exactly, for any deployment where the `plugin-asset-map.php` mechanism is in active use. ## Suggested Fix Append a trailing directory separator before the prefix comparison, or use a proper containment check: ```php if ($realFile && $realBase && ( $realFile === $realBase || str_starts_with

Scans originating from a single IP address have been targeting an old hospitality management system called PBX in a Flash Hospitality Management System (PIAF-HMS). This application appears abandoned, with the last update 10 years ago, and is known to have an SQL injection vulnerability reported recently. The scans also target other related endpoints such as /admin/, /admin/config.php, /ucp/, /hms/, and /hotel/. The source IP is linked to a bulletproof hosting provider, raising concerns about potential malicious intent. Hotels are considered soft targets due to valuable personal data and the possibility of attackers leveraging compromised PBX systems for man-in-the-middle attacks on guests.

MaxSite CMS through 109.6 ships with a hardcoded session encryption key in application/config/config.php that is never changed during installation, allowing unauthenticated attackers to forge administrator session cookies. Attackers can mint a malicious ci_session cookie with administrator privileges by computing an HMAC-SHA1 using the publicly known encryption key, bypassing authentication checks in is_login() and mso_check_allow() functions.

A vulnerability was detected in light0011 cms c774dce31c6df0055568a8d5c53d964d99be199d/f72cf46f601efb2a0618c3814cc2f61380b38930. This issue affects some unknown processing of the file App/Common/Conf/config.php of the component Debug Mode. The manipulation of the argument DB_DEBUG results in information disclosure. It is possible to launch the attack remotely. The exploit is now public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The project was informed of the problem early through an issue report but has not responded yet.

The Welcart e-Commerce WordPress plugin up to version 2.12.1 contains a PHP Object Injection vulnerability via deserialization of untrusted data in the Telecom EDY payment callback. Unauthenticated attackers can inject arbitrary order metadata during checkout and later trigger deserialization without validation, enabling file deletion on the server, including critical files like wp-config.php. Exploitation requires an admin to print an invoice to trigger the file deletion, potentially leading to remote code execution if the WordPress installer is rerun with attacker-controlled data.

An authenticated remote code execution (RCE) vulnerability exists in the admin_config.php component of seacms version 13.6. This flaw allows attackers with valid authentication to execute arbitrary code by sending a crafted POST request. No patch or remediation information is currently available. There is no evidence of exploitation in the wild at this time.

CVE-2026-79423 is a high-severity authenticated remote code execution vulnerability in the admin_config.php component of seacms version 13.6. It allows attackers with valid privileges to execute arbitrary code by sending a crafted POST request. This vulnerability has a CVSS score of 8.8, indicating a significant impact on confidentiality, integrity, and availability. No patch or remediation information is currently provided.

The SigmaForms Pro – AI Generated Forms plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the delete_submission_files function in all versions up to, and including, 1.4.11. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). The malicious path traversal URL is submitted via form upload field and stored in the database, with deletion triggered when an administrator deletes the submission record from the admin panel.

The WP File Download plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the delete function in all versions. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). The two-stage exploit requires a first request to the file.save task to persist the path-traversal string into file metadata, followed by a second request to the file.delete task to trigger the unlink call — both endpoints lack capability checks and nonce enforcement.

The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the move_folders function in all versions up to, and including, 3.29.12. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). This is exploitable without authentication when a form is configured with public visibility (who_can_see='all'), as the required nonce is publicly obtainable from the rendered form.