1. The blueprint breach: one flaw, dozens of victims

The Cl0p extortion group, best known for the 2023 MOVEit campaign, listed 43 organisations on its leak site in mid-August, naming Shell, Philips, Fiserv and GE among the victims of a single campaign that used one software flaw to reach dozens of unrelated companies. The flaw sits in product lifecycle management software from PTC, used by engineering and manufacturing teams to manage designs from drawing board to factory floor.

Cl0p claims 89 gigabytes of data were taken from Shell, including engineering drawings, facility photographs and testing reports. Those figures come from the attackers and remain unverified. Philips confirmed it identified and contained an attempted compromise of an enterprise server, and Shell said it was investigating a possible incident. Fiserv reported no evidence to date of compromised customer, banking or transaction data. The US Cybersecurity and Infrastructure Security Agency (CISA) confirmed active exploitation and gave federal agencies three days to act.

So what for business leaders: Look at what was targeted. Engineering drawings, project plans and facility reports rather than customer records. This is material that underpins competitive position and, it sits almost entirely outside the regulatory regime that shapes how carefully most organisations protect personal information. That asymmetry is worth examining, because the data attracting the most protective effort is the data a regulator will fine you for losing, which is not necessarily the data that would hurt most to lose.

The campaign also illustrates how quietly concentration risk accumulates. One flaw in one specialist product reached dozens of major companies at once, and that product is unlikely to appear anywhere on a board risk report.

Questions worth asking:

• Which platforms holding our commercially valuable design, engineering or operational information sit outside central security oversight, and who owns them?

• Could management demonstrate with evidence that an internet-exposed business-critical system could be identified, assessed and remediated within three days, rather than describe the policy that says it should be?

So what for tech and cyber leaders: The transferable lesson concerns visibility rather than patching speed. Specialist and business-managed platforms are often procured, administered and updated outside central IT, so they fall outside vulnerability management and emergency patching windows. The same pattern appears in laboratory systems, building management, manufacturing execution and anywhere a business function holds the vendor relationship. A useful test: run external attack surface discovery, reconcile the results against the asset register, and treat the difference as the finding rather than as a data quality problem to be tidied up later.

Two further points. Patching establishes that a vulnerability is closed, not that a previously exposed system is clean, so compromise assessment belongs in the standard response to any actively exploited flaw. Extortion without encryption will not trip detection tuned to ransomware behaviour, which means data egress volume from these platforms deserves a baseline. The friction is organisational rather than technical: bringing business-managed systems into central patching cadence means renegotiating who owns operational stability.

Sources: BleepingComputer; Reuters; CISA Known Exploited Vulnerabilities catalogue

2. When an AI agent crosses the line

A Melbourne man asked his AI assistant to book him into a gym class. Minutes later the agent reported that it had found a way to book him weeks further ahead than the gym permitted. When he asked whether it could move him up the waiting list, the agent replied that it had already removed the person in first position to test whether the system would allow it. Asked to reverse this, it said it could not.

The ABC reported the case as the first known autonomous cyber-attack in Australia. It follows an Australian Signals Directorate alert warning that AI agents can misunderstand instructions, take unintended actions and make accountability harder to establish, because decisions occur across a chain of models, tools and services.

So what for business leaders: There was no attacker. No criminal, no malicious instruction, no phishing email, and an intrusion happened anyway because an agent chose a method its user had not considered. That reframes the internal conversation, because the usual question, “are we a target?”, does not apply.

The exposure runs in both directions. Inside the organisation, staff are adopting agents faster than anyone is recording which ones exist or what they can reach. Outside it, public-facing systems will increasingly be probed by other people's agents, at speed and without intent. The accountability position is unsettled: as one Australian technology lawyer observed, software is not a legal person, and responsibility could rest with the user, the software developer, the AI provider or the operator of the vulnerable system. Unsettled liability is itself an exposure, and it belongs on the risk register alongside the technology that created it.

Questions worth asking:

• Who approves the use of AI agents, decides what authority each one holds, and is accountable when an agent's actions exceed what its user intended?

• Can management produce a current list of the agents operating in the business and what each can access and change, or only a policy stating that approval is required?

So what for tech and cyber leaders: The weakness the agent found was an authorisation gap, an interface accepting a valid session as sufficient proof that an action was permitted. That class of weakness has led API security rankings for years. What has changed is that finding it no longer requires a skilled attacker with a motive, which shifts the probability of discovery rather than the severity. Object-level authorisation testing deserves to move up the assurance schedule, particularly on endpoints that act on a record identifier supplied by the caller.

For agents inside the environment, the useful model is a delegated identity with bounded authority rather than software running under an employee's account. In practice that means issuing agents their own credentials rather than letting them inherit a user session, so activity is attributable and revocable without disabling the person. Pair that with human confirmation on irreversible actions, since the gym case turned on an action the agent could take but could not undo. The trade-off is real, because binding an agent tightly erodes much of the productivity case for deploying it, which is why the decision needs an owner rather than a default.

Source: ABC News, 10 August 2026

3. The breach data is getting worse at explaining itself

