CVE-2022-26138: Atlassian Questions Auth Bypass Vulnerability

CVE-2022-26138 Overview

The Atlassian Questions For Confluence app for Confluence Server and Data Center contains a critical hardcoded credentials vulnerability. When installed, the app creates a Confluence user account in the confluence-users group with the username disabledsystemuser and a hardcoded password. A remote, unauthenticated attacker with knowledge of the hardcoded password can exploit this vulnerability to log into Confluence and access all content accessible to users in the confluence-users group.

Critical Impact
This vulnerability allows unauthenticated attackers to gain full access to Confluence content by exploiting hardcoded credentials. CISA has added this vulnerability to the Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild.

Affected Products

Atlassian Questions For Confluence versions 2.7.34, 2.7.35, and 3.0.2
Atlassian Confluence Server (when running affected app versions)
Atlassian Confluence Data Center (when running affected app versions)

Discovery Timeline

2022-07-20 - CVE-2022-26138 published to NVD
2026-01-14 - Last updated in NVD database

Technical Details for CVE-2022-26138

Vulnerability Analysis

This vulnerability falls under CWE-798 (Use of Hard-coded Credentials), a configuration and design flaw that represents a fundamental security anti-pattern. The Questions For Confluence app automatically creates a system user account during installation with predictable, static credentials that are embedded in the application code. This means every installation of the affected app versions creates identical credentials, making them trivially exploitable once the hardcoded password becomes public knowledge.

The vulnerability is particularly severe because it requires no prior authentication or special privileges to exploit. An attacker simply needs network access to the Confluence instance and knowledge of the hardcoded credentials to authenticate as the disabledsystemuser account. Once authenticated, the attacker inherits all permissions granted to the confluence-users group, which typically includes read access to a significant portion of organizational content.

Root Cause

The root cause is the intentional creation of a user account with static, hardcoded credentials during the app installation process. The account disabledsystemuser was created with a password embedded directly in the application code, violating fundamental secure development practices. This design decision removed the security boundary that credentials are supposed to provide, effectively creating a backdoor that exists on every affected Confluence installation.

Attack Vector

The attack vector is network-based and requires no user interaction or prior authentication. An attacker can exploit this vulnerability by:

Identifying a Confluence instance running an affected version of the Questions For Confluence app
Navigating to the Confluence login page
Authenticating with the username disabledsystemuser and the publicly known hardcoded password
Gaining access to all content available to the confluence-users group

The vulnerability can be exploited remotely through standard authentication mechanisms, making it a straightforward attack path. No sophisticated exploitation techniques or special tools are required—only knowledge of the credentials and network access to the target system.

Detection Methods for CVE-2022-26138

Indicators of Compromise

Successful authentication events for the disabledsystemuser account in Confluence audit logs
Unusual access patterns or content downloads associated with the disabledsystemuser account
Login attempts from unexpected IP addresses or geographic locations for this system account
Presence of the disabledsystemuser account in the Confluence user database

Detection Strategies

Review Confluence access logs for any authentication attempts using the disabledsystemuser username
Implement alerting on successful logins from the disabledsystemuser account, which should not be used for interactive access
Query the Confluence user database to identify if the disabledsystemuser account exists
Monitor for bulk content access or export operations performed by system accounts

Monitoring Recommendations

Enable detailed audit logging in Confluence to capture all authentication events
Configure SIEM rules to alert on authentication events involving disabledsystemuser
Implement network monitoring to detect connections to Confluence from untrusted sources
Establish baseline user activity patterns to identify anomalous access from system accounts

How to Mitigate CVE-2022-26138

Immediate Actions Required

Immediately disable or delete the disabledsystemuser account from your Confluence instance
Update the Questions For Confluence app to a patched version
Review Confluence audit logs for any evidence of unauthorized access via this account
Conduct a security review of content accessed by the disabledsystemuser account to assess potential data exposure

Patch Information

Atlassian has released security patches addressing this vulnerability. Organizations should update the Questions For Confluence app to the latest available version. Detailed remediation guidance is available in the Atlassian Security Advisory and the Atlassian Jira Issue CONFSERVER-79483.

Note that uninstalling the Questions For Confluence app does not automatically remove the disabledsystemuser account. The account must be manually disabled or deleted even after uninstallation.

Workarounds

Manually delete or disable the disabledsystemuser account in the Confluence administration panel
If the account cannot be deleted, change the password to a strong, randomly generated value and disable the account
Implement network-level controls to restrict access to Confluence from trusted networks only
Enable multi-factor authentication (MFA) for all Confluence user accounts where supported

bash

# Check for the disabledsystemuser account in Confluence
# Navigate to: Administration > User Management > Users
# Search for: disabledsystemuser
# If found, select the account and choose "Delete" or "Deactivate"

# Alternative: Use Atlassian CLI or REST API to query and disable the account
# Example API endpoint to search for the user:
# GET /rest/api/user?username=disabledsystemuser