Is CVE-2025-0994 (Trimble Cityworks Deserialization) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2025-0994 to its Known Exploited Vulnerabilities catalogue on 7 February 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Trimble Cityworks contains a deserialization vulnerability. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

How to treat CVE-2025-0994 as an exploitation question

This is not just a vulnerability lookup, it is a prioritisation problem. Once CISA has placed a CVE in KEV, the practical assumption is that exploitation has moved from possible to credible and time-sensitive. For Trimble Cityworks, the right first step is confirming whether the product is present anywhere in the environment, including legacy, departmental, or externally hosted deployments.

Because the issue is a deserialization flaw, organisations should think beyond the application banner and verify every place the product can run or be reached. That includes connected services, exposed management interfaces, and any integrations that may still depend on the vulnerable instance. If the product is internet-facing or supports privileged workflows, exposure should be treated as urgent until proven otherwise.

For a fast response path, use Zero-Day and Exploited Vulnerabilities Guide to structure the triage: confirm exposure, decide whether emergency mitigation is needed before maintenance windows, and preserve evidence for post-patch hunting. The key question is not whether the vulnerability exists in the abstract, but whether your deployment can be reached and abused before remediation lands.

What the exploitation status means operationally

“Exploited in the wild” changes the control objective from patch management to active incident readiness. You are no longer estimating likelihood from theory alone, you are responding to confirmed attacker interest and usable exploitation conditions. That makes patching necessary, but not sufficient, because exploitation may already have occurred before the organisation noticed the CVE.

Deserialization flaws are especially sensitive because they can convert a routine application request into code execution or similar unsafe behavior depending on the implementation. The real-world implication is that compromise may not leave a neat, user-visible failure. Attackers may gain execution, manipulate application state, or pivot into adjacent systems that trust the compromised server. This is why exposed Cityworks instances should be assessed as a potential foothold, not just a software defect.

Insecure Deserialisation Guide is the most relevant deeper reference for understanding how object injection and gadget-chain style abuse turn a deserialization bug into a security event. That matters here because the response should include both patching and a compromise review, especially if the product handles administrative or operational data.

What to check before and after remediation

Start with asset scope, then move straight to containment decisions if the product is confirmed. If patching cannot happen immediately, isolate the affected system, restrict network reachability, and reduce the exposure of any accounts or services that can administer the application. Do not wait for proof of exploitation before tightening access, because KEV-listed issues deserve defensive action while the investigation is still underway.

After remediation, review application, host, and authentication logs for suspicious requests, unusual child processes, new scheduled tasks, webshell-like artifacts, unexpected outbound connections, or privilege changes around the exposure window. If the product is used with elevated service accounts or integrated credentials, treat those as potentially exposed and rotate them where the deployment model makes that possible. A clean patch does not by itself prove that pre-patch compromise did not occur.

Vulnerability Management Guide is useful here because the workflow is the same one practitioners use for confirmed exploitation risk: verify scope, prioritize by exploitability, document exceptions, and measure whether the remediation actually closed the exposure. That is the right operating model for a KEV-listed vulnerability with active exploitation evidence.

Risk and Threat Considerations

When a deserialization flaw is already being exploited, the main risk is silent compromise before the patch cycle completes. Attackers often prefer these bugs because they can turn ordinary application traffic into privileged execution paths, and those paths may sit behind trusted business logic rather than obvious perimeter controls.

Failure mechanism: Malicious input is accepted as structured data, then interpreted in a way that permits unsafe object construction or code execution. If the vulnerable Cityworks instance is reachable and the attacker can hit the triggering path, the system may execute attacker-controlled behavior before defenders see a clear service failure.

Impact: The likely consequences are application compromise, data exposure, unauthorized action within the application environment, and possible lateral movement into related systems. If the application uses privileged service credentials or supports operational workflows, the blast radius can extend beyond the vulnerable host itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE exploitation status requires urgent asset validation and remediation prioritisation.
Recommendation — Track Cityworks exposure continuously and prioritise urgent remediation for KEV-listed findings.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Confirmed exploitation requires risk-based prioritisation and exception handling.
	PR.PS-01 — Configuration Management	Patch or mitigate the vulnerable deployment and reduce exploitable exposure.
Recommendation — Treat KEV-listed Cityworks exposure as a high-priority risk decision and escalate remediation. Apply approved fixes or mitigations to the affected Cityworks environment without delay.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question hinges on verifying exposure and responding to an actively exploited flaw.
	SI-2 — Flaw Remediation	Active exploitation makes timely flaw remediation the primary control response.
Recommendation — Scan for Cityworks exposure and verify remediation against the exploited CVE. Remediate the Cityworks flaw promptly and document any delay or exception.

Practitioner Guidance

What to prioritise: Confirm whether Trimble Cityworks exists in production, test, and third-party managed environments, then decide whether you can patch immediately or need temporary isolation first. If the answer is “we are not sure,” treat that as a visibility gap, not a safe state.

What to verify: Validate that remediation changed the exposed attack surface, not just the version number. Review whether the application was reachable during the exploitation window and whether logs show any suspicious activity before or after the fix.

Practitioner takeaway: For a KEV-listed deserialization issue, the correct unit of work is exposure plus compromise review, not patching alone. If you cannot prove the system was unreachable or untouched, assume the vulnerability may have been used and investigate accordingly.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org