Is CVE-2019-3396 (Atlassian Confluence Server and Data Center Server-Side Template Injection) being exploited in the wild?

Yes. CISA added CVE-2019-3396 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Atlassian Confluence Server and Data Center contain a server-side template injection vulnerability that may allow an attacker to achieve path traversal and remote code execution.

What “being exploited in the wild” means for this CVE

For a CVE like this, the practical question is not just whether the flaw exists, but whether defenders should treat it as an active incident driver. CISA’s KEV inclusion is the strongest public signal that exploitation is confirmed, and for exposed Confluence instances that immediately changes prioritisation from routine patch planning to urgent exposure reduction and compromise checks.

Because the issue is a server-side template injection path that can lead to path traversal and remote code execution, the operational concern is full application compromise, not just a narrow application error. That means internet-facing systems, management interfaces, and any Confluence deployment with broad trust boundaries deserve immediate review.

When a vulnerability has active exploitation evidence, the response threshold should be higher than for a theoretical proof of concept. Treat the system as potentially targeted already, especially if it is reachable from the internet or has historically weak patch governance. For general triage and exploitability context, use the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database as the canonical references, then confirm your own asset exposure against them.

How to confirm exposure and urgency

The first step is to determine whether any Confluence Server or Data Center instance is present in your environment and whether it is reachable by users, partners, or the public internet. If you operate a large estate, do not rely on memory or ownership lists, because stale inventory is one of the common reasons actively exploited flaws remain open.

Next, confirm whether the instance is on a version and configuration path covered by the vendor advisory and the KEV entry. For this CVE, the exact product scope and remediation details should come from Atlassian’s advisory rather than from secondary summaries. If the instance is externally reachable, has administrative interfaces exposed, or sits behind weak compensating controls, treat the case as urgent.

For vulnerability triage, the most useful pattern is to combine exploit evidence with your own asset context. The FIRST EPSS score can help with prioritisation, but KEV status should override normal queue ordering when deciding what to fix first.

Containment, patching, and what to do if you cannot patch immediately

The safest response is to apply the vendor’s fix or mitigation as soon as operationally possible, then verify the system is no longer reachable through the vulnerable path. If patching must wait, reduce exposure first: restrict network access, limit administrative reachability, and remove any public exposure that is not strictly required.

Temporary controls are only a bridge, not a substitute for remediation. If the instance must stay online, lower the blast radius by tightening inbound access, reviewing reverse proxy and WAF rules, and ensuring the application is not trusted as a general-purpose execution surface. A framework like Web Application Attacks Guide is useful here because SSTI, path traversal, and code execution belong to the same defensive family of application-layer compromise.

If your environment uses adjacent Atlassian services, the Atlassian Cloud Security Guide is a practical companion for understanding how permissions, admin controls, and connected apps affect blast radius around Atlassian estates. Even when the vulnerable product is on-premises, surrounding identity and access choices often determine how far an attacker can move after initial access.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0, OWASP ASVS and NIST SP 800-53 Rev 5 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 timely identification and remediation central.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities immediately.
NIST CSF 2.0	DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	Exploited Confluence systems warrant monitoring for compromise indicators.
	RS.MI-01 — Incidents are contained	Active exploitation changes the response from patching alone to containment.
Recommendation — Monitor the application and host for signs of unauthorized activity. Contain exposed instances before or while applying remediation.
OWASP ASVS	V15 — Secure Coding and Architecture	SSTI and path traversal are application-layer failures that belong to secure design review.
Recommendation — Review server-side templating and access boundaries for unsafe execution paths.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Known exploited vulnerabilities require prompt remediation and verification.
Recommendation — Apply the vendor fix and verify the vulnerable component is remediated.

Practitioner Guidance

What to prioritise: Treat KEV-listed, internet-reachable Confluence systems as urgent exposure items before you spend time on lower-signal vulnerabilities. For exploited flaws, the key question is whether the system is still reachable and whether the vulnerable path is still live, not whether you have already seen an alert.

What to verify: Confirm the vendor advisory, your actual deployed build, external reachability, and whether any suspicious application behaviour began before remediation. If you have logs, preserve them before making disruptive changes, because compromise assessment is often the last chance to recover attacker activity.

Decision rule: If patching is delayed, reduce exposure immediately and assume the system may already have been probed. If you find evidence of suspicious template execution, unexpected child processes, webshell-like artifacts, or new admin activity, escalate to incident response rather than treating it as a normal maintenance issue.

Practitioner takeaway: For a KEV-listed application flaw, the right response is to think in terms of exposure, compromise likelihood, and post-exploitation cleanup, not just patch installation.