CVE-2021-26914

What it actually does

NetMotion Mobility versions before 11.73 and 12.x versions before 12.02 contain an unauthenticated Java deserialization flaw in the MvcUtil valueStringToObject handling path. A remote attacker who can reach the affected service can submit a malicious serialized Java object that is deserialized by the server. If the required gadget chain or vulnerable classpath is present, deserialization can trigger attacker-controlled code execution. Successful exploitation runs with SYSTEM privileges, giving the attacker full control of the underlying Windows host. The CVSS score is 8.1 because exploitation is network-reachable, requires no authentication or user interaction, and can compromise confidentiality, integrity, and availability, though exploitation complexity is rated high.

Why it matters to the business

Successful exploitation can allow an external attacker to take over a NetMotion Mobility server, which may disrupt secure remote-access operations, expose sensitive traffic or configuration data, and provide a foothold into internal networks. Because this vulnerability has weaponized exploit maturity and a high EPSS probability of exploitation, internet-exposed or partner-accessible Mobility deployments should be treated as high-priority remediation targets even though the issue is not currently listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns.

How an attack unfolds

An attacker first identifies an exposed NetMotion Mobility service and determines whether it is running a vulnerable version prior to 11.73 or a vulnerable 12.x release prior to 12.02. The attacker then sends a crafted request to functionality that reaches the MvcUtil valueStringToObject deserialization logic. The request contains a malicious serialized Java object designed to invoke a gadget chain during deserialization. If the server accepts and deserializes the object, Java object reconstruction triggers unintended method execution, allowing the attacker to execute commands or stage payloads under the service context. Because the vulnerable service can execute as SYSTEM, a successful exploit gives the attacker local administrator-level control. The attacker may then create persistence, dump credentials, modify Mobility configuration, access logs or secrets, pivot to adjacent systems, or deploy additional tooling.

How to fix it

Upgrade NetMotion Mobility to a fixed release: version 11.73 or later for the 11.x branch, or version 12.02 or later for the 12.x branch. If immediate upgrade is not possible, restrict access to Mobility administrative and service interfaces to trusted networks, place the service behind VPN or allowlisted ingress controls, block direct internet exposure, and monitor for suspicious deserialization-related errors or unexpected child processes from Java or Mobility service processes. Because exploitation results in SYSTEM-level code execution, compensating controls should be considered temporary only. After patching, rotate any credentials, API keys, certificates, or shared secrets that may have been accessible to the affected server if compromise is suspected.

How to confirm the fix worked

Confirm installed NetMotion Mobility versions are 11.73 or later, or 12.02 or later for 12.x deployments. Validate exposure by inventorying all externally reachable Mobility hosts and checking service banners, administrative UI version information, package inventories, and vendor build metadata. Confirm that unauthenticated access to sensitive Mobility endpoints is blocked except where explicitly required. After upgrade, perform a controlled vulnerability scan or vendor-supported health check to verify the deserialization flaw is no longer detected. Review service behavior after patching for unexpected Java exceptions, failed deserialization attempts, abnormal service restarts, and unexpected child processes spawned by Mobility or Java services.

Typical attack path

1. Scan for exposed NetMotion Mobility services on internet-facing or externally reachable hosts.
2. Fingerprint the service version or infer vulnerable versions from banners, responses, files, or behavioral differences.
3. Send a crafted unauthenticated request that reaches the MvcUtil valueStringToObject Java deserialization path.
4. Trigger deserialization of a malicious Java object containing a usable gadget chain.
5. Execute commands or payloads with SYSTEM privileges on the Mobility server.
6. Establish persistence, collect credentials or configuration data, and use the server as a foothold for lateral movement.
7. Clean up or rotate infrastructure to avoid detection.

How to detect it

To determine whether exploitation already occurred, review NetMotion Mobility application logs, Windows Application/System/Security logs, web or reverse-proxy access logs, EDR process telemetry, firewall logs, and network packet captures for the period before patching. Focus on unauthenticated requests followed by Java deserialization exceptions, service crashes or restarts, and unexpected child processes launched by Mobility or Java service processes. On Windows, investigate Event ID 4688 process creation events where java.exe, javaw.exe, or NetMotion Mobility service binaries spawn cmd.exe, powershell.exe, wscript.exe, cscript.exe, rundll32.exe, certutil.exe, bitsadmin.exe, mshta.exe, regsvr32.exe, or other living-off-the-land utilities. Review for new local users, new services, scheduled tasks, suspicious files in temporary directories, outbound connections from the Mobility server to unfamiliar IPs, and credential access activity. Network teams should search HTTP bodies or proxy logs for Java serialized object magic bytes and suspicious class or gadget names. Because public exploit tooling is weaponized, absence of a vendor-specific IOC does not prove absence of compromise; behavioral evidence is more reliable.

• MvcUtil
• valueStringToObject
• java.io.ObjectInputStream
• java.io.InvalidClassException
• java.io.StreamCorruptedException
• java.io.OptionalDataException
• java.io.WriteAbortedException
• AC ED 00 05
• rO0AB
• javax.management.BadAttributeValueExpException
• org.apache.commons.collections
• org.apache.commons.collections.functors.InvokerTransformer
• org.apache.commons.collections.functors.ChainedTransformer
• cmd.exe spawned by java.exe
• powershell.exe spawned by java.exe
• wscript.exe spawned by java.exe
• cscript.exe spawned by java.exe
• rundll32.exe spawned by java.exe
• certutil.exe spawned by java.exe
• bitsadmin.exe spawned by java.exe
• mshta.exe spawned by java.exe
• regsvr32.exe spawned by java.exe
• Event ID 4688
• Event ID 7045
• Event ID 4698
• java.io.EOFException

What your security team should do

• Prioritize patching all NetMotion Mobility deployments to 11.73 or later, or 12.02 or later for 12.x, especially internet-facing systems.
• Immediately inventory exposed Mobility services and remove unnecessary public access.
• Apply network allowlisting or segmentation around Mobility services until patching is complete.
• Hunt for historical exploitation using Mobility server logs, Windows Event Logs, EDR telemetry, web/proxy logs, and process creation events.
• Look for Java deserialization errors, suspicious serialized-object payloads, and unexpected process execution by Java or NetMotion Mobility service accounts.
• If suspicious activity is found, treat the host as fully compromised because exploitation can execute as SYSTEM.
• Rotate credentials and secrets stored on or accessible from affected Mobility servers after any suspected compromise.
• Add SIEM detections for deserialization exceptions, anomalous HTTP requests to Mobility endpoints, and command interpreters spawned by service processes.