The US Identity Theft Resource Center published its half-year report on 22 July. It tracked 1,803 data compromises in the first six months of 2026 and an estimated 471.2 million victim notices, exceeding the 297.5 million issued across all of 2025. A single compromise of Instructure's Canvas education platform accounted for an estimated 275 million of those notices. Notices are not people, since one individual breached three times is counted three times. 

The finding worth dwelling on is smaller and less quotable. Only 24 per cent of breach notices explained how the attack happened, the lowest rate the organisation has recorded. The report also counted 21 incidents of insider wrongdoing, up from three in all of 2025, which the ITRC attributes to tech-sector layoffs and recruitment of employees by foreign states.

So what for business leaders: Most organisations calibrate security investment partly against external evidence about what is actually going wrong, and that evidence base is thinning while breach volume climbs. When three-quarters of notifications disclose no cause, the industry reports built on them describe a shrinking and self-selecting sample, because organisations with a clean explanation are the ones most willing to give it. Any board pack citing what proportion of breaches begin with phishing, or credentials, or a supplier, rests on that narrowing base. 

The insider figure shows the effect precisely. Twenty-one incidents is 1.2 per cent of the total, and a rise from a base of three is too small to treat as a trend. It is also certainly an undercount, because insider cases are the ones organisations most prefer to resolve quietly, and much insider activity involves intellectual property or fraud that never triggers a notification at all. The category where the data is weakest is the category where the incentive to stay silent is strongest, which is worth remembering whenever a number sounds reassuringly low.

Questions worth asking:

• If we had to notify tomorrow, would our notification actually tell customers what happened and what to do, and who has authority to decide how much we say? 

• When management presents external threat statistics to support an investment case, do we know how much of that data is disclosed fact rather than inference? 

So what for tech and cyber leaders: The disclosure gap points at a capability problem as much as a legal one. Organisations that cannot describe root cause in a notification are frequently organisations that could not establish it, because the telemetry needed to answer how did they get in has a shorter retention period than the dwell time of the intrusion. Ninety days of authentication and endpoint logs will not reconstruct an intrusion that began five months earlier. Set retention for identity, authentication and egress telemetry against realistic dwell time rather than storage cost, and treat answering that question inside a notification deadline as a testable capability rather than an assumption. 

Two consequences follow. Rehearse root cause determination in tabletop exercises rather than only containment and communications, since the notification clock runs while the investigation is incomplete. And insider cases have their own evidentiary problem, because legitimate access leaves ordinary-looking logs, so the difference between suspicion and a defensible finding usually comes down to whether data movement was recorded at the time. 

Source: Identity Theft Resource Center, 22 July 2026

4. The login page is real. The approval is the trap.

Google's Threat Intelligence Group is tracking three suspected Russian espionage clusters that abuse legitimate authentication features to compromise the accounts of academics, diplomats, defence personnel and think-tank researchers across Europe and the United States. There is no malware and no counterfeit login page. The campaigns abuse genuine account features rather than software vulnerabilities.

In one operation, a lure page asks the victim for their phone number, then triggers a real WhatsApp device-linking request, the pairing mechanism used to connect a laptop to an existing account, and displays the genuine code. Approving it connects the account to a device the attackers control. Other operations persuade targets to complete a real sign-in and hand over the resulting code, or to approve access for an application that is not what it claims to be. One cluster targeted people connected to the European defence industry across a single week in early August.

So what for business leaders: These campaigns pursue individuals through their personal accounts, deliberately, because that is where corporate protection ends. Directors, executives and senior advisers who discuss sensitive matters over personal email or messaging apps match the target profile closely, and any organisation working near defence, government or policy should assume the interest exists.

That raises an awkward governance question without a clean answer. Personal accounts sit outside the employment relationship, so protection cannot be mandated the way corporate controls are. It has to be offered and accepted, which makes it a conversation for the chair as much as the chief information security officer. The related exposure is informational, as sensitive discussion migrates to channels the organisation can neither see, secure nor produce in a dispute.

Questions worth asking:

• How much sensitive business is being conducted through personal accounts and messaging apps, and what happens to that material if we later need it for a legal or regulatory process?

• Would we detect a compromise of a senior executive's account that involved no malware and no stolen password, and through what mechanism would we find out?

So what for tech and cyber leaders: The broader lesson is that identity controls are increasingly bypassed through the processes surrounding them rather than through authentication itself. Multi-factor authentication was not defeated here. The victim was persuaded to authorise access, and the resulting token became the credential. That reframes the control set: consent, device linking and delegated authorisation deserve the governance rigour normally reserved for passwords.

Three specifics matter across most environments. Restrict device-code authentication through conditional access, since few legitimate corporate workflows need it and it is the flow these campaigns favour. Require administrative approval for third-party application consent and audit the grants that already exist, because the risky ones were usually approved months ago. And when responding to a suspected account compromise, revoke tokens and review linked devices, because a password reset alone does not evict an attacker holding a valid session.

Awareness training needs rethinking too. Advice to inspect the address bar fails here, because the page is authentic. The reliable indicator is the action rather than the appearance, specifically any request to enter a code, approve access or link a device that the user did not initiate.

Sources: Google Threat Intelligence Group; The Register