Grav CMS 2.0.7 Critical Code Execution PoC Published — Detection, Hunting, and Hardening Guide | Security Arsenal

A public proof-of-concept exploit for a critical code execution vulnerability affecting Grav CMS 2.0.7 has been published to Exploit-DB (entry 52669). Grav is a popular open-source, flat-file PHP content management system — no database required — which makes it a favorite for marketing sites, documentation portals, and lightweight corporate web properties. That same popularity and its typical deployment pattern (internet-facing, often administered by non-security staff, frequently forgotten after launch) makes a weaponized RCE against it a serious operational concern.

When a PoC lands on Exploit-DB, the exploitation clock starts immediately. Within hours to days, proof-of-concept code gets folded into scanner payloads, opportunistic botnets, and initial-access tooling. If you run Grav anywhere in your environment — including that microsite nobody has touched since launch — treat this as an active-threat scenario, not a theoretical one.

Important caveat: at the time of writing, the source material does not reference a CVE identifier or an official CVSS score for this flaw. Do not wait for a CVE to be assigned before acting. Patch/harden first, track identifier assignment second. Verify the current status against the official Grav security advisories at getgrav.org and the Grav GitHub repository.

Technical Analysis

Affected Product and Attack Surface

Product: Grav CMS (flat-file PHP CMS)
Affected version: 2.0.7 (per the published exploit entry); treat prior versions as potentially affected until vendor guidance confirms otherwise
Typical deployment: PHP-FPM or mod_php behind nginx/Apache, commonly on Ubuntu/Debian Linux, frequently in Docker containers or on shared hosting
High-risk components: the Grav Admin plugin (/admin route), the form/plugin processing pipeline, Twig template rendering, and the file-write-capable directories (user/, cache/, tmp/, backup/)

How Code Execution Flaws in Grav Typically Manifest

Because Grav is flat-file, the most damaging exploitation outcomes in this class of bug follow a consistent pattern that defenders can plan around:

Payload delivery — an HTTP request (often unauthenticated, sometimes requiring low-privilege admin access) reaches a vulnerable code path in Grav core or a bundled plugin.
Code execution in the web server context — attacker-controlled input reaches a PHP execution primitive (template rendering, unsanitized file operations, or dynamic function invocation), running commands as the web server user (www-data, nginx, apache).
Web shell drop — the attacker writes a PHP payload into a web-accessible directory. In Grav specifically, watch user/pages/, cache/, tmp/, images/, and the site root. A writable, web-reachable .php file anywhere under the docroot is a red alert.
Post-exploitation — reverse shells, credential harvesting from user/config/ (which can contain SMTP, API keys, and admin secrets), lateral movement, and persistence via cron or injected PHP in theme files.

Exploitation Status

Public PoC: Yes — published to Exploit-DB (entry 52669), meaning working exploit logic is in the open.
Active exploitation: Not confirmed in the source material, but public PoCs against CMS platforms are historically absorbed into mass-scanning campaigns within days. Assume scanning is underway.
CISA KEV: Not listed at time of writing (no CVE has been publicly associated in the source). Monitor the CISA KEV catalog for additions.

Why This Matters for Your Risk Register

Grav instances are frequently deployed outside standard IT inventory — by marketing agencies, as container sidecars, on developer VMs. An RCE on an internet-facing CMS is a beachhead: web server access becomes host access, host access becomes network access. If that host can reach internal segments or holds cloud credentials, a 'minor website bug' becomes an enterprise incident.

Detection & Response

The detections below target the post-exploitation behaviors that are consistent and high-fidelity regardless of the exact exploit primitive: web server processes spawning shells, PHP files appearing in content directories, and suspicious requests against Grav paths. These are the signals a veteran SOC analyst can actually use.

Sigma Rules

YAML

---
title: Web Server Process Spawning Suspicious Child Process
id: 8b2e4f16-7c3a-4d91-ae52-6f1b9c4d8e23
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning shells or common post-exploitation tools, consistent with web application RCE exploitation such as the Grav CMS 2.0.7 code execution flaw.
references:
  - https://www.exploit-db.com/exploits/52669
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - 'php-fpm'
      - 'apache2'
      - 'httpd'
      - 'nginx'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/netcat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate backup or maintenance scripts invoked by the web stack (rare; investigate any hit)
  - Health-check tooling executing curl from within PHP application code
