CVE-2016-1000027

What it actually does

This is a Java deserialization remote code execution condition in Spring Framework when an application uses Spring components or custom code to deserialize untrusted Java serialized data. If an exposed endpoint accepts attacker-controlled serialized objects and the runtime classpath contains a usable gadget chain, object deserialization can trigger attacker-controlled method execution before application authorization or business logic is reached. Successful exploitation can result in arbitrary command execution in the privileges of the Java application process, with full compromise of confidentiality, integrity, and availability for the affected service.

Why it matters to the business

An exposed vulnerable implementation can let an unauthenticated remote attacker take over an application server, steal application secrets, alter data, deploy malware, or disrupt service. The issue is implementation-dependent: organizations are most at risk where Spring-based services expose Java serialization endpoints, Spring HTTP Invoker-style remoting, or custom deserialization of request data. Although it is not listed in CISA KEV and is not known here as ransomware-associated, public exploitation techniques exist and the EPSS score indicates meaningful exploitation likelihood, so internet-facing or partner-facing Java services should be prioritized.

How an attack unfolds

An attacker first identifies a Spring-based service endpoint that accepts Java serialized objects, commonly through remoting interfaces, legacy integration endpoints, or custom request handlers. The attacker confirms that the endpoint passes untrusted input into Java deserialization, such as ObjectInputStream, Spring serialization utilities, or Spring remoting exporters. They then craft a serialized payload using a gadget chain available in the target application's classpath, often from common Java libraries. When the vulnerable service deserializes the payload, gadget methods execute during object reconstruction, allowing the attacker to run commands, load additional code, open a reverse shell, write files, or pivot to application credentials and internal systems. Authentication may be required in some deployments, but if the vulnerable endpoint is exposed without authentication, exploitation can be fully remote and unauthenticated.

How to fix it

The primary mitigation is to remove Java native deserialization of untrusted data. Do not expose endpoints that accept arbitrary Java serialized objects from users, partners, browsers, message queues, or other untrusted sources. Replace Java serialization with safer formats such as JSON or Protocol Buffers with strict schema validation. Where deserialization cannot be immediately removed, enforce authentication and authorization before deserialization where architecturally possible, restrict network access to trusted callers only, apply JEP 290 object input filters or equivalent allowlists, reject unexpected classes, and remove unnecessary gadget libraries from the runtime classpath. Upgrade affected components to fixed package versions where available: Chainguard mysql-8.0, mysql-8.0-dev, mysql-8.0-oci-entrypoint, mysql-8.0-oci-entrypoint-compat, and mysql-8.0-client should be updated to 8.0.38-r0 or later; spring-projects/spring-framework should include commit 5a30a43b753a971ac8bf4005a8ccddeaff439d7e or a later fixed release/branch equivalent. Because the vendor position notes that untrusted deserialization is not an intended use case, upgrading alone should not be treated as sufficient if the application still deserializes untrusted data.

How to confirm the fix worked

Inventory Java applications and containers for Spring Framework versions through 5.3.16 and for the affected Chainguard packages below their fixed versions. Use software composition analysis, Maven/Gradle dependency reports, container image scanning, and runtime classpath inspection to identify vulnerable Spring libraries and common gadget libraries. Review application routes, controllers, filters, remoting configuration, and integration endpoints for ObjectInputStream, SerializationUtils.deserialize, HttpInvokerServiceExporter, RemoteInvocationSerializingExporter, or any code accepting application/x-java-serialized-object. Confirm fixed state by verifying upgraded package versions, confirming vulnerable remoting/deserialization endpoints are removed or access-controlled, and testing that serialized Java object payloads are rejected before deserialization. Validate that object input filters are active and deny unexpected classes, and confirm network controls prevent untrusted clients from reaching any remaining legacy remoting interfaces.

Typical attack path

1. Discover a Java/Spring service exposing legacy remoting, HTTP Invoker, or custom serialized-object endpoints.
2. Send probes containing Java serialization magic bytes or serialized test objects to determine whether the endpoint deserializes attacker-controlled input.
3. Identify usable gadget chains based on libraries present in the target application's classpath.
4. Generate a malicious Java serialized payload designed to execute a command or load a second-stage payload during deserialization.
5. Submit the payload to the vulnerable endpoint using the expected protocol, HTTP method, headers, or authentication context if required.
6. Achieve code execution under the Java application account and establish persistence, exfiltrate secrets, move laterally, or disrupt the service.

How to detect it

Review web, reverse proxy, application server, EDR, container, and JVM logs for evidence of Java serialized payloads reaching Spring endpoints. Focus on requests with Content-Type application/x-java-serialized-object, request bodies beginning with Java serialization magic bytes AC ED 00 05, unusual POST requests to remoting or integration paths, and spikes in HTTP 500 responses with Java deserialization exceptions. In application logs, look for ObjectInputStream, StreamCorruptedException, InvalidClassException, ClassNotFoundException during deserialization, rejected object input filters, Spring remoting exporter stack traces, and references to known gadget classes such as InvokerTransformer or TemplatesImpl. In host and container telemetry, investigate java processes spawning shells or command interpreters, writing files to temporary directories, launching curl/wget/powershell, or making unexpected outbound connections shortly after suspicious HTTP requests. If available, correlate network captures or WAF logs for serialized Java payload signatures with process creation and outbound beaconing. Threat hunting should include both successful exploitation and failed probing, because attackers often test multiple gadget chains before achieving execution.

• Content-Type: application/x-java-serialized-object
• application/x-java-serialized-object
• AC ED 00 05
• org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter
• org.springframework.remoting.rmi.RemoteInvocationSerializingExporter
• org.springframework.util.SerializationUtils.deserialize
• java.io.ObjectInputStream
• java.io.StreamCorruptedException
• java.io.InvalidClassException
• java.io.InvalidClassException: filter status: REJECTED
• java.lang.ClassNotFoundException
• org.apache.commons.collections.functors.InvokerTransformer
• com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
• ysoserial
• /bin/sh -c
• cmd.exe /c
• powershell -enc
• wget http
• curl http
• java.lang.Runtime.exec
• java.lang.ProcessBuilder

What your security team should do

• Prioritize internet-facing and partner-facing Spring/Java services that expose remoting or serialized-object endpoints.
• Upgrade affected packages to the listed fixed versions, including Chainguard packages to 8.0.38-r0 or later and Spring Framework to a branch containing the fixed commit or later equivalent.
• Remove or redesign any feature that deserializes untrusted Java serialized data; treat this as the durable fix.
• If immediate redesign is not possible, restrict endpoint access at the network layer and require strong authentication before any deserialization path is reachable.
• Enable Java object deserialization allowlists/filters and log rejected classes for investigation.
• Search application code and configurations for ObjectInputStream, SerializationUtils.deserialize, HttpInvokerServiceExporter, RemoteInvocationSerializingExporter, and application/x-java-serialized-object.
• Hunt historical logs for serialized-object probes, deserialization exceptions, Java child process creation, suspicious outbound connections, and web requests followed by application crashes or shell activity.
• Remove unnecessary libraries that provide known deserialization gadget chains from application classpaths.
• Add regression tests that submit Java serialized payloads to public endpoints and verify rejection without deserialization.