CVE-2022-26138: Atlassian Questions for Confluence hard-coded password, actively exploited
The short version: Certain versions of Atlassian's Questions for Confluence app create a hidden account — disabledsystemuser — with a hard-coded password that has since been made public (CVE-2022-26138). Any unauthenticated attacker who knows it can log in and read everything the confluence-users group can. It's in CISA's KEV catalog, and uninstalling the app does not remove the account. Remediate directly. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — trivial, unauthenticated access with a publicly known password |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~98.17% · 99.91th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2022-08-19 |
| Known exploited? | Yes — hard-coded password disclosed publicly; CISA-listed as exploited |
| Vulnerability type | CWE-798 use of hard-coded credentials → unauthenticated Confluence access |
| Requires authenticated session? | No — the credential is built in and public |
| Affected | Questions for Confluence 2.7.34, 2.7.35, 3.0.2 (on Confluence Server / Data Center) |
| Fixed in | Questions for Confluence 2.7.38 (for Confluence 6.13.18–7.16.2) · 3.0.5 (for Confluence 7.16.3+) |
What you need to know
When affected versions of the Questions for Confluence app are installed, they create a Confluence account named disabledsystemuser, place it in the confluence-users group, and set a hard-coded password. That password was subsequently disclosed publicly — at which point the account became an open door: a remote, unauthenticated attacker can log in and access every non-restricted page the confluence-users group can reach.
The traps that make this one linger:
- Uninstalling the app doesn't fix it. The
disabledsystemuseraccount is not removed when you uninstall Questions for Confluence — you have to remove or disable the account, or upgrade to a version that removes it. - You can be affected without the app "installed" now. If a vulnerable version ever created the account, it may still be present.
- There's a tell. The account is configured with the email address
[email protected], which is not controlled by Atlassian.
How serious we see it
High — about as low-effort as unauthorized access gets.
There's no exploit chain and no cleverness required: a built-in account, a password anyone can look up, and access to Confluence content. It's in KEV, and the impact is a straightforward confidentiality breach of your wiki — often full of exactly the internal information attackers want. The reassuring part is that remediation is fast and entirely in your hands: upgrade the app or remove the account, then verify it's gone.
Recommendations
Straight from Atlassian's advisory and CISA:
- Remediate the account now — pick one:
- Upgrade the app to Questions for Confluence 2.7.38 or 3.0.5 (fixed versions stop creating the account and remove it if present), or
- Disable or delete the
disabledsystemuseraccount directly (required if Confluence uses a read-only external directory such as Crowd).
- Do not rely on uninstalling the app — that leaves the account in place.
- Check whether it was ever used. If the last authentication time for
disabledsystemuseris non-null, investigate; review SMTP logs for mail sent to[email protected]. - In a cluster, apply the fix on every node.
- Confirm your exposure first. Search your user list for
disabledsystemuser/[email protected].
How BreachRisk sees it
BreachRisk discovers internet-facing Confluence Server and Data Center instances from little more than your domain, fingerprints the product, and flags exposure tied to KEV-listed vulnerabilities like this one — surfaced at the top of your results because it's in KEV.
That continuous, outside-in view is the point: an exposed Confluence with a publicly known built-in password is exactly the kind of finding you want mapped and ranked, so you can close the account before someone simply logs in.