CVE-2023-29492 is an insecure deserialization vulnerability in Novi Survey Novi Survey. CISA added it to the Known Exploited Vulnerabilities catalogue on 13 April 2023, which means attackers have used it in real attacks. Novi Survey contains an insecure deserialization vulnerability that allows remote attackers to execute code on the server in the context of the service account.
Why insecure deserialization is dangerous in a web application
Insecure deserialization becomes dangerous when an application accepts serialized data and reconstructs objects without trustworthy validation. In a web product, that can let an attacker shape program state, trigger unintended logic, and cross from data handling into code execution.
This is especially serious in server-side products because the payload is processed by trusted application code. Once the deserialization boundary is broken, the attacker may inherit the application’s internal privileges rather than those of a normal user.
How exploitation typically works
The common failure is not “serialization” itself, but deserializing attacker-controlled input. A crafted object graph, gadget chain, or malformed payload can cause the application to call sensitive methods, load unexpected classes, or invoke dangerous operations during parsing.
That is why insecure deserialization often appears alongside remote code execution, authentication bypass, or privilege abuse. The exact exploit path depends on the language, framework, and available objects, but the pattern is consistent: untrusted bytes are treated as trusted program state.
What organisations should check for exposure
Exposure review starts with inventory: find every deployed instance of the product, confirm where it is reachable, and identify whether the vulnerable interface is internet-facing or only available internally. For a known-exploited CVE, the practical question is not whether the issue exists in theory, but whether any reachable asset can still accept the dangerous input.
It is also worth checking vendor advisories and the CVE Program record alongside the NIST National Vulnerability Database entry for authoritative identification and follow-on remediation details. For prioritisation, use the product owner’s guidance and your own asset visibility rather than relying on the CVE name alone.
Remediation, detection, and post-compromise review
The preferred fix is to remove the deserialization sink or apply the vendor remediation that eliminates unsafe object reconstruction. If immediate patching is not possible, reduce exposure by restricting network access, placing the service behind stronger access controls, and limiting who can reach the affected endpoint.
Detection should look for abnormal requests, unexpected object types, crashes, spawned processes, and suspicious server activity after input parsing. After exploitation, review the host for webshells, modified files, scheduled tasks, new local users, and signs that the service account was used to expand access.
Because the vulnerability can lead to code execution in the context of the service account, identity impact matters: rotate any credentials, tokens, API keys, certificates, or other secrets the service could reach, and assume anything stored or mounted for that account may have been exposed. A broader playbook for exploited applications is covered in NHIMG’s Web Application Attacks Guide.
Risk and Threat Considerations
Known-exploited deserialization flaws are attractive because they can convert a single HTTP request into server-side code execution. Once an attacker can run code in the application context, they may steal data, implant persistence, or pivot toward adjacent systems that trust the compromised service.
Failure mechanism: Untrusted serialized input is parsed by a trusted server process, allowing attacker-controlled object state or gadget chains to trigger unintended execution paths.
Impact: The attacker can obtain the privileges of the affected service account, which can expose data, secrets, and downstream systems that rely on that account or host.
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, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1210 — Exploitation of Remote Services | Deserialization flaws are a common path to remote exploitation of exposed services. |
| Recommendation — Map exposed service exploitation to T1210 and prioritize detection on reachable application endpoints. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Unsafe deserialization is a failure of trusting attacker-controlled input as program state. |
| SI-4 — System Monitoring | Exploitation should be detectable through abnormal process, file, and request activity. | |
| Recommendation — Apply SI-10 to validate and reject untrusted serialized input before object reconstruction. Use SI-4 to alert on anomalous parsing behavior, spawned processes, and suspicious post-exploit activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | A KEV-listed CVE requires asset discovery, prioritisation, and remediation tracking. |
| Recommendation — Prioritise the affected product under CIS-7 and track exposure until the vulnerable instance is removed or fixed. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | The issue arises when untrusted data is accepted and interpreted without safe handling. |
| Recommendation — Review input handling under V1 and remove any deserialization path that accepts attacker-controlled payloads. | ||
Practitioner Guidance
What to watch for: Treat deserialization risks as exposure issues, not just code-quality issues. If a product is internet-facing or processes untrusted payloads, confirm whether the vendor has removed unsafe deserialization paths and whether your deployment still exposes the vulnerable function.
Governance implication: For KEV-listed issues, ownership should be explicit across asset management, patching, and incident response so that exposed instances are found quickly and compromise review is not delayed by unclear responsibility.
Practitioner takeaway: For this kind of CVE, remediation and compromise review should move together, because exploitation often changes both application integrity and the trustworthiness of the service account.