level: high
---
title: PHP File Created in Grav CMS Content or Cache Directories
id: 3d7a9c05-2e48-4b76-bf31-9a5c8e2d6f47
status: experimental
description: Detects creation of PHP files in Grav CMS web-accessible content, cache, tmp, or image directories — a strong indicator of web shell deployment following code execution. Grav is flat-file; legitimate PHP execution should not originate from these paths.
references:
  - https://www.exploit-db.com/exploits/52669
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/user/pages/'
      - '/cache/'
      - '/tmp/'
      - '/images/'
      - '/user/data/'
      - '/assets/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php5'
      - '.php7'
  condition: selection_path and selection_ext
falsepositives:
  - Grav cache compilation (cache/twig, cache/compiled) — scope tighter to your docroot and exclude known compiled-cache subpaths
  - Theme/plugin updates writing files via the admin panel
level: high
---
title: Suspicious HTTP Request Patterns Against Grav CMS Paths
id: 5f1c8e39-6b24-4a58-9d72-1e3b7a4c9f05
status: experimental
description: Detects web proxy/firewall log entries with POST requests or payload-bearing query strings against Grav CMS routes (admin, task handlers) containing common command execution markers.
references:
  - https://www.exploit-db.com/exploits/52669
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/20
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: proxy
detection:
  selection_uri:
    cs-uri|contains:
      - '/admin'
      - '/task:'
      - '/grav'
  selection_payload:
    cs-uri-query|contains:
      - 'cmd='
      - 'exec'
      - 'system('
      - 'passthru'
      - 'shell_exec'
      - 'base64_decode'
      - '%2fbin%2f'
      - 'bash'
  condition: selection_uri and selection_payload
falsepositives:
  - Vulnerability scanners and authorized penetration tests
  - Application performance monitoring with verbose query strings
level: medium

KQL — Microsoft Sentinel / Defender Hunt

If your web servers ship Syslog (via the Azure Monitor Agent / CEF connector) or your WAF/proxy logs land in CommonSecurityLog, hunt for the exploitation chain end to end. Run both queries over at least the last 30 days.

KQL — Microsoft Sentinel / Defender

// Hunt 1: Web server processes spawning shells (Linux Syslog process data)
Syslog
| where TimeGenerated > ago(30d)
| where ProcessName in~ ("php-fpm", "apache2", "httpd", "nginx")
   or SyslogMessage has_any ("php-fpm", "apache2", "nginx")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "nc ", "python", "base64", "id;", "whoami")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc

// Hunt 2: Suspicious requests against Grav paths in proxy/WAF logs
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where RequestURL has_any ("/admin", "/task:", "grav")
| where RequestURL has_any ("cmd=", "exec", "system(", "shell_exec", "base64_decode", "%2fbin%2f", "passthru")
   or RequestMethod == "POST" and RequestURL has "/admin"
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by SourceIP, RequestURL, RequestMethod
| order by Count desc

// Hunt 3: Outbound connections from web server hosts shortly after inbound hits (pivot on the same host)
DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessName in~ ("php-fpm", "apache2", "httpd", "nginx", "www-data")
| where RemotePort in (80, 443, 4444, 8080, 53)
| where RemoteIPType == "Public"
| project TimeGenerated, DeviceName, InitiatingProcessName, InitiatingProcessCommandLine, RemoteIP, RemotePort
| order by TimeGenerated desc

Velociraptor VQL — Endpoint Hunt

Use this as a fleet hunt artifact against any host identified as running Grav. It looks for the two most reliable forensic artifacts: PHP files recently dropped in content directories, and web server workers with shell children.

VQL — Velociraptor

-- Grav CMS post-exploitation hunt: web shells in content dirs and suspicious web server children
-- Deploy as a hunt scoped to hosts tagged as web servers / known Grav hosts

LET shell_files = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
  '/var/www/**/user/pages/**/*.php',
  '/var/www/**/cache/**/*.php',
  '/var/www/**/tmp/**/*.php',
  '/var/www/**/images/**/*.php',
  '/var/www/**/assets/**/*.php',
  '/srv/**/user/**/*.php'
])
WHERE Mtime > now() - 2592000

LET suspicious_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'bash|sh|dash|nc|ncat|curl|wget|python|perl'
  AND Username =~ 'www-data|nginx|apache'

SELECT 'php_file_in_content_dir' AS Indicator, FullPath AS Detail,
       format('%v', Mtime) AS Modified, '' AS ProcDetail
FROM shell_files
UNION ALL
SELECT 'web_user_shell_process' AS Indicator, Exe AS Detail,
       format('%v', CreateTime) AS Modified, CommandLine AS ProcDetail
FROM suspicious_procs

