Five things from the past working week that a UK board should know about, in the order I would raise them with a chair over coffee on Monday morning. It was a week of stolen access rather than clever exploits: a login, a leaked password, an unpatched collaboration server, a certificate nobody should have been able to obtain. I have left out the noise. What survives has a decision attached.

1. ASOS was breached through a third party, and customers found out from their own phones

On 6 October, ASOS customers received a push notification through the retailer's own app from a group calling itself Xuanye Group, claiming to have stolen customer data and demanding contact. TechCrunch reported that ASOS confirmed the breach in a London Stock Exchange filing, and that the attackers claim to have compromised data hosted on Snowflake. ASOS says an intruder impersonated a trusted contact to obtain an employee's credentials, then used them to reach third-party platforms. ASOS says names and contact details were exposed, and that payment card details and passwords were not. It has not said how many of its roughly 17 million customers are affected.

For boards. The attacker did not need to break anything; one employee was persuaded. Ask where your customer data sits outside your own estate, whether every one of those platforms enforces multi-factor authentication, and who can send a message to your customers in your name. If the answer to the last question is a third-party vendor, you have a second front door.

2. The FBI says FortiBleed is still being used to get ransomware crews inside

The FBI warned this week that attacks stemming from FortiBleed are ongoing. The leak exposed credentials tied to more than 73,000 Fortinet firewall URLs; SOCRadar now counts 86,644 compromised devices. Per the FBI, attackers log into exposed FortiGate firewalls and SSL VPN gateways with leaked or sprayed credentials, take authentication data off the device, crack it offline, then create their own admin accounts and lock the real administrators out. The bureau names INC/Lynx and Payload ransomware affiliates among those using the route, and warns that patching and resetting passwords may not be enough on their own.

For boards. This is a credential problem on a security appliance, so a clean patch report tells you nothing. Ask whether your FortiGate administration is reachable from the internet, whether MFA is enforced on it, and whether anyone has reviewed it for administrator accounts nobody remembers creating.

3. Atlassian's critical flaw was being probed within two hours of a public exploit

Atlassian disclosed CVE-2026-21589 on Monday 5 October: an unauthenticated file-read flaw across self-hosted Data Center versions of Confluence, Jira, Bitbucket, Bamboo, Crowd and others. watchTowr published a technical write-up and proof of concept; Previdian's honeypots recorded exploitation attempts within two hours. In Jira deployments integrated with Crowd, attackers can read plaintext credentials from a configuration file and use them to create an administrator account.

For boards. The gap between disclosure and exploitation is now measured in hours. Ask whether you run self-hosted Atlassian, who owns patching it, and whether it is reachable from the internet at all. If it holds source code and internal documentation, treat it as a crown-jewel system.

4. Citrix has another NetScaler flaw, and this time there is no sign of exploitation yet

Two weeks ago I wrote about the NetScaler zero-days. This week Citrix published CVE-2026-107406, a memory overflow permitting remote code execution or a crash, affecting appliances configured as a SAML identity provider or service provider. Citrix says it has no evidence of in-the-wild exploitation. Fixed builds are 14.1-73.46 and 13.1-64.29 or later, per Citrix's advisory.

For boards. "Not yet exploited" is the cheapest moment to patch. Having been caught out last time, ask your team how many days it took them to patch the previous NetScaler flaw, and whether this one will beat it.

5. Attackers hijacked country-code domains and obtained real certificates for Google's

Google blocked fraudulent certificates in Chrome after attackers compromised operators of the .gh, .sl and .as country-code domains, redirected DNS, and passed certificate authority checks for domains they did not own. Google says certificate transparency logs revealed other global brands were also affected, and that it may not have found them all. Google's own account notes protection outside Chrome is not reliable. Nothing I found says .uk was involved.

For boards. Your brand can be impersonated with a valid padlock without your systems being touched. Ask whether you monitor certificate transparency logs for your domains, and what your registrar and registry lock arrangements are.

The thread that ties this together

None of the five required a novel technique. Stolen credentials, a leaked password list, a public proof of concept, a trusted-looking request: each succeeded because somebody else's door was left on the latch, whether a vendor, an appliance, or a registry. Your assurance reporting probably describes your own estate well, and everything beyond it badly.

Which of your most important systems can be reached today using nothing but a stolen password?