Back to Intelligence

Critical RCE in 8 Atlassian Products Actively Exploited in the Wild — Detection and Remediation Guide for Jira and Confluence Defenders

SA
Security Arsenal Team
October 8, 2026
11 min read

VulnCheck has confirmed that a critical vulnerability affecting eight Atlassian products — including Jira and Confluence, the two platforms most commonly exposed to the internet in enterprise environments — is being actively exploited in the wild. This is not a theoretical advisory or a proof-of-concept confined to a researcher's lab. Real threat actors are hitting real deployments.

If your organization runs Atlassian Data Center or Server products — and most mid-to-large enterprises do — you should treat this as an incident-response-grade event until you have verified your patch status and hunted for signs of compromise. Jira and Confluence instances are high-value targets: they sit inside the perimeter, hold credentials, API tokens, internal documentation, project data, and frequently integrate with identity providers and CI/CD pipelines. A single compromised Confluence node is a beachhead for lateral movement, data theft, and follow-on ransomware deployment.

This post breaks down what's at risk, how exploitation typically presents on the host and network, and gives you the detection content and remediation steps to act on today.

Technical Analysis

Affected Products and Scope

According to the reporting via VulnCheck and Infosecurity Magazine, the vulnerability affects eight Atlassian products, with Jira and Confluence explicitly named. Atlassian's product family means the blast radius realistically includes:

  • Jira Software (Data Center / Server)
  • Confluence (Data Center / Server)
  • Other Atlassian self-hosted products sharing the affected component (e.g., Jira Service Management, Bitbucket, Bamboo, Crowd, and related Data Center offerings)

Atlassian Cloud instances are managed and patched by Atlassian directly; the exposure here is concentrated in self-hosted Data Center and Server deployments, which are disproportionately run by enterprises — and disproportionately under-patched.

A critical-severity flaw across eight products almost always means a shared underlying component is vulnerable — historically in the Atlassian ecosystem this has been the templating/OGNL layer, a deserialization path, or an exposed servlet/filter reachable pre-authentication. The defender-relevant takeaway is the same regardless of the exact primitive: an unauthenticated remote attacker can execute code or commands in the context of the Atlassian service account, which is the worst-case scenario for a web-facing application.

