CVE-2023-23076

What it actually does

This is an unauthenticated network-reachable OS command injection flaw in the schedule-creation workflow, specifically where an Executor value is used by an Action without sufficient validation or safe command construction. An attacker can supply crafted input that is interpreted by the underlying operating system as commands rather than data. Successful exploitation can result in arbitrary command execution with the privileges of the application service account, enabling file read/write, process execution, credential access from the application host, persistence, lateral movement, or full host compromise. The provided product metadata is inconsistent: the description refers to Support Center Plus 11, while the affected package metadata lists pimcore/pimcore with a Git fix commit; affected-asset validation should therefore confirm both product identity and the exact vulnerable code path before closure.

Why it matters to the business

Because the flaw is remotely exploitable, requires no authentication or user interaction, and carries a critical CVSS score with a high EPSS probability, exposed systems should be treated as high-priority compromise candidates even though it is not currently listed in CISA KEV. A successful attack could let an external actor take over the application server, steal sensitive support or business data, disrupt service availability, alter content or records, deploy malware, and use the server as a foothold into connected internal systems. The issue has been public for several years, increasing the likelihood that scanners, exploit developers, and opportunistic attackers have had time to weaponize similar patterns.

How an attack unfolds

An attacker first identifies an internet-facing or otherwise reachable vulnerable application instance and confirms that the schedule-creation functionality is accessible. They then submit a crafted schedule/action request in which data intended to configure an Executor or Action includes shell metacharacters or command separators. If the vulnerable code concatenates that value into an operating-system command, the application server executes attacker-controlled commands under the service account running the application. The attacker commonly validates execution with a harmless command or outbound network callback, then escalates to reconnaissance, credential discovery, file staging, web shell or backdoor deployment, and persistence. From there, they may exfiltrate application data, modify business records, deploy ransomware tooling, or pivot to systems reachable from the compromised host.

How to fix it

Upgrade affected code to a fixed release or apply the upstream fix identified in the supplied metadata: pimcore/pimcore Git commit 44c6b37aa649a0e3105fa41f3d74a3e511acf964. Because the vulnerability description references Support Center Plus 11 while the package metadata references pimcore/pimcore, verify the actual deployed product and vendor advisory before relying on a single package update. If immediate patching is not possible, restrict network access to the application and administrative/scheduling interfaces, disable or limit schedule-creation functionality where feasible, enforce strong authentication and authorization in front of the affected workflow, block dangerous shell metacharacters at a compensating control layer, and run the application under a least-privileged service account. Harden the host by preventing the application service from spawning shells or script interpreters where operationally possible, limiting outbound egress, removing unnecessary command-line tools, and monitoring for child processes spawned by the application runtime.

How to confirm the fix worked

Confirm remediation by verifying that the deployed code contains the upstream fix commit 44c6b37aa649a0e3105fa41f3d74a3e511acf964 or a vendor release that includes it. Inventory all externally reachable and internally reachable instances that expose schedule/action functionality, and verify product identity because the supplied metadata contains a product-description mismatch. Review application dependency manifests, container images, source commit hashes, build artifacts, and vendor version pages to ensure no vulnerable branch remains. Conduct a controlled security test in a non-production environment using benign command-injection payloads that should be rejected or treated as literal input, not executed. Confirm that application logs show blocked or sanitized input and that the application process does not spawn shell interpreters during schedule creation. Validate compensating controls by ensuring only authorized networks and users can reach schedule-management workflows.

Typical attack path

1. Scan for exposed instances of the affected application or codebase.
2. Fingerprint the application version, schedule/action functionality, and reachable endpoints.
3. Submit a crafted schedule-creation request containing command-injection metacharacters in the Executor or Action-related input.
4. Confirm command execution through command output, timing behavior, file creation, or outbound DNS/HTTP callback.
5. Run host reconnaissance commands to identify user context, operating system, network configuration, installed tools, and accessible secrets.
6. Stage additional tooling such as a web shell, reverse shell, downloader, or persistence script.
7. Access application configuration files, credentials, uploaded files, databases, or connected services.
8. Move laterally or perform impact actions such as data theft, service disruption, content tampering, or malware deployment.

How to detect it

To determine whether exploitation already occurred, review application access logs, scheduler/action audit logs, web server logs, reverse proxy logs, endpoint detection telemetry, process creation events, shell history, file integrity alerts, and outbound DNS/HTTP/network flow records from affected application servers. Look for requests to schedule-creation or action-management functionality containing shell metacharacters, encoded payloads, command separators, or references to system utilities. On Linux, investigate application runtime processes such as Java, PHP-FPM, Apache, Nginx, or application workers spawning /bin/sh, bash, curl, wget, nc, python, perl, or other interpreters. On Windows, investigate application processes spawning cmd.exe, powershell.exe, certutil.exe, bitsadmin.exe, wscript.exe, cscript.exe, mshta.exe, or rundll32.exe. Search for unexpected files in web-accessible directories, temporary directories, upload directories, application plugin/module directories, startup locations, and scheduled task or cron locations. Network telemetry should be checked for unusual outbound connections from the application server shortly after suspicious schedule-creation requests, especially to rare domains, raw IP addresses, paste sites, file-sharing hosts, or dynamic DNS providers. Because no named threat actor or campaign is provided, detections should prioritize behavior-based evidence of command execution rather than campaign-specific indicators.

• java -> /bin/sh
• java -> /bin/bash
• java -> curl
• java -> wget
• java -> nc
• java -> python
• java -> perl
• php-fpm -> /bin/sh
• php-fpm -> /bin/bash
• php-fpm -> curl
• php-fpm -> wget
• php-fpm -> nc
• cmd.exe /c
• powershell.exe -enc
• powershell.exe -EncodedCommand
• certutil.exe -urlcache
• bitsadmin /transfer
• wget http
• curl http
• curl -fsSL
• bash -c
• sh -c
• /bin/sh -i
• /bin/bash -i
• nc -e
• ncat -e
• mkfifo /tmp
• /dev/tcp/
• python -c
• perl -e
• chmod +x /tmp
• crontab -l
• Runtime.getRuntime().exec
• ProcessBuilder
• Executor
• Action
• ;curl
• ;wget
• |curl
• |wget
• `curl
• `wget
• $(curl
• $(wget

What your security team should do

• Treat internet-facing affected instances as urgent due to critical severity, unauthenticated remote exploitability, high EPSS, and long public exposure time.
• Patch or upgrade immediately to a fixed version or code state that includes commit 44c6b37aa649a0e3105fa41f3d74a3e511acf964, after confirming the correct affected product lineage.
• Perform an exposure review for both the product named in the description and the package named in the affected-product metadata because of the mismatch.
• Hunt for evidence of exploitation before and after patching, focusing on application processes spawning shells, downloaders, scripting engines, and outbound callbacks.
• Restrict access to schedule creation and administrative functionality using network controls, identity-aware access, VPN, or allowlisting until remediation is complete.
• Limit outbound egress from application servers to approved destinations to reduce callback, payload download, and data exfiltration opportunities.
• Rotate credentials stored on or accessible from potentially exposed application servers if exploitation is suspected.
• Review file integrity, application upload directories, scheduled jobs, startup scripts, and web-accessible directories for persistence artifacts.
• Add SIEM detections for command-injection patterns in HTTP requests and for shell or script interpreter child processes spawned by the application runtime.
• Document the fixed commit or vendor version in vulnerability management records and re-scan to confirm closure.