In July 2022, Atlassian disclosed CVE-2022-26138, a vulnerability that was almost too simple to believe. The Questions for Confluence app — an Atlassian Marketplace plugin used for Q&A functionality — created a user account with a hardcoded password when installed. The account had access to all non-restricted pages in Confluence. The password was the same on every installation. Once the credential was extracted from the app's code and published online, every Confluence instance with the app installed was immediately compromised.
The Vulnerability
When the Questions for Confluence Cloud Migration app (versions 2.7.34 and 2.7.35) was installed or enabled on a Confluence Server or Data Center instance, it created a user account called disabledsystemuser with a specific hardcoded password. This account was added to the confluence-users group, giving it access to all pages that were accessible to logged-in users.
The account was intended to help with data migration between Confluence Server and Confluence Cloud. But the implementation was fundamentally flawed:
- The password was hardcoded in the app's source code
- The password was identical across all installations
- The account was not disabled or removed after migration was complete
- The account had the same access as any regular Confluence user
Once the hardcoded password was reverse-engineered from the app package and posted online, any attacker could log into any Confluence instance that had the app installed. No exploit required. Just a username and password.
Why This Is Worse Than It Sounds
Confluence is where organizations store their most sensitive internal documentation:
- Architecture diagrams and network topologies
- Runbooks and operational procedures
- Internal policies and compliance documentation
- Project plans and roadmaps
- Meeting notes and decision records
- API documentation and credentials
- Incident response playbooks
Many organizations also store credentials, API keys, and connection strings in Confluence pages. A quick search for "password," "API key," or "credentials" on most Confluence instances will return results that would make any security team cringe.
Access to Confluence doesn't just expose documents — it provides an attacker with a complete map of the organization's technology stack, business operations, and security practices. This is reconnaissance gold.
The Timeline
- June 2022: Atlassian privately notifies affected customers and begins working on a fix
- July 20, 2022: Atlassian publishes advisory for CVE-2022-26138
- July 21, 2022: The hardcoded password is published on Twitter
- July 22, 2022: Active exploitation attempts are detected in the wild
- July 22, 2022: CISA adds CVE-2022-26138 to its Known Exploited Vulnerabilities catalog
The speed of exploitation was predictable. This wasn't a vulnerability that required exploit development or sophisticated tooling. It was a username and password that anyone could use.
The Remediation Confusion
Atlassian's remediation guidance added to the confusion. Simply uninstalling the Questions for Confluence app did not remove the disabledsystemuser account. The account persisted after uninstallation, meaning organizations that thought they were safe because they'd removed the app were still vulnerable.
The actual remediation required:
- Disabling or deleting the
disabledsystemuseraccount manually - Checking for any other accounts that might have been created with similar privileges
- Reviewing access logs for authentication events from the compromised account
- Assessing whether any data was accessed or exfiltrated during the exposure window
Atlassian provided a script to check for the presence of the account and instructions for manual removal. But many organizations didn't realize the account still existed after uninstalling the app.
A Confluence Vulnerability Pattern
CVE-2022-26138 came during a period of frequent critical Confluence vulnerabilities:
- CVE-2021-26084 (September 2021): OGNL injection in Confluence allowing unauthenticated RCE, widely exploited by cryptominers and ransomware operators
- CVE-2022-26134 (June 2022): Another OGNL injection RCE in Confluence, exploited as a zero-day
- CVE-2023-22515 (October 2023): Broken access control allowing unauthenticated admin account creation
- CVE-2023-22518 (October 2023): Improper authorization allowing data destruction
This pattern made Confluence one of the most frequently targeted enterprise applications, second perhaps only to Microsoft Exchange. Each vulnerability provided unauthenticated access to an application containing an organization's most sensitive internal knowledge.
Hardcoded Credentials: A Persistent Problem
CVE-2022-26138 is far from the only hardcoded credential vulnerability in enterprise software. This class of bug persists because:
Development convenience: Developers hardcode credentials during development and forget to remove them. In the case of the Questions for Confluence app, the hardcoded account was likely a quick solution for a migration requirement that wasn't reconsidered from a security perspective.
Testing artifacts: Test accounts with known passwords are created during QA and inadvertently included in production builds.
Default credentials in appliances: Many software appliances ship with default admin credentials that customers don't change. While not technically hardcoded, the effect is the same.
Third-party libraries and plugins: Even if the core product is secure, plugins and extensions from the marketplace may introduce hardcoded credentials. Organizations rarely audit marketplace apps with the same rigor as the core product.
Defensive Recommendations
1. Audit Confluence Accounts Regularly
Maintain an inventory of all user accounts in Confluence and review them periodically. Accounts that don't correspond to actual users — especially system or service accounts — should be investigated and removed if not needed.
2. Restrict Confluence Network Access
Confluence should not be directly accessible from the internet unless absolutely necessary. If external access is required, use a VPN or zero-trust network access solution with strong authentication.
3. Evaluate Marketplace Apps Carefully
Before installing any Atlassian Marketplace app, assess its security posture. Check the developer's track record, review the app's permissions, and consider whether the functionality justifies the additional attack surface.
4. Monitor Authentication Events
Log and monitor all authentication events in Confluence. Logins from unexpected accounts, unusual IP addresses, or at unusual times should trigger alerts. The disabledsystemuser account should never have been authenticating to Confluence, and monitoring would have caught exploitation quickly.
5. Implement Least Privilege for Confluence Pages
Not every page in Confluence should be accessible to every authenticated user. Use Confluence's space permissions and page restrictions to limit access to sensitive information. Even if an attacker gains access through a compromised account, restricted pages remain protected.
How Safeguard.sh Helps
Safeguard.sh addresses the security risks posed by enterprise collaboration platforms and their ecosystems:
- Plugin and Extension Tracking: Safeguard.sh inventories all installed plugins and extensions, including Atlassian Marketplace apps, tracking their versions and known vulnerabilities.
- Credential Exposure Detection: Safeguard.sh scans for hardcoded credentials and default accounts across your software inventory, identifying vulnerabilities like CVE-2022-26138 before attackers discover them.
- Continuous Vulnerability Monitoring: Safeguard.sh tracks the rapid pace of Confluence CVE disclosures, ensuring you're aware of new vulnerabilities the moment they're published.
- SBOM-Driven Risk Assessment: By maintaining SBOMs for your deployed applications and their plugins, Safeguard.sh provides a complete picture of your exposure to known vulnerabilities.
CVE-2022-26138 was a reminder that the simplest vulnerabilities can be the most damaging. A hardcoded password in a third-party plugin gave attackers the keys to corporate knowledge bases worldwide. Safeguard.sh ensures these oversights are caught before they're exploited.