Bash Triage and Hardening Script

Run this on any host suspected of running Grav. It identifies the installed version, sweeps for recently modified PHP files in high-risk directories, greps access logs for exploitation markers, and checks for exposed admin routes. It makes no destructive changes — review output before acting.

Bash / Shell

#!/usr/bin/env bash
# grav-rce-triage.sh — triage + hardening checks for Grav CMS code execution exposure
set -euo pipefail

echo "=== [1] Locate Grav installations ==="
# Grav core is identifiable by its system/ directory and bin/grav CLI
find /var/www /srv /opt /home -maxdepth 6 -name "grav" -path "*/bin/*" -type f 2>/dev/null | while read -r g; do
  root="$(dirname "$(dirname "$g")")"
  echo "[+] Grav found at: $root"
  grep -m1 -E "Grav|version" "$root/CHANGELOG.md" 2>/dev/null | head -3 || true
done

echo "=== [2] Sweep for recently modified PHP files in content/cache dirs (last 14 days) ==="
find /var/www /srv -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -mtime -14 2>/dev/null \
  | grep -E "/(user|cache|tmp|images|assets|data)/" | head -50

echo "=== [3] Grep web access logs for exploitation markers (last 7 days of rotated logs) ==="
for log in /var/log/nginx/access.log /var/log/apache2/access.log /var/log/httpd/access_log; do
  [ -f "$log" ] || continue
  echo "--- $log ---"
  grep -aEi "cmd=|exec|system\(|shell_exec|base64_decode|/bin/(sh|bash)|passthru|task:" "$log" | tail -30
done

echo "=== [4] Check for world-writable PHP-executable directories ==="
find /var/www /srv -type d -writable \( -path "*/user*" -o -path "*/cache*" -o -path "*/tmp*" \) 2>/dev/null | head -20

echo "=== [5] Cron / persistence check for web users ==="
for u in www-data nginx apache; do
  crontab -u "$u" -l 2>/dev/null && echo "[!] Review cron entries for $u above"
done
ls -la /etc/cron.d/ 2>/dev/null | grep -Ei "www|grav" || echo "[ok] no suspicious cron.d entries"

echo "=== [6] Grav version check + upgrade path ==="
echo "If version is 2.0.7 (or any vulnerable release), upgrade immediately:"
echo "  cd <grav_root> && bin/gpm selfupgrade -f && bin/gpm update -y"
echo "Verify with: bin/grav --version"

echo "=== Triage complete. Escalate any hits from sections 2/3/5 to IR immediately. ==="

Remediation

Upgrade Grav immediately. From the Grav root: bin/gpm selfupgrade -f then bin/gpm update -y to pull core and plugin updates. Confirm the running version with bin/grav --version and cross-reference it against the latest stable release at getgrav.org/downloads. Do not assume your version is unaffected — verify.
Inventory every instance. Grav's flat-file nature means it hides in places asset management misses: marketing microsites, docs portals, Docker containers, agency-managed hosting. Sweep DNS, certificate transparency logs, and your external attack surface management data for Grav fingerprints (/admin login page, X-Grav headers, theme asset paths).
Restrict the Admin plugin. Until patched, IP-allowlist /admin at the reverse proxy/WAF, enforce SSO/MFA in front of it, or take the admin panel offline entirely. Most Grav exploitation requires reaching a vulnerable route — removing reachability removes the risk window.
Block PHP execution in content directories. At nginx/Apache, deny execution of .php/.phtml/.phar under user/, cache/, tmp/, images/, and assets/. This neutralizes web shell drops even if code execution succeeds — a high-value compensating control for any PHP CMS.
Hunt before you patch. A public PoC means exploitation may have already occurred. Run the KQL/VQL hunts above over at least 30 days of telemetry before wiping or rebuilding. Preserve logs and disk images for any host with confirmed hits.
Rotate secrets on affected hosts. Grav stores configuration — including SMTP credentials, API keys, and admin password hashes — under user/config/. If you find evidence of compromise, rotate every secret reachable from that host and review egress from the host for data staging.
Deploy file integrity monitoring on the docroot. FIM alerts on new PHP files in content directories are one of the cheapest, highest-fidelity detections available for this entire class of CMS exploitation.
Track KEV and vendor advisories. If a CVE is assigned and the flaw enters the CISA KEV catalog, federal agencies face a BOD 22-01 remediation deadline — and your SLAs should follow the same clock regardless of sector.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Grav CMS 2.0.7 Critical Code Execution PoC Published — Detection, Hunting, and Hardening Guide