How do you patch or mitigate CVE-2022-26138 (Atlassian Questions For Confluence App Hard-coded Credentials)?

CISA’s required action for CVE-2022-26138 is to apply updates per vendor instructions. In practice, find every instance of Atlassian Confluence in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2022-26138 means for patching Atlassian Confluence

This issue is not just a routine software update. It is a hard-coded credential flaw in an Atlassian Confluence app, so the practical question is whether your estate contains the affected app, whether any exposed instance can still be reached, and whether attacker access may already have been established. Treat the fix as both a remediation task and a compromise check.

Because CISA directed organisations to apply vendor updates, the first step is to confirm exactly where the Atlassian Questions for Confluence app is installed and whether the vendor fix or documented mitigation can be applied cleanly in each environment. For an inventory-driven response, use the CISA Known Exploited Vulnerabilities Catalog alongside the vendor advisory, and map every Confluence deployment before you change anything.

When patching is possible, prefer the vendor update over ad hoc compensating controls, because hard-coded credentials usually fail in more than one place at once. A patch removes the unsafe trust relationship, while a mitigation only reduces the chance that the exposed credential can be reached or abused. If you need a broader response pattern for exploited flaws, the Zero-Day and Exploited Vulnerabilities Guide is useful for deciding when to patch immediately, when to isolate, and when to hunt first.

How to reduce exposure if the fix cannot go in immediately

If you cannot apply the vendor update right away, focus on reducing reachability and limiting the blast radius. Remove direct internet exposure, place the application behind tighter access controls, and consider taking the product out of service if you cannot prevent untrusted access. For a Confluence environment, that often means treating external accessibility as the highest-priority risk, not as a convenience issue.

Mitigation should also include credential hygiene around the app itself. Hard-coded secrets tend to be reused, copied, or embedded into adjacent workflows, so you should look for any related API keys, service credentials, or automation tokens that may have been exposed by the same flaw. The Guide to the Secret Sprawl Challenge is a relevant internal reference for understanding how hard-coded credentials spread beyond the original vulnerable component.

For Atlassian environments specifically, the Atlassian Cloud Security Guide is useful when you need to review surrounding permissions, integrations, and admin exposure around Confluence and related Atlassian services. Even when the flaw sits in a marketplace app, the operational risk usually extends into the wider tenant or instance configuration.

What to check after patching or containment

After the update or mitigation is in place, assume the issue may already have been used in the wild and review logs for abnormal access, suspicious administrative activity, new accounts, unusual plugin behaviour, or outbound activity from the Confluence host. The point is not only to prove the patch worked, but to determine whether the vulnerable credential was already used before the fix landed.

This is where post-remediation hunting matters most. If the application was reachable from the internet, or if logs show authentication attempts tied to the app before you contained it, treat the environment as potentially compromised and expand your review to adjacent systems that may have received delegated access. The Vulnerability Management Guide is helpful for structuring that verification work, especially when remediation and compromise assessment need to happen together.

Once you have contained the exposure, rotate any credentials that could plausibly have been touched by the vulnerable app, and invalidate sessions or tokens where the app was acting on behalf of users or service functions. If evidence suggests the flaw was abused, the safest assumption is that related trust material may also need renewal, not just the plugin itself.

Risk and Threat Considerations

Hard-coded credentials create a direct trust failure, because anyone who can discover or reuse the embedded secret may be able to authenticate without normal user oversight. In an exposed Confluence environment, that can turn a plugin weakness into a broader application compromise, especially if the app has access to content, administration functions, or connected systems.

Failure mechanism: The vulnerable app contains fixed authentication material that cannot be safely issued, rotated, or scoped like a normal secret, so compromise of the app or its code path can expose access that defenders may not notice until after use.

Impact: Attackers may obtain unauthorized access, move into adjacent Atlassian services or connected integrations, and leave little evidence if the credential was treated as trusted by design.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue requires finding and remediating an actively exploited vulnerability across the estate.
Recommendation — Prioritise exposure discovery, remediation tracking, and verification for every Confluence instance.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The response depends on identifying affected instances and verifying remediation after exposure.
	SI-2 — Flaw Remediation	CVE-2022-26138 is a flaw-remediation case where vendor updates or mitigations must be applied.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch log review is needed to check for earlier exploitation.
Recommendation — Scan for all Confluence deployments and confirm the vulnerable app is removed or updated. Apply the vendor update or approved mitigation and validate the corrected configuration. Review logs for signs of prior abuse after containment and patching.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The subject is an exploitable software vulnerability requiring coordinated remediation and verification.
Recommendation — Track, assess, and remediate the vulnerable Atlassian app through formal vulnerability handling.

Practitioner Guidance

What to prioritise: Start with exposure reduction, then patching, then log review. If the instance is internet-facing, containment should move ahead of convenience or low-severity change windows.

What to verify: Confirm the exact app version and deployment path in every Confluence instance, then verify that the vendor fix or mitigation was actually applied and that no alternate copy of the app remains active.

Decision rule: If you cannot patch promptly and cannot confidently restrict exposure, take the affected instance out of service rather than relying on hope that the hard-coded secret has not been found.

Practitioner takeaway: With hard-coded credential flaws, the remediation question is inseparable from compromise assessment, because a successful fix can still leave you with an already-abused trust path.