How to Rotate Every Secret an Arbitrary File-Read Bug Could Have Exposed

A pre-authentication file-read vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. like Atlassian CVE-2026-21589 forces an uncomfortable assumption: if the flaw was reachable before you patched, any secret stored at a predictable path inside the affected application may already be in someone else's hands. Patching closes the hole. It does nothing about the credentials that leaked through it while it was open. This is the runbook for the second half of the job, rotating every secret the bug could have exposed, in an order that does not lock you out or miss anything.

Start by Deciding Scope

You cannot rotate what you have not listed. Before touching anything, build the exposure set: every secret that lived in a file an attacker could have read on an affected, reachable instance.

Enumerate the affected systems first. Because this class of flaw often sits in a shared library, one bug can touch several products at once, which is exactly what happened across the Atlassian suite and why we recommend reading why a flaw in one shared library means patching eight products at once. For each instance, ask one question: was it reachable by an attacker during the exposure window, between the flaw existing and the patch landing. If you cannot prove it was isolated, treat it as exposed.

Then inventory the secrets on those instances. Walk the application's configuration and web root for anything sensitive: integration and service-account passwords, database connection strings, API keys and tokens, signing and encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. keys, SMTP and LDAP bind credentials, and any shared secret used to trust another system. The credentials behind the Atlassian takeover were an integration password sitting in a properties file; assume your own stack has equivalents. For why those files are such a reliable target, see our explainer on how a config-file read turns into account takeover.

Rotate in Dependency Order

The failure mode of credential rotation is rotating a secret two systems depend on and taking both offline. Sequence the work so that does not happen.

First, the highest-leverage secrets: any credential that can create accounts, grant privileges, or authenticate as the application to an identity provider. In the Atlassian case that is the directory-integration password, because it was the pivot to administrator. Rotate these first and, while you are there, tighten their scope so the replacement cannot do more than the component actually needs.

Second, standing access that an attacker could use for persistence: API tokens, personal access tokens, OAuthOAuth🛡️An open standard authorization protocol that allows applications to access user resources without exposing passwords, using tokens instead of credentials. client secrets, and SSH keys stored on the host. Revoke the old values rather than only issuing new ones. A new token does not help if the old one still works.

Third, the supporting secrets: database passwords, SMTP and service credentials, and internal shared keys. For each, change the value at the source of truth, update every consumer, then invalidate the old value. Do it one dependency chain at a time so a mistake is contained to one service.

Invalidate Sessions and Hunt for Persistence

Rotating a password does not evict an attacker who already authenticated. If the leaked credential could have been used to log in or mint a session, invalidate active sessions and tokens for the affected systems, and force re-authentication.

Then look for what they left behind. Audit for new or modified privileged accounts, unexpected members of administrator groups, new API tokens or integrations, and changes to authentication configuration. The Atlassian chain ended in a freshly created administrator, so an unexplained admin account or group change is the signal that matters most. This is the same evidence-first instinct we describe for appliances in our guide to hunting your web server logs for path-normalization evasion, applied to identity instead of traffic.

Prove It and Write It Down

Close the loop by confirming the old secrets are dead. Where you can, test that a revoked token or password is actually rejected rather than assuming the rotation propagated. Watch for breakage from consumers you forgot, which is the normal way rotations go wrong, and fix the inventory rather than reinstating the old secret.

Record what you rotated, when, and why, including the exposure window you assumed. That record is what lets you answer the compliance and incident questions that follow a disclosure, and it feeds the next cycle: secrets you had to rotate under pressure are the ones to move into a secrets manager and put on an automatic rotation schedule, so the next pre-auth read finds short-lived values instead of a static jackpot.

The Short Version

Patching stops the bleeding; rotation is the treatment. Scope the exposure honestly, list every secret in reach, rotate from most to least privileged in dependency order, kill sessions, hunt for the persistence the leak may already have bought, and verify the old credentials no longer work. For the vulnerability that prompted this runbook and the attacks already exploiting it, see our news report on Atlassian CVE-2026-21589.