Self-managed Confluence is one of the most exploited collaboration platforms on the internet, and a single unauthenticated flaw has repeatedly handed attackers administrator accounts, server code execution and every page in the wiki. CISA's Known Exploited Vulnerabilities catalogue lists nine Confluence vulnerabilities, seven of them marked as known to be used in ransomware campaigns, plus a 2026 flaw affecting several Atlassian Data Center products. Confluence also stores the passwords, runbooks and API keys that teams paste into pages. This guide covers Confluence Data Center specifically: global permissions and the administrators super group, personal access tokens and integration accounts, audit logging, a hardening baseline and the end-of-life timeline that now shapes every plan. It is for Confluence administrators, infrastructure teams and security engineers. Atlassian's hosted service is covered in the Atlassian Cloud Security Guide, and the controls differ substantially.
Key takeaways
- Patching speed is the primary control. CVE-2022-26134 and CVE-2023-22515 were exploited as zero-days; an internet-facing Confluence that patches monthly is not defended.
- The confluence-administrators group sees everything. Members can open restricted pages; use a separate group with the System Administrator global permission and keep the super group almost empty.
- Personal access tokens default to no expiry. Set atlassian.pats.eternal.tokens.enabled to false and lower the maximum lifetime before integrations multiply.
- Audit coverage is configurable and per node. Raise coverage for security areas and ship each node's JSON audit file and the access logs to a separate system.
- Data Center has an end date. Atlassian's published end of life for Confluence Data Center is 28 March 2029, after which no security fixes are provided; plan migration or isolation now.
How identity and access work in Confluence Data Center
Confluence Data Center authenticates users against its internal directory, an external LDAP or Active Directory directory, Atlassian Crowd or Jira as a user server, and optionally SAML or OpenID Connect single sign-on through the built-in SSO 2.0 feature. Authorisation then flows through three layers.
| Layer | Examples | What it controls | Security note |
|---|---|---|---|
| Global permissions | Can Use, Personal Space, Create Space(s), Browse All Group Members, Confluence Administrator, System Administrator | Who can log in, create spaces and reach the admin console | Can Use granted to a broad directory group gives every directory account a login |
| Space permissions | View, Add, Delete, Export, Restrict, Admin per user, group or anonymous | What a user can do inside one space | Space admins can grant anonymous access to their space once global anonymous access is on |
| Page restrictions | View and edit restrictions on a page and its children | Narrowing access below the space level | Do not protect members of confluence-administrators, who can open restricted pages by URL |
- Prefer SSO with MFA at the identity provider: Atlassian's best practice is to integrate with an identity provider for single sign-on and two-factor authentication, enable two-step verification for local users, and then disable basic authentication for both login and REST requests.
- Manage leavers in the directory: disable accounts when people leave. Atlassian notes that deleting a user anonymises the name, which affects audit history, so disabling is usually the better default.
- Control anonymous access and public signup: both are set in the admin console Security Configuration. Leave them off for internal wikis and review space permissions for the anonymous user whenever a public space exists.
Admin roles and privileged access
| Privilege | What it grants | Recommendation |
|---|---|---|
| System Administrator (global permission) | Full admin console including Backup & Restore, System Information, Mail Queue, Scheduled Jobs, Logging and Profiling, Clustering | Grant to a small dedicated admin group of separate admin accounts |
| Confluence Administrator (global permission) | Subset of the console: users, groups, SSO 2.0, most general and security configuration; excludes backup, system information and jobs | Use for support staff who manage users and spaces |
| confluence-administrators group | All admin functions, all spaces and all pages including view-restricted ones; cannot be edited or deleted | Keep membership to one break-glass account; System Administrators do not need it |
| Space Admin | Permissions, restrictions and settings for one space | Review quarterly in spaces holding sensitive content |
- Separate admin accounts: Atlassian recommends each administrator has one account for daily work and another for administration, with no shared accounts and no guessable usernames such as "admin". The initial installation account is a member of confluence-administrators: rename or disable it once named admin accounts exist.
- Secure administrator sessions: keep the setting on so administrators re-enter their password before admin functions, with a short timeout.
- Restrict the admin interface by network: Atlassian gives an Apache example that limits the administration interface to specific IP addresses, and notes it can serve as a template for any reverse proxy. See the Proxies and Forward vs Reverse Proxy Security Guide.
- Treat new admins as an incident signal: the CVE-2023-22515 advisory lists unexpected members of confluence-administrators and unexpected new users as indicators of compromise.
- Protect the server and database tiers: run Confluence as a dedicated non-root OS user, restrict access to the installation, home, attachment and export directories, and give the database user only the privileges Confluence needs, reachable only from the Confluence nodes.
Integrations, API tokens and service accounts
Integrations reach Confluence Data Center through the REST API, application links to Jira and other Atlassian products, and Marketplace apps that run inside the Confluence JVM. Each path carries a credential or trust relationship that outlives the project that created it.
Personal access tokens
Confluence 7.9 and later support personal access tokens (PATs), sent as Authorization: Bearer headers. A PAT carries the permissions of the user who created it, so a token created by an administrator is an administrator credential. Atlassian recommends PATs instead of basic authentication for integrations. Administrators control them through JVM system properties.
| System property | Default | Hardened value |
|---|---|---|
| atlassian.pats.enabled | true | true (or false if no integrations use the REST API) |
| atlassian.pats.eternal.tokens.enabled | true (tokens without expiry allowed) | false |
| atlassian.pats.max.tokens.expiry.days | 365 | 90 or less for user tokens |
| atlassian.pats.max.tokens.per.user | 10 | Lower for normal users, tracked for service accounts |
| atlassian.pats.expiry.warning.days | 5 | Long enough for owners to rotate before expiry |
| atlassian.pats.pruning.delay.days | 30 | Default is acceptable |
- Use dedicated integration users: create a non-human account per integration, grant only the spaces it needs, never add it to administrator groups, and create its PAT from that account. Record an owner and purpose.
- Review the token list: administrators can list every token with author, creation, expiry and last-used time and can bulk revoke. Revoke tokens unused for 90 days and those owned by leavers.
- Do not paste tokens into pages: Confluence content is a common hiding place for credentials. Scan it with a secrets scanner and move findings to a vault. See the Atlassian API Tokens Security Guide and the Secrets Management Guide.
Application links and Marketplace apps
- Application links: links to Jira or Bitbucket let one product act on another. Remove unused links and review which accounts the linked application can impersonate.
- Marketplace apps: apps run with Confluence's own privileges. The KEV entry CVE-2022-26138 was a hard-coded account created by the Questions for Confluence app that let an unauthenticated attacker log in with confluence-users group access. Keep an app inventory, remove apps nobody owns and include apps in patching.
- Outbound allowlist: Atlassian recommends enabling the allowlist for incoming and outgoing connections to reduce server-side request forgery risk from macros, gadgets and integrations.
Credentials harvested by infostealers are a realistic path into self-managed Atlassian tools: in the Schneider Electric Jira breach the attacker reported logging in with exposed credentials and pulling about 400,000 rows through a plugin REST API.
Logging and detection
Confluence Data Center records security events in the audit log, with coverage set per area to Off, Base, Advanced or Full. The database copy is retained for three years by default on new installations (20 years on migrated sites) up to 10 million records. Each cluster node also writes JSON audit files to <home-directory>/log/audit, keeping 100 files by default, intended for tools such as Splunk, ELK or CloudWatch. Atlassian also recommends monitoring the access logs in the installation directory.
| Source | What to look for | Related technique |
|---|---|---|
| Audit log: users and groups | New users, additions to confluence-administrators or admin groups, global permission changes | T1136 Create Account, T1078 Valid Accounts |
| Audit log: apps | App installed, enabled or updated outside a change window | T1505 Server Software Component |
| Audit log: security configuration | Anonymous access, public signup, SSO or basic authentication changes | T1078 Valid Accounts |
| Access logs and reverse proxy | Requests to /setup/*.action or /server-info.action from the internet; exploit-style payloads in URLs | T1190 Exploit Public-Facing Application |
| atlassian-confluence-security.log | Login failures, setupadministrator.action exceptions | T1110 Brute Force |
| Host and EDR telemetry | The Confluence Java process spawning shells, new JSP files, unexpected outbound transfers | T1505.003 Web Shell, T1567.002 Exfiltration to Cloud Storage |
| REST API usage | High-volume page or space exports by a single user or token | T1213.001 Confluence |
The joint CISA, FBI and MS-ISAC advisory on CVE-2023-22515 described attackers creating administrator accounts through the setup endpoint and then exfiltrating content with cURL and Rclone. It recommends forwarding Confluence application and server logs to a separate, logically isolated system and searching for unauthorised administrator accounts. See the Web Shell Response Playbook for the host side of an investigation.
Hardening baseline
| Area | Control | Why |
|---|---|---|
| Exposure | Keep Confluence off the internet or behind a VPN, ZTNA or authenticating reverse proxy | Most KEV entries are unauthenticated and pre-auth |
| Patching | Subscribe to Atlassian security advisories; apply critical fixes within days, run a supported Long Term Support release | Zero-day exploitation of 26134 and 22515 |
| Emergency mitigation | When the advisory offers one (for example blocking /setup/* for CVE-2023-22515), apply it at the proxy until the upgrade | Buys time, does not replace the upgrade |
| TLS | Terminate TLS at the proxy or Tomcat connector; set the base URL to HTTPS | Protects sessions and tokens in transit |
| Authentication | SSO 2.0 with the IdP enforcing MFA; disable basic authentication for login and REST; strong password policy for local accounts | Stops password replay and infostealer reuse |
| Brute force and abuse | Rate limiting for REST, including blocking anonymous REST requests; Fail2Ban or proxy rate limits on login | Atlassian best practice |
| Admin access | Secure administrator sessions, admin paths restricted by IP, separate admin accounts, minimal super group | Limits the value of a stolen session |
| Tokens | Disable eternal PATs, lower maximum expiry | Bounds credential lifetime |
| Host | Dedicated non-root service account, restricted directory permissions, monitored binaries, EDR on nodes | Limits post-exploitation reach |
| Database | Least privilege database user, network access only from Confluence nodes | Protects the content store |
| Logging | Advanced or Full coverage for security areas; ship node audit files and access logs off host | Evidence survives attacker cleanup |
Phased rollout
- Exposure check: confirm the version, whether the instance is reachable from the internet and which KEV entries apply; patch first.
- Compromise check: review confluence-administrators membership, recent new users, installed apps and access logs for setup endpoint requests before trusting the instance.
- Admin model: create the System Administrator group with separate admin accounts, empty the super group, enable secure administrator sessions.
- Authentication: enable SSO 2.0 for a pilot group, then all users; keep one local break-glass admin; then disable basic authentication.
- Tokens and integrations: set the PAT properties in the JVM arguments on every node, create integration users, revoke stale tokens and remove unused apps and links.
- Logging: raise audit coverage, forward node files and access logs, build the detections above.
Testing and rollback: make PAT and SSO changes in a staging node first; PAT system properties need a restart and must be identical on every cluster node. Keep the break-glass local admin so a broken SSO configuration can be reverted from the admin console, and keep the previous JVM argument set to restore if integrations fail.
Plan for end of life
Atlassian's published schedule ends Data Center sales to new customers on 30 March 2026, ends expansions for existing customers on 30 March 2028 and ends life for Confluence Data Center on 28 March 2029, with critical security fixes until then. After that date instances become read-only and receive no security fixes, and Atlassian advises against keeping a read-only instance connected to the internet. A small organisation will usually migrate or export and archive; a large or regulated one that must stay self-managed should negotiate any extension early and plan network isolation for the archive (NIST SP 800-53 SA-22 Unsupported System Components).
Common misconfigurations
- Internet-facing Confluence patched on a normal cycle: CVE-2023-22527, CVE-2023-22518 and CVE-2023-22515, all from a four-month period, are each flagged in the KEV catalogue as used in ransomware campaigns.
- Everyday admin accounts in confluence-administrators: a phished administrator exposes every restricted HR, security and legal page.
- Basic authentication left on after SSO: scripts and attackers bypass the IdP and its MFA with stolen passwords.
- Non-expiring PATs created by administrators: a leaked token is a permanent admin credential.
- Unowned Marketplace apps: apps that nobody patches, including ones that create their own accounts as CVE-2022-26138 showed.
- Logs only on the node: an attacker with code execution can delete the evidence the advisories tell you to search.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Patching and KEV tracking | SI-2, RA-5, SA-22 | ID.RA-01 | 7 | A.8.8 |
| Admin groups and global permissions | AC-2, AC-6, AC-6(5) | PR.AA-05 | 5, 6 | A.8.2 |
| SSO, MFA and PATs | IA-2, IA-5 | PR.AA-01 | 6 | A.5.17, A.8.5 |
| Network exposure and allowlist | SC-7, AC-17 | PR.IR-01 | 12, 13 | A.8.20, A.8.22 |
| Audit and access logs | AU-2, AU-6, AU-9 | PR.PS-04, DE.CM-09 | 8 | A.8.15, A.8.16 |
Detection and measurement
- Patch latency: days from an Atlassian critical advisory to production upgrade (target: under seven days for internet-reachable instances).
- Super group size: members of confluence-administrators (target: one break-glass account).
- Token hygiene: PATs without expiry, PATs older than 90 days and PATs unused for 90 days.
- Authentication coverage: share of logins through SSO and number of REST calls still using basic authentication.
- App inventory: installed Marketplace apps without a named owner or behind on updates.
Practitioner checklist
- Check the running version against every Confluence entry in the CISA KEV catalogue and patch.
- Remove direct internet exposure or put an authenticating proxy in front of Confluence.
- Review confluence-administrators, new users and installed apps for signs of past compromise.
- Move administrators to separate admin accounts in a System Administrator group and enable secure administrator sessions.
- Enable SSO 2.0 with MFA at the IdP, then disable basic authentication for login and REST.
- Set atlassian.pats.eternal.tokens.enabled=false and a lower maximum PAT expiry on every node.
- Create owned integration users, revoke stale tokens and remove unused apps and application links.
- Raise audit coverage and forward node audit files and access logs to a separate system.
- Decide the migration, extension or archive plan for the 28 March 2029 end of life.
Standards and references
- Atlassian: Best Practices for Configuring Confluence Security
- Atlassian: Global Permissions Overview
- Atlassian: Using Personal Access Tokens
- Atlassian: Auditing in Confluence
- Atlassian: CVE-2023-22515 Security Advisory
- CISA, FBI and MS-ISAC: AA23-289A Threat Actors Exploit Atlassian Confluence CVE-2023-22515
- CISA: Known Exploited Vulnerabilities Catalog
- Atlassian: Data Center End of Life
Related NHI Mgmt Group resources: Atlassian Cloud Security Guide · Atlassian API Tokens Security Guide · CISA KEV Catalogue Guide · Web Shell Response Playbook · Bitbucket Security Guide