FortiBleed and the Atlassian flaw: why your internet-facing systems need an owner, not just a patch

Two security stories from the past week look different on the surface. One is a long-running credential campaign against Fortinet firewalls. The other is a freshly patched flaw in Atlassian's self-hosted products. They share a lesson that is easy to miss: the systems facing the internet are where attackers start, and "we patched it" is only part of being safe.

FortiBleed: the problem is credentials, not a bug

On 6 October the FBI and US Secret Service issued a joint advisory saying the FortiBleed campaign remains active. It targets internet-facing FortiGate firewalls and SSL VPN gateways. Citing SOCRadar's figures, the advisory puts confirmed compromised devices at more than 86,000 across 194 countries. SOCRadar describes this as a count of confirmed compromises, not an estimate of exposure.

According to Infosecurity Magazine and Help Net Security, the method is mundane. Attackers scan for exposed VPN portals and try credentials from earlier leaks and infostealer logs, using credential stuffing and password spraying. They also pull password hashes from compromised devices and crack them on a GPU cluster. Once inside, they enumerate Active Directory accounts and look for privileged users. The agencies link the access to ransomware affiliates associated with the INC, Lynx and Payload groups.

The detail that matters most is persistence. Attackers create new administrator accounts on the firewall and, in some cases, delete or change the original accounts, locking owners out. The advisory says recovery may need more than patching and password resets. A researcher quoted by Infosecurity Magazine worried most about attackers who want to live quietly inside an organisation for as long as possible.

Atlassian: hours, not weeks

Meanwhile, Atlassian patched CVE-2026-21589, a critical arbitrary file access flaw in its self-managed Data Center products, including Jira, Confluence, Bitbucket, Bamboo and Crowd. Help Net Security reports that watchTowr published its technical analysis within hours of the patch, and honeypot operator Previdian saw exploitation attempts that same night.

There are limits worth stating. Atlassian says an attacker needs to know the exact file name and path, and cannot list directories. But some files are well known, and in Crowd-integrated deployments a credentials file could let an attacker manage users and groups, including adding accounts to Jira administrator groups. Reporting differs on whether a full exploit was published, so treat the precise exposure with caution and read Atlassian's own advisory for your version.

What the two stories have in common

• The window between disclosure and attack keeps shrinking. A monthly patch cycle does not match an attack timeline measured in hours for internet-facing systems.
• Patching does not evict someone already inside. A device can be fully up to date and still hold attacker-created accounts.
• Stolen credentials are as dangerous as vulnerabilities. A VPN without strong multi-factor authentication is exposed even when the software is current.
• Nobody owns the edge. Firewalls, VPNs and self-hosted collaboration tools often sit between IT, a vendor and a team that set them up years ago.

Practical steps

1. List everything internet-facing: firewalls, VPN gateways, self-hosted Jira, Confluence and similar tools. Name an owner for each.
2. Require phishing-resistant MFA on remote access and on administrator accounts, as the advisory recommends.
3. Restrict management interfaces so they are not reachable from the open internet.
4. Audit administrator accounts on firewalls and VPNs. Look for accounts nobody can explain, and for changes to existing ones.
5. End active admin and VPN sessions and reset credentials if you have any doubt, then review firewall, VPN, authentication and domain controller logs for lateral movement.
6. Decide your emergency patch rule in advance: who can approve an out-of-cycle change for a critical, internet-facing flaw, and how quickly.
7. If you run Atlassian Data Center, upgrade to a fixed version, and if you cannot do it quickly, restrict external access and review access logs for signs of abuse, as Atlassian advises.
8. Check your exposure to infostealers. Staff devices with stolen saved passwords are how reused credentials end up in the next leak.

None of this is exotic. It is inventory, ownership and identity hygiene. An independent review of your external footprint and remote access controls can show where the gaps are before an attacker does. If you suspect compromise, follow the advisory's guidance and report to the relevant authorities.

The takeaway: patching is necessary, but it answers only one question. The better one is whether you know what is exposed, who owns it and whether anyone else already holds the keys.

Sources: Help Net Security, "FortiBleed is still active, with attackers locking admins out of Fortinet firewalls"; Infosecurity Magazine, "FBI and Secret Service Warn of FortiBleed Lockout Threat"; Help Net Security, "Exploitation attempts against critical Atlassian flaw have begun (CVE-2026-21589)".