CVE-2025-40553

What it actually does

This is an unauthenticated remote code execution vulnerability caused by unsafe deserialization of untrusted data. A network-accessible attacker can submit a crafted serialized payload to the vulnerable service; when the application deserializes it, attacker-controlled object data can trigger code paths that execute operating system commands in the context of the affected service. Because the CVSS vector is network-accessible, low-complexity, requires no privileges, and requires no user interaction, successful exploitation can provide full confidentiality, integrity, and availability impact on the host or container running the vulnerable component.

Why it matters to the business

Successful exploitation could allow an attacker to take control of the affected service host, steal credentials or sensitive ticketing/operational data, disrupt help desk or automation workflows, pivot further into connected systems, or deploy malware. Although this issue is not currently listed in CISA KEV and no public exploit maturity is indicated, the EPSS score is high and the issue has been public for 194 days, increasing the likelihood that exposed deployments will be probed. Organizations using the affected MinimOS packages should prioritize upgrade because the impacted components may be deployed in Kubernetes or operational infrastructure where compromise can affect broader platform reliability.

How an attack unfolds

An attacker first identifies an internet-facing or internally reachable vulnerable instance of the affected service. They then send a malicious serialized object to a code path that accepts and deserializes untrusted input without adequate validation. During deserialization, a gadget chain or vulnerable class behavior is invoked, causing command execution under the privileges of the application process. The attacker typically validates execution with a harmless command or outbound callback, then downloads tooling, creates persistence where possible, harvests configuration secrets or tokens, and uses the compromised host or container as a foothold for lateral movement. In containerized environments, the attacker may also inspect mounted service account tokens, environment variables, secrets, and network access to adjacent services.

How to fix it

Upgrade all affected packages to the fixed release 2.17.2-r2 or later: keda-fips-2.17 (MinimOS) fixed in 2.17.2-r2; keda-fips-2.17-metrics-apiserver (MinimOS) fixed in 2.17.2-r2; keda-fips-2.17-admission-webhooks (MinimOS) fixed in 2.17.2-r2. Rebuild and redeploy any container images or downstream artifacts that include the vulnerable packages, and verify runtime workloads are actually using the patched image digests rather than only updated tags. If immediate patching is not possible, restrict network access to the service, place it behind authenticated access controls, block unnecessary external exposure, apply WAF or ingress filtering for serialized Java object payloads where feasible, and run the service with least privilege. Rotate secrets, API tokens, and credentials that may have been accessible from vulnerable hosts or containers if compromise is suspected.

How to confirm the fix worked

Confirm package and image versions report 2.17.2-r2 or later for all affected components. Validate running workloads, not just repositories, by checking deployed image digests, container manifests, Kubernetes deployments, admission webhook deployments, and metrics API server pods. Run authenticated vulnerability scans or software composition analysis against built artifacts and live hosts to ensure no vulnerable package remains. Review ingress, firewall, and service exposure to confirm the affected interfaces are not publicly reachable unless explicitly required. Where safe and authorized, perform a non-destructive validation test that confirms malformed serialized input is rejected and does not trigger deserialization errors or command execution. After patching, restart affected services and verify logs show the patched build at startup.

Typical attack path

1. Scan for exposed instances of the affected Web Help Desk or packaged service components.
2. Confirm the target appears to be running a vulnerable build or image version.
3. Send a crafted serialized payload to the vulnerable unauthenticated deserialization path.
4. Trigger deserialization so the payload executes operating system commands as the service user.
5. Establish command-and-control through a reverse shell, web shell, scheduled task, cron job, or downloaded agent.
6. Enumerate local configuration, credentials, tokens, mounted secrets, and reachable internal services.
7. Pivot to connected systems or disrupt the application by altering data, stopping services, or deploying ransomware or destructive tooling.

How to detect it

Investigate application, web server, ingress controller, reverse proxy, container runtime, Kubernetes audit, EDR, and operating system logs for suspicious activity around the affected service. Look for unauthenticated requests containing Java serialized object markers, unusual binary payloads, repeated malformed request errors, and deserialization-related exceptions. On hosts and containers, search for unexpected child processes spawned by the application runtime, especially shells, download utilities, scripting interpreters, or commands that fetch remote payloads. Review outbound network telemetry for new connections from the affected service to unfamiliar IPs, paste sites, file-sharing services, dynamic DNS domains, or command-and-control infrastructure. Examine filesystem changes for recently created scripts, web-accessible files, cron entries, systemd units, startup scripts, modified container layers, and temporary files in writable directories. In Kubernetes environments, review pod exec events, service account token access, secret reads, new or modified roles and role bindings, unexpected admission webhook changes, and anomalous API calls from the affected workload identity. Because no named threat actor or KEV activity is currently provided, prioritize behavior-based detection rather than actor-specific indicators.

• AC ED 00 05
• application/x-java-serialized-object
• ysoserial
• java.io.InvalidClassException
• java.io.StreamCorruptedException
• java.io.OptionalDataException
• java.lang.ClassCastException
• org.apache.commons.collections.functors.InvokerTransformer
• org.apache.commons.collections.functors.ChainedTransformer
• java.lang.Runtime.exec
• ProcessBuilder
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe -enc
• powershell.exe -EncodedCommand
• curl http
• wget http
• nc -e
• ncat -e
• bash -i >&
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Treat externally reachable instances as high priority because exploitation is unauthenticated, network-based, and low complexity.
• Upgrade all affected MinimOS packages and redeploy workloads to version 2.17.2-r2 or later as soon as operationally possible.
• Inventory all downstream images, Helm charts, Kubernetes workloads, and automation pipelines that may include the vulnerable packages.
• Restrict access to affected services at network boundaries and Kubernetes ingress while remediation is underway.
• Hunt for evidence of exploitation before and after patching, focusing on deserialization exceptions, suspicious child processes spawned by Java or application runtimes, outbound callbacks, and unexpected file writes.
• Rotate credentials, service account tokens, API keys, and database credentials accessible to any vulnerable instance if exploitation cannot be confidently ruled out.
• Add detection rules for Java serialized object payloads, ysoserial-style gadget indicators, and unexpected shell or scripting process execution from the application process.
• Document compensating controls and residual exposure for any systems that cannot be upgraded immediately.