Is CVE-2021-27852 (Checkbox Survey Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2021-27852 to its Known Exploited Vulnerabilities catalogue on 11 April 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Deserialization of Untrusted Data vulnerability in CheckboxWeb.dll of Checkbox Survey allows an unauthenticated remote attacker to execute arbitrary code.

What CVE-2021-27852 Means for Exposure and Triage

CVE-2021-27852 is not a theoretical issue once it appears in CISA KEV. The immediate question is whether the affected Checkbox Survey installation is reachable, still in service, and exposed to untrusted input paths that can hit the vulnerable deserialization flow. For a remote-code-execution flaw, confirmation of exposure matters more than debating likelihood.

If the product is present, treat the vulnerable component as a priority asset and verify whether the vulnerable feature is externally reachable or only available to a restricted admin path. A KEV listing means you should assume exploitation pressure is already real enough to justify urgent action, even before you have proof of compromise.

For background on how actively exploited vulnerabilities are triaged, see Zero-Day and Exploited Vulnerabilities Guide and the CISA Known Exploited Vulnerabilities Catalog.

Why Deserialization Flaws Are High-Risk

deserialization of untrusted data is dangerous because the application may reconstruct attacker-controlled objects and trigger code paths that were never meant to process hostile input. In practice, that can lead to arbitrary code execution, which turns a simple request into a full system compromise if the process runs with meaningful privileges.

That risk is amplified when the vulnerable code sits in a web-facing component, because the attacker does not need credentials or prior foothold. A flaw of this type is especially sensitive when the process can reach configuration files, service credentials, internal APIs, or other trust boundaries after execution begins.

For the underlying exploit pattern, the Insecure Deserialisation Guide explains why object injection and gadget chains make these bugs so dangerous.

What to Do If You Cannot Patch Immediately

When patching has to wait, reduce exposure first: remove public reachability where possible, place the application behind tighter network controls, and limit access to the specific administrative or application paths that can trigger the vulnerable logic. If you cannot eliminate exposure, assume an attacker may already be testing the target and make detection part of the response plan.

Also check for signs of earlier compromise before you normalize the system. Web shell artifacts, unexpected child processes, unusual outbound connections, new scheduled tasks, and tampered configuration are all relevant follow-up checks for a remote-code-execution path like this one. If the application handled secrets, session material, or service credentials, plan rotation after containment.

For emergency prioritisation, compare the finding against your broader vulnerability queue with the Vulnerability Management Guide and use the NIST National Vulnerability Database and CVE Program for record verification and product metadata.

Risk and Threat Considerations

Once a deserialization flaw is publicly exploitable, the main threat is not just initial access. Attackers can use remote code execution to establish persistence, pivot inside the environment, or stage secondary payloads, especially if the affected service can access internal resources or sensitive files.

Failure mechanism: The application accepts attacker-controlled serialized input, reconstructs objects unsafely, and allows crafted data to trigger execution instead of being treated as inert content.

Impact: An unauthenticated remote attacker may gain code execution on the host, which can lead to full application takeover, lateral movement, credential exposure, and follow-on compromise.

Standards & Framework Alignment

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

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
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Identified	Exploitability depends on knowing where the vulnerable product is deployed.
	PR.PS-06 — Vulnerability Scans are Performed and Results are Resolved	A KEV-listed flaw requires prioritised remediation and verification.
	DE.CM-08 — Vulnerability Scans are Performed	Exploitation triage depends on validating the presence and exposure of the vulnerable service.
Recommendation — Inventory affected instances and classify them as active exposure until remediated. Prioritise remediation and confirm the vulnerable component is no longer exposed. Scan for the product, confirm reachability, and watch for indicators of compromise.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The vulnerability requires urgent remediation or compensating controls.
	SI-4 — System Monitoring	Exploited RCE flaws require hunting for signs of compromise.
Recommendation — Apply the fix or mitigation promptly and verify remediation outcomes. Monitor for suspicious execution, persistence, and outbound activity after exposure.

Practitioner Guidance

What to verify: Confirm whether Checkbox Survey is installed, whether the vulnerable component is deployed on any internet-facing or partner-facing system, and whether the affected function can be invoked without a trusted gateway in front of it. If you cannot answer those three questions quickly, you do not yet have enough exposure visibility to downgrade the issue.

Decision rule: If the instance is reachable and cannot be remediated immediately, treat it as a live exploitation concern and prioritize isolation, compensating controls, and compromise assessment before broader hardening work. If the service is already isolated and no longer needed, removal is better than trying to preserve a vulnerable legacy deployment.

Practitioner takeaway: KEV inclusion changes the operating assumption, you should act as though exploitation is already happening somewhere and focus first on exposure, containment, and compromise verification, not on waiting for a second signal.