Is CVE-2019-10068 (Kentico Xperience Deserialization of Untrusted Data) being exploited in the wild?

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

Yes. CISA added CVE-2019-10068 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Kentico contains a failure to validate security headers. 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.

Why active exploitation changes the response

Once a vulnerability appears in CISA’s Known Exploited Vulnerabilities catalogue, the question is no longer theoretical. For Kentico Xperience, the practical issue is exposure to a deserialisation flaw that can support real-world compromise, so the response must move from routine backlog management to urgent validation, containment and remediation. The same urgency applies even if you have not seen obvious symptoms yet.

The first decision is whether the product is deployed anywhere in your estate, including forgotten internet-facing instances, staging systems and partner-managed environments. If you can confirm exposure, treat the issue as a live remediation item rather than a future patch cycle candidate. If you cannot immediately patch, you still need to reduce reachability and validate whether the vulnerable service can be touched from untrusted networks.

For teams building a repeatable response path, the Zero-Day and Exploited Vulnerabilities Guide is the right operating model for KEV-driven triage, emergency mitigation and post-patch verification. The key lesson is that “actively exploited” changes prioritisation, not just severity scoring.

What deserialisation of untrusted data means in practice

Deserialisation issues become dangerous when a system accepts data that the attacker can shape and then reconstructs objects or state from it without adequate trust controls. That can lead to behaviour the application never intended, including logic abuse, code execution or privilege-sensitive actions, depending on the implementation. The concern is not the syntax of the input alone, but the trust boundary the application crosses when it rebuilds state.

In a web product, the impact is often amplified by the surrounding session, authentication and administrative workflow. If the vulnerable path is reachable before strong access control checks, an attacker may be able to trigger the flaw directly. If it sits behind an authenticated boundary, the practical question becomes whether any low-privilege account, exposed management endpoint or misconfigured integration can reach it.

If you are mapping the underlying weakness rather than the single CVE, the Insecure Deserialisation Guide is a useful reference for understanding how object injection, gadget chains and unsafe allowlisting turn input handling into an exploit path.

How to confirm exposure, reduce blast radius and look for compromise

Start with asset confirmation, then move to containment. That means identifying exact product instances, checking whether the vulnerable feature is reachable, and deciding whether a temporary block, isolation or service disablement is needed while you patch. For externally reachable systems, reduction of exposure is often as important as the patch itself when exploitation is already underway in the wild.

After remediation, review logs for signs of pre-patch activity: unexpected administrative actions, odd session behaviour, new files, altered configuration, unusual outbound connections or authentication anomalies around the vulnerable service. Where the application stored secrets, tokens or privileged session material, rotate the relevant credentials and invalidate sessions that could have been exposed during compromise.

When the response needs to be tied to broader vulnerability operations, the Vulnerability Management Guide helps frame exposure, prioritisation, exception handling and verification as one workflow rather than separate tasks.

Risk and Threat Considerations

Actively exploited deserialisation flaws are high-risk because they sit at the boundary between user-controlled input and application trust. When the vulnerable path is reachable, the attacker may not need novel tradecraft, just a reliable way to trigger the application into processing malicious data before defenders can react.

Failure mechanism: The application accepts untrusted serialized content and reconstructs state or objects without sufficient validation, allowing crafted input to trigger unintended code paths or privileged behaviour.

Impact: Successful exploitation can lead to application compromise, follow-on access to credentials or sessions, and broader lateral movement if the affected instance has privileged connectivity or stored secrets.

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 CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	Confirms exposure by identifying affected assets and known vulnerabilities.
	PR.DS-01 — Data-at-Rest Is Protected	Deserialisation flaws can expose stored secrets and application data.
	DE.CM-01 — Networks and Network Services Are Monitored to Find Anomalous Events	Post-exploitation review depends on detecting unusual service and network activity.
Recommendation — Inventory and confirm every instance that could still accept the vulnerable input. Protect stored secrets and sensitive data on affected systems before exposure can be abused. Monitor affected services for unusual connections, requests and configuration changes.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Directly addresses unsafe processing of untrusted input that drives deserialisation flaws.
	SI-4 — System Monitoring	Needed to spot signs of compromise after exploitation or while patching is delayed.
Recommendation — Validate and constrain input before the application reconstructs objects or state. Review telemetry and alerts for signs of exploitation or persistence on the affected service.
OWASP ASVS	V1 — Encoding and Sanitization	Unsafe deserialisation is driven by mishandled untrusted input reaching the application layer.
Recommendation — Enforce strict input handling and reject data that cannot be safely parsed.
MITRE ATT&CK	T1041 — Exfiltration Over C2 Channel	Compromised web applications often support follow-on data theft after exploitation.
Recommendation — Hunt for outbound data transfer patterns that may follow application compromise.

Practitioner Guidance

What to verify: Confirm whether any instance is internet-facing, whether the vulnerable component is enabled, and whether compensating controls actually block the attack path. Do not assume a patch plan is enough if exposed endpoints remain reachable.

Decision rule: If the system can authenticate or operate with privileged back-end access, treat suspected compromise as possible even when user-facing behaviour looks normal. In that case, rotate credentials and validate adjacent systems before declaring the incident closed.

Practitioner takeaway: For KEV-listed deserialisation issues, the right order is exposure check, containment, patching, then compromise review, because exploitation may already have happened before anyone noticed.

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