Is CVE-2020-8644 (PlaySMS Server-Side Template Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

Yes. CISA added CVE-2020-8644 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. PlaySMS contains a server-side template injection vulnerability that allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

For this vulnerability, “exploited in the wild” is the practical question that matters most: whether the flaw is not just theoretical, but already being used against real targets. Once CISA lists a CVE in KEV, teams should assume exploitation is credible and that delay has a real cost. The decision now is exposure confirmation, containment, and remediation timing.

That framing is especially important for the CISA Known Exploited Vulnerabilities Catalog, because KEV inclusion is a strong signal that the issue has crossed from research interest into active operational risk. For a server-side template injection issue, the concern is not just page manipulation, but possible remote code execution and follow-on compromise.

How to confirm whether you are exposed

The first step is simple inventory work: determine whether PlaySMS is present anywhere in production, staging, test, externally reachable lab systems, or forgotten internal hosts. Do not rely on a single CMDB entry, because legacy web applications are often mirrored, forked, or left behind on shared infrastructure. If you cannot prove the product is absent, treat it as potentially present until verified.

For version and advisory details, use the vendor’s advisory and the authoritative vulnerability records rather than secondary summaries. The practical value of the record is to identify the exact affected deployment path in your environment, then pair that with application discovery, host inventory, and web-facing asset review. The NIST National Vulnerability Database and CVE Program are the canonical reference points for the record itself.

What to do if patching must wait

If immediate remediation is not possible, focus on reducing exposure rather than accepting the risk as-is. Place the application behind the narrowest possible network access, remove unnecessary internet exposure, and review whether the vulnerable function is reachable from unauthenticated or low-trust paths. Where feasible, add virtual patching or request filtering, but treat that as a temporary control, not a substitute for fixing the application.

Because this is a template-injection path, attackers often benefit from arbitrary input reaching server-side rendering logic. That makes input-path review, web request logging, and rapid rollback planning more useful than generic hardening alone. You should also prepare to disable the affected feature or isolate the application if business continuity allows it. The Web Application Attacks Guide is useful context for understanding how SSTI commonly becomes code execution.

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 CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid detection and remediation central.
Recommendation — Prioritise and remediate the exposed CVE immediately using risk-based vulnerability management.
OWASP ASVS	V15 — Secure Coding and Architecture	SSTI is a server-side input handling and code execution issue.
Recommendation — Review server-side rendering paths and remove unsafe template evaluation.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	An internet-reachable web app flaw is a classic public-facing exploitation path.
Recommendation — Hunt for exploitation of the exposed web application and review internet-facing services first.

Practitioner Guidance

What to prioritise: Treat KEV listing as the trigger for action, not as background context. If PlaySMS is exposed to any network segment you do not fully trust, the priority is to remove reachability, validate whether code execution has occurred, and then patch or retire the instance.

What to verify: Check web server logs, application logs, and host telemetry for suspicious template payloads, unexpected child processes, and new or changed files. If the application had access to credentials, tokens, or adjacent systems, extend the review to those dependent assets because SSTI often becomes a pivot point rather than a standalone event.

Practitioner takeaway: With an actively exploited CVE, the real decision is not whether exploitation is possible, but whether you can prove the vulnerable service was unreachable, uncompromised, or already remediated before the next attacker arrives.

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