How the Attack Presents (Defender's View)

Exploitation of Atlassian server products follows a well-worn pattern that we've observed across multiple IR engagements:

  1. Initial access: An HTTP(S) request to a crafted endpoint on the Jira/Confluence Tomcat listener (typically TCP 8080/8443 internally, 443 behind a reverse proxy or load balancer).
  2. Code execution: The Atlassian JVM (java process owned by the confluence, jira, or atlassian service account) spawns a child process — /bin/sh, /bin/bash, curl, wget, python, or on Windows hosts cmd.exe / powershell.exe.
  3. Payload staging: Attackers pull second-stage tooling from external infrastructure, frequently to /tmp, /dev/shm, or the Atlassian install/temp directories.
  4. Persistence: Webshells dropped as .jsp files into the Tomcat webroot, cron entries, systemd units, or malicious plugins/apps installed via the Atlassian Universal Plugin Manager.
  5. Post-exploitation: Credential harvesting from dbconfig.xml and connected directories, internal recon, and pivoting.

Exploitation Status

  • Confirmed active in-the-wild exploitation, per VulnCheck's reporting.
  • Public technical analysis from VulnCheck typically means exploit details are circulating — assume working exploit code is available to commodity actors within days, if it isn't already.
  • Action: Check the CISA Known Exploited Vulnerabilities catalog and Atlassian Security Advisories daily; KEV listing typically follows confirmed in-the-wild reporting quickly and carries a binding remediation deadline for federal agencies (and a de facto deadline for everyone else).

Detection & Response

Exploitation of a Java web application like Jira or Confluence has one extremely high-fidelity observable: the Tomcat/JVM process spawning a shell or script interpreter. This should essentially never happen in normal operation. The detections below target that chokepoint plus webshell staging.

YAML
---
title: Atlassian Java Process Spawning Shell or Script Interpreter
id: 9f2e7a41-3c8b-4d5e-a6f1-7b2c9d4e5f01
status: experimental
description: Detects the Atlassian JVM (java process under confluence/jira user) spawning shells, download tools, or script interpreters — a high-fidelity indicator of RCE exploitation against Jira/Confluence.
references:
  - https://www.infosecurity-magazine.com/news/critical-vulnerability-atlassian/
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/java'
      - '/java.exe'
  selection_parent_user:
    ParentUser|contains:
      - 'confluence'
      - 'jira'
      - 'atlassian'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and (selection_parent_user or selection_parent) and selection_child
falsepositives:
  - Rare — legitimate Atlassian plugins executing scripts. Investigate every hit.
level: critical
---
title: Atlassian Tomcat Process Spawning Command Shell on Windows
id: 2b8d4e6f-1a3c-5e7b-9d2f-4c6a8e0b1d3f
status: experimental
description: Detects the Atlassian Tomcat/Java service spawning cmd.exe or PowerShell on Windows-hosted Jira/Confluence instances, consistent with web application RCE.
references:
  - https://www.infosecurity-magazine.com/news/critical-vulnerability-atlassian/
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059.003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\tomcat9.exe'
      - '\tomcat10.exe'
      - '\commons-daemon.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Very rare on Atlassian hosts — any hit warrants investigation.
level: critical
---
title: Webshell Dropped in Atlassian Installation or Temp Directory
id: 5c1f9a3b-7e2d-4f8a-b6c3-8d0e2f4a6b8c
status: experimental
description: Detects creation of JSP/script files in Atlassian Tomcat web directories or temp paths, indicating webshell deployment following exploitation of Jira/Confluence.
references:
  - https://www.infosecurity-magazine.com/news/critical-vulnerability-atlassian/
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.initial_access
  - attack.t1190
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/atlassian/jira/temp/'
      - '/atlassian/confluence/temp/'
      - '/atlassian-jira/'
      - '/confluence/'
      - '/tomcat/webapps/'
      - '/dev/shm/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.sh'
      - '.elf'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate plugin deployments create JSPs — correlate with change windows and the writing process (java writing JSPs outside a deployment event is suspicious).
level: high
KQL — Microsoft Sentinel / Defender
// Hunt: Atlassian JVM spawning shells/interpreters across Linux hosts (via Syslog/Auditd ingestion)
// and Windows-hosted Jira/Confluence via Defender process events.
// Run over the last 14 days; any hit on an Atlassian host is a P1 investigation.

// Linux hosts (Syslog or Auditd via AMA/CEF)
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName =~ "java"
   or SyslogMessage has_any ("confluence", "jira", "atlassian")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "python", "perl", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc
;

// Windows-hosted Atlassian instances (Defender for Endpoint)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("java.exe", "tomcat9.exe", "tomcat10.exe", "commons-daemon.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "certutil.exe", "bitsadmin.exe", "wscript.exe", "cscript.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc
;

// Network egress from Atlassian hosts to rare external destinations (payload staging)
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "java.exe"
| where RemotePort in (80, 443, 8080, 8443)
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, RemoteIP, RemoteUrl, RemotePort
| where ConnectionCount < 20  // low-volume egress is more suspicious from a web app JVM
| order by FirstSeen asc
VQL — Velociraptor
-- Hunt artifact: Atlassian RCE indicators — shells under the JVM, staged payloads, and webshells
-- Deploy against all Jira/Confluence Data Center/Server nodes.

-- 1) Java/Tomcat processes with shell-like children or suspicious command lines
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)java|tomcat' AND Username =~ '(?i)confluence|jira|atlassian')
   OR CommandLine =~ '(?i)(/bin/(ba)?sh|curl |wget |python|perl|base64 -d|cmd.exe|powershell)'

-- 2) Recently created executable/script artifacts in Atlassian temp and shared-memory paths
SELECT FullPath, Size, Mtime, Ctime, Mode
FROM glob(globs=['/var/atlassian/**/temp/*.sh', '/var/atlassian/**/temp/*.jsp',
                 '/opt/atlassian/**/temp/*.sh', '/opt/atlassian/**/temp/*.jsp',
                 '/dev/shm/*', '/tmp/*.sh', '/tmp/*.elf'])
WHERE Mtime > now() - 1209600  -- last 14 days

-- 3) Outbound connections owned by the JVM (payload staging / C2)
SELECT Pid, Name, LocalAddr, LocalPort, RemoteAddr, RemotePort, State
FROM netstat()
WHERE Name =~ '(?i)java'
  AND State =~ 'ESTABLISHED'
  AND NOT RemoteAddr =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.|127\\.)'
Bash / Shell
#!/bin/bash
# atlassian-harden-verify.sh — Verification and containment helper for Jira/Confluence DC/Server nodes.
# Run as root on each Atlassian host. Read-only checks plus optional containment flags.
# 1) Identify Atlassian version and install state
echo "=== Atlassian Version Inventory ==="
for f in /opt/atlassian/*/atlassian-*-*/WEB-INF/classes/com/atlassian/*/buildinfo.properties \
         /var/atlassian/application-data/*/buildinfo.properties; do
  [ -f "$f" ] && echo "--- $f" && grep -E 'version|build' "$f"
done 2>/dev/null

# 2) Hunt: java processes with shell children (live indicator of exploitation)
echo "=== Suspicious child processes of the Atlassian JVM ==="
for pid in $(pgrep -u confluence java; pgrep -u jira java); do
  ps --ppid "$pid" -o pid,ppid,user,comm,args 2>/dev/null
  pstree -ap "$pid" 2>/dev/null | grep -E 'sh|bash|curl|wget|python|perl|nc'
done

# 3) Hunt: recently modified JSP/scripts in install and temp directories (webshell staging)
echo "=== Recent script artifacts in Atlassian paths (last 14 days) ==="
find /opt/atlassian /var/atlassian -type f \( -name '*.jsp' -o -name '*.sh' -o -name '*.elf' \) -mtime -14 -ls 2>/dev/null
find /tmp /dev/shm -type f -mtime -14 -ls 2>/dev/null

# 4) Hunt: unexpected outbound connections from the JVM
echo "=== Established outbound connections from java ==="
ss -tnp 2>/dev/null | grep java | grep ESTAB

# 5) Hunt: new persistence (cron/systemd) for atlassian service accounts
echo "=== Persistence check: cron and systemd units ==="
crontab -l -u confluence 2>/dev/null; crontab -l -u jira 2>/dev/null
ls -la /etc/systemd/system/ | grep -iE 'atlassian|jira|confluence'
grep -rE 'curl|wget|bash -i|/dev/tcp' /etc/cron* /var/spool/cron 2>/dev/null

# 6) Verify ingress exposure: is the instance reachable from the internet?
echo "=== Listener check (Tomcat 8080/8443/8009) ==="
ss -tlnp 2>/dev/null | grep -E ':8080|:8443|:8009'

echo ""
echo "NEXT STEPS:"
echo "[1] Confirm installed version against Atlassian Security Advisories:"
echo "    https://confluence.atlassian.com/security/security-bulletins-1716549380.html"
echo "[2] If unpatched: patch IMMEDIATELY to the fixed version listed in the advisory."
echo "[3] If any suspicious child process or artifact found: isolate the host, memory-capture first, then IR."
echo "[4] If you cannot patch today: restrict the listener to internal/VPN source IPs via host firewall or WAF."

Remediation

Act on this in priority order:

  1. Inventory and patch immediately. Enumerate every self-hosted Atlassian instance (including forgotten test/staging nodes — these are favorite entry points). Cross-reference your installed builds against the fixed versions in the Atlassian Security Bulletins page and upgrade to the fixed release for your product line. With confirmed in-the-wild exploitation, "next maintenance window" is not an acceptable answer — treat this as an emergency change.
  2. Check CISA KEV. Monitor the Known Exploited Vulnerabilities catalog. Once listed, federal agencies face a binding remediation deadline — use it as your internal SLA as well.
  3. Hunt before you assume clean. Patching closes the door but does not evict anyone already inside. Run the Sigma/KQL/VQL content above and the bash verification script on every Atlassian host covering at least the last 30 days. Any JVM-spawned shell, unexpected JSP, or anomalous egress connection from an Atlassian node is a full IR engagement: isolate, preserve memory and disk, rotate all credentials the host could reach (database passwords in dbconfig.xml, LDAP bind accounts, API tokens, app passwords).
  4. Reduce exposure as a compensating control. If patching must be staged, immediately restrict Jira/Confluence access to authenticated internal users or VPN ranges at the load balancer/WAF. Block or alert on the vulnerable request patterns per the vendor advisory. There is no legitimate business reason for Confluence to be anonymously internet-reachable.
  5. Egress filtering. Atlassian servers have minimal legitimate reasons to initiate outbound internet connections beyond Atlassian marketplace/license endpoints. Deny-by-default egress from these hosts neuters the payload-staging step of most exploitation chains.
  6. Rotate credentials post-remediation on any exposed instance. Assume the service account, connected directory credentials, and stored tokens were accessible to the attacker during the exposure window.
  7. Review installed apps/plugins. Malicious apps installed via the Universal Plugin Manager are a known persistence mechanism on compromised Atlassian hosts — audit the installed app list for anything unrecognized.

The pattern here is one we've seen repeat across every actively exploited Atlassian flaw in recent years: exploitation begins within hours of disclosure, and internet-facing instances are scanned en masse. The defenders who fare best are the ones who treat "critical + in the wild + internet-facing" as a same-day action, not a ticket in a queue.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.