Is CVE-2023-29492 (Novi Survey Insecure Deserialization) being exploited in the wild?

Yes. CISA added CVE-2023-29492 to its Known Exploited Vulnerabilities catalogue on 13 April 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Novi Survey contains an insecure deserialization vulnerability that allows remote attackers to execute code on the server in the context of the service account.

What “being exploited in the wild” means for this CVE

For a CVE like this, “in the wild” means the vulnerability has moved beyond theoretical proof-of-concept status and has been observed being used against real systems. The practical question is not whether the bug exists, but whether exposure still matters right now, because active exploitation changes priority, urgency, and the need for compromise checks.

For incident response teams, KEV listing is the strongest operational signal. CISA’s catalogue is intended for vulnerabilities with reliable evidence of active abuse, so a KEV entry should be treated as a live threat indicator, not a historical note. That is why CISA guidance is commonly used as a trigger for emergency remediation and exposure review.

When a vulnerability is exploitable remotely, the first decision is whether the affected service is internet-facing, reachable from partner networks, or exposed inside a flattened internal trust zone. That assessment often matters more than a generic severity label, because an active exploit will usually target the easiest reachable instance first.

How the exploitation path typically matters

The underlying issue here is insecure deserialization, which is dangerous because attacker-controlled input can be interpreted as executable object state. Once that happens, the server may process crafted data in a way that leads to code execution, service abuse, or follow-on access using the permissions of the running service account.

That execution context matters. If the service account has access to application data, configuration files, internal APIs, or adjacent systems, the initial exploit can become a broader compromise path. In practice, the damage is often driven less by the deserialization flaw itself and more by what the compromised process can touch after code execution begins.

For a topic like this, Insecure Deserialisation Guide is the most direct conceptual reference because it explains the object-injection and gadget-chain mechanics that turn untrusted data into execution risk.

A second useful lens is exploitation prioritisation. Zero-Day and Exploited Vulnerabilities Guide covers how to triage KEV-listed issues, decide when to accelerate patching, and plan post-fix verification when exploitation may already be under way.

What defenders should do before and after patching

Confirmed exploitation should trigger two parallel tracks: remediation and compromise assessment. Remediation means applying the vendor fix or a supported mitigation as quickly as operationally possible. Compromise assessment means looking for anomalous requests, unexpected child processes, new web shells, suspicious outbound traffic, or changes that indicate the server was already used as an execution foothold.

If patching must wait, reduce exposure immediately. The most effective short-term options are to isolate the system, restrict network reachability, limit who can invoke the vulnerable function, and remove any unnecessary service privileges that would enlarge post-exploit impact. If the service account is broadly privileged, its scope should be narrowed as part of the interim containment step.

CISA Known Exploited Vulnerabilities Catalog, CVE Program, and NIST National Vulnerability Database are the right external references for authoritative recordkeeping, while the vendor advisory remains the source for exact affected and fixed versions.

Risk and Threat Considerations

Active exploitation changes the risk from “potential RCE” to “possible current compromise,” which means the main concern is not just service disruption but unauthorized execution in the application’s trust boundary. Because the flaw executes in the context of the service account, an attacker may inherit whatever access that account already has, including internal data access and lateral movement opportunities.

Failure mechanism: Crafted serialized input is accepted and deserialized by the application, allowing attacker-controlled object behavior to drive server-side execution or unsafe logic paths before normal validation can stop it.

Impact: A successful exploit can lead to remote code execution, theft of application data, persistence, or expansion into nearby systems through the compromised service account and any privileges it already holds.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The CVE is a remote server exploit path against a public-facing application.
Recommendation — Hunt for exploitation attempts against exposed web services and correlate them with inbound request anomalies.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Insecure deserialization is a dangerous form of untrusted input handling.
	SI-2 — Flaw Remediation	A KEV-listed actively exploited flaw requires urgent remediation discipline.
	AC-6 — Least Privilege	The exploit runs in the service account context, so privilege scope affects impact.
Recommendation — Validate and constrain untrusted input before it reaches deserialization logic. Prioritise expedited remediation for actively exploited vulnerabilities and verify deployment. Reduce service-account permissions to the minimum needed for the application to function.
OWASP ASVS	V15 — Secure Coding and Architecture	Deserialization safety is a secure architecture and code-hardening concern.
Recommendation — Design the application to avoid unsafe object deserialization of untrusted data.

Practitioner Guidance

What to verify: Confirm whether Novi Survey is internet-facing, whether the vulnerable code path is reachable, and whether logs show suspicious input patterns or execution anomalies around the KEV date. If you cannot prove the service was not reachable, treat exposure as unresolved until checked.

Decision rule: If the system can still be reached and you have not yet applied the vendor fix, prioritise containment and patching over broad hunting. If patching is delayed, assume the service account may be a blast-radius multiplier and limit its permissions before doing anything else.

What practitioners underestimate: Teams often focus on whether the vulnerability was exploited and miss whether the service account had enough privilege to make the exploit materially worse. That privilege question is often the difference between a contained web compromise and a wider environment incident.

Practitioner takeaway: Treat a KEV-listed deserialization flaw as an active-response problem, not a routine patch item, and validate both exposure and post-exploit privilege because the account context determines how far the compromise can go.