CVE-2025-51684

The vulnerability in renderCustomHtml is a straightforward DOM-based XSS: the function receives data via postMessage and injects it directly into the DOM without sanitization or origin verification. If a malicious page can send crafted messages to a window hosting the CleverTap SDK, arbitrary JavaScript executes in the context of the host site. This is not a subtle bug—the data flows from an untrusted source directly into innerHTML or equivalent DOM manipulation with no intermediate sanitization layer. What makes this worth attention despite the low EPSS score (0.00217) is the deployment model. CleverTap is an SDK integrated across thousands of sites. A single vulnerable code path in their repository becomes a single vulnerable code path in every downstream application simultaneously. This is the asymmetric deployment problem: the exploit probability is low per-site, but the blast radius when exploitation succeeds spans CleverTap's entire customer ecosystem. EPSS measures individual exploitability—it doesn't capture systemic exposure. The deeper issue is that this vulnerability class is a design problem, not a one-off mistake. The pattern (receive postMessage data, inject into DOM without sanitization) recurs across SDK after SDK because the security boundary around cross-origin messaging requires explicit construction: origin allowlisting, input sanitization as an API-level guarantee rather than an integrator responsibility, and CSP directives that constrain what the injected content can do. The CleverTap SDK provides none of these by default for renderCustomHtml—it exposes a convenient path that's insecure by default, placing the burden of secure implementation on integrators who may not understand that postMessage data is definitionally untrusted. Check whether your application loads the CleverTap SDK and whether any code path calls renderCustomHtml or passes postMessage data to the SDK. If either is true, treat this as high priority regardless of the EPSS score—the issue isn't whether this specific function is reachable from your threat model, it's that the architectural pattern guarantees similar vulnerabilities will emerge in other functions within the same SDK unless the API design itself changes. Monitor CleverTap's release notes for the patch, but also push for confirmation that the fix includes origin verification and sanitization as default behavior, not as optional configuration for sophisticated integrators.

Reviewed through automated stages and approved by a human before publication.