CVE-2022-26138 is a questions for app hard-coded credentials vulnerability in Atlassian Confluence. CISA added it to the Known Exploited Vulnerabilities catalogue on 29 July 2022, which means attackers have used it in real attacks. Atlassian Questions For Confluence App has hard-coded credentials, exposing the username and password in plaintext.
What the vulnerability means in practice
This CVE is dangerous because hard-coded credentials turn a software flaw into a ready-made access path. When usernames and passwords are embedded in plaintext, anyone who can inspect the app, its files, or related deployment artifacts may inherit the same access the vendor intended for the application itself.
That pattern is especially damaging in collaboration and content-management products because the compromised credentials can be reused to reach sensitive spaces, administrative functions, or connected systems. For the underlying vulnerability class, the security problem is not just “exposed secret,” but the collapse of trust between the application and the protected environment.
Use the vendor advisory and the CVE Program or NVD for authoritative record details, then confirm whether the affected app is present in your environment and whether it was deployed in a way that exposed its secrets.
How to assess exposure
Exposure review starts with an asset inventory, because the first question is whether the Atlassian Questions for Confluence app is installed anywhere. From there, check whether the deployment package, source repository, container image, or configuration files reveal embedded credentials, and whether the host or plugin was reachable in an exposed environment.
Because this is an exploited vulnerability class, organisations should also treat internet-facing instances and externally reachable admin interfaces as higher priority. A hard-coded credential may be discovered through static inspection, but its practical impact depends on where the app runs and what the embedded account can access.
Pair that inventory work with vendor advisories and KEV monitoring so you are not relying on guesswork about whether the flaw is present or whether it has been weaponised. CVE records and vendor notes are the right sources for version and remediation specifics.
Remediation and compensating controls
The remediation objective is to remove the embedded secret and replace it with a proper secret-management pattern. In practice, that usually means rotating the exposed credential, replacing plaintext storage with managed secrets, and removing any design that hard-wires authentication material into code or packaged assets.
When an immediate change is not possible, reduce the blast radius by restricting the account’s privileges, limiting where the service can connect from, and blocking unnecessary inbound exposure. Hard-coded credentials are dangerous partly because they are durable, so compensating controls should assume the secret may already be known.
The most useful mental model is that a credential embedded in application logic is not merely a configuration issue, it is an identity and access failure. The Secret Sprawl Challenge explains why secret exposure and credential sprawl create repeated compromise paths, while Secrets Management Guide covers the shift toward centralised secrets and away from embedded credentials.
Detection and post-exposure review
After a disclosure or suspected exploitation, review authentication logs, application access logs, and any upstream identity or proxy telemetry for use of the exposed account. A hard-coded credential often leaves few obvious traces at the point of exposure, so defenders need to infer misuse from downstream logins, unusual access patterns, or unexpected configuration changes.
Post-patch review should also confirm that the vulnerable credential was actually invalidated. If the secret was reused anywhere else, a patch alone does not end the incident because the attacker may still have a valid route into related systems.
For the same reason, organisations should review whether the compromised account was used for more than one integration. API Key Management Guide is useful here because the operational lesson is the same: exposed credentials must be rotated, revoked, and checked for reuse wherever they were embedded.
Risk and Threat Considerations
Hard-coded credentials are high-value targets because they shortcut normal authentication controls and can survive for long periods in code, images, backups, and deployment artifacts. Once discovered, they can enable direct access, privilege abuse, or lateral movement without the attacker needing to defeat the product’s normal login flow.
Failure mechanism: The embedded secret is reused outside its intended trust boundary, so anyone who finds it can authenticate as the application or its associated account and operate with whatever permissions that account has.
Impact: The result can include data exposure, administrative access, service manipulation, and persistence through any other system that trusts the same credential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of credentials exposed by hard-coded authentication material. |
| AC-6 — Least Privilege | Limits damage if the hard-coded credential is abused for access. | |
| Recommendation — Rotate exposed credentials and replace embedded secrets with managed authenticator lifecycle controls. Reduce the compromised account’s permissions to the minimum required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Applies to credential inventory, rotation, and revocation for exposed application accounts. |
| Recommendation — Inventory the affected account and revoke or replace any exposed access path. | ||
| OWASP ASVS | V6 — Authentication | Directly addresses insecure credential handling and authentication weaknesses in applications. |
| Recommendation — Verify that the application never ships plaintext credentials or hard-coded login material. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Maps directly to plaintext secret exposure in non-human application credentials. |
| Recommendation — Eliminate embedded secrets and move them into managed secret storage. | ||
Practitioner Guidance
Why practitioners should care: Treat hard-coded credentials as an identity compromise pattern, not just a code-quality defect. The practical question is whether the exposed account can reach anything sensitive, because that determines how far the blast radius extends.
What to watch for: Any plugin, integration, or automation that stores usernames or passwords in source, binaries, configuration bundles, or shared documentation deserves immediate review. If the same secret appears in more than one place, assume it will be reused and plan rotation accordingly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org