① When the safest fix is to switch it off 

PHP is the programming language behind a large share of the world's websites, including every WordPress site. On 21 October its developers fixed two critical flaws that let an attacker take control of a web server without logging in. The security firm Calif found the first flaw in August, using an OpenAI model in a code audit that OpenAI funded. Wiz, another security firm, later found the flaws independently with AI tools. 

Details leaked online before the planned disclosure. ASD's Australian Cyber Security Centre (ACSC) issued a critical alert before the fix was out, and overnight the ATO, Health and ACMA websites were disrupted, along with ASD's own cyber.gov.au. For several hours, ASD's full statement on the flaw would not load. ASD said some organisations had taken sites offline as a precaution, and agencies in the Netherlands and Finland did the same. Industry Minister Tim Ayres said: "This isn't a breach." 

Whether attackers are exploiting the flaws is contested. The security firm watchTowr reports exploitation against its decoy servers since 21 October, while ASD said it was not aware of active exploitation. Older versions of PHP, still common on legacy systems, will get no official fix. 

So what for business leaders 

Most organisations have rehearsed restoring a service after an outage. Fewer have rehearsed the decision to switch one off. This month several governments judged that taking public websites offline was safer than leaving them exposed, and made that call within hours, before full details were public. The ABC reported that ASD urged organisations to put security ahead of keeping services available. 

That is a business decision, not an IT one, because both choices harm someone. Switching off a customer portal, booking system or online store stops customers paying bills, making appointments or getting help, and some customers have no other way to reach the organisation. Switching off also costs revenue, breaks service commitments and draws public attention. Leaving the service running may expose those same customers' data instead. Even ASD paid a price: while cyber.gov.au was down, organisations could not easily read the advice they needed. If nobody has agreed in advance who may weigh these harms, and on what evidence, the organisation will either lose hours finding the right person or leave a technician to decide alone. 

Questions worth asking: 

• Who has the authority to take a customer-facing service offline for security reasons at 2am, and has that person ever practised the call? 

• For our most important online services, do we know who would be hurt by a day offline, including customers with no other way to reach us, and which services we would switch off first? 

• How quickly could we tell customers why a service had gone dark and where else to turn, without the message being read as a breach notice? 

So what for tech and cyber leaders 

The first problem many teams hit was finding PHP. It runs in obvious places such as WordPress and Drupal sites, but also inside vendor appliances, management consoles, hosting control panels and marketing sites that an agency built and nobody in IT owns. The UK National Cyber Security Centre told organisations to watch for updates from suppliers, "including for appliances and services that may bundle PHP". An inventory that lists applications but not the runtimes underneath them cannot answer that question quickly. End-of-life runtimes deserve their own line on the risk register: PHP 7.3 and older will never be fixed, so the only remedies are upgrade, isolation or shutdown. 

The second lesson is to build the off switch before you need it. A tested way to put a site behind a blocking WAF rule, or replace it with a static page that tells customers where else to go, makes the availability decision reversible within minutes. Tiering services in advance, by what can safely go dark and what customers cannot do without, saves the argument at 2am. The trade-off is real: precautionary shutdowns have a cost, and a team that pulls the plug on every critical alert will soon lose the support to do it.

Sources: PHP security advisory, CVE-2026-109618 and CVE-2026-109619 · ABC News live blog, 22 October · The Canberra Times · NCSC · watchTowr · The Next Web 

② The breach report that went to a researchers' inbox

On 18 June, an AI agent running in OpenAI's internal testing reached an old Services Australia website that publishes Medicare statistics. When the site refused it, the agent found a way around the block and retrieved public and non-public files, including unpublished aggregate statistics. The Prime Minister said it did not appear that anyone's personal Medicare details were accessed.

OpenAI found the activity on 11 August while reviewing what it called "misaligned model activity". On 10 September it reported the incident by emailing a public mailbox that academics and researchers use to report weaknesses. Services Australia read the email the next day and told ASD on 15 September. The Prime Minister announced the incident on 24 September after calling OpenAI's chief executive to express "extreme concern", and set up a taskforce to review it. OpenAI said its models "took actions we did not intend".

So what for business leaders

Cutting through Cyber Issue 4 asked who is accountable when an AI agent oversteps. This story raises a quieter question: how a warning reaches the people who can act on it. Most of the three-month delay sat with OpenAI. But the report itself arrived in a researchers' mailbox, from a company with no contract with the government, and then had to travel through an agency, ASD, ministers and the Prime Minister's office.

Breach warnings increasingly come from outside: researchers, journalists, suppliers, AI providers and sometimes attackers. They arrive in shared inboxes, social media messages and account managers' phones. If nobody has mapped the route from first report to accountable executive, the organisation's notification obligations may start running before anyone senior knows they exist.

Questions worth asking:

• If a supplier or researcher reported a problem in our systems tomorrow, where would the message land, and how long would it take to reach an executive who can act? 

• Has anyone tested that route by sending a report through it and timing the result

• Do our contracts with technology and AI suppliers require them to tell us promptly when their tools have touched our systems or data?

So what for tech and cyber leaders

Two lessons transfer well beyond AI. First, publish a vulnerability disclosure channel and staff it. A security.txt file (RFC 9116) on each public domain tells finders where to report, but it helps only if the address routes to a monitored queue with triage and an escalation threshold, not a mailbox someone checks weekly.

Second, the agent got in through an old website that still held non-public files. Legacy portals and retired sites often rely on obscurity or bot blocking rather than authentication. Robots.txt, bot rules and rate limits slow automated visitors down; they do not stop one persistent enough to look for a way around them. Non-public data on an internet-facing system should sit behind real authorisation, or not be there at all. And an incident discovered months later can be investigated only if the logs still exist, so check that retention on low-priority web assets covers that window.

Sources: ABC News, 24 September · Pinsent Masons

③  When the adviser across the table may be on the other side

Ransomware victims usually hire a specialist negotiator to deal with the criminals, often a firm their insurer directs them to. On 19 October, KrebsOnSecurity reported that federal investigators suspect executives at two negotiation firms of unusually close ties to the ShinyHunters extortion group. Sources told Krebs that one US executive helped run a website that pressured nearly 100 victim organisations to pay. That executive has not been named or charged.

Separately, a prominent Canadian ransomware negotiator was arrested in Pennsylvania this month on US federal extortion charges. The complaint is sealed, the allegations are untested, and authorities have not confirmed a link to ShinyHunters.

The concern has precedent. In July a US court sentenced a former ransomware negotiator to 70 months in prison. According to the US Department of Justice, the BlackCat ransomware group paid him for confidential information about his clients' negotiating position and strategy, which helped the group extract larger payments.

So what for business leaders

A ransom negotiator sees more of an organisation's crisis than almost anyone outside it: what the attackers took, what the business can afford, what the insurance will cover and how much pressure the board is under. A compromised adviser in that seat is more dangerous than an open adversary, because nobody is watching them.

The way organisations choose these advisers makes the risk harder to see. Many victims accept the firm their insurer directs them to, in the first hours of an incident, with no time for checks. Some negotiators charge a percentage of the ransom paid, which rewards a bigger payment even when everyone acts honestly. None of this means negotiators as a group are untrustworthy. It means the choice deserves the due diligence any other privileged supplier would get, done before the crisis rather than during it.

Questions worth asking:

• Who chooses our incident response and negotiation advisers, and what checks have we done on them before we need them?

• How are those advisers paid, and does the fee structure reward a higher ransom?

• Who knows our insurance limits and the most we would pay, and how much of that do we share with outside advisers?

So what for tech and cyber leaders

Incident responders and negotiators usually get the access an attacker would most like: EDR consoles, privileged credentials, backups and the full picture of what was stolen. Treat them as a privileged third party, with the controls you would apply to any other. Agree the retainer and onboarding before an incident, with your insurer's approval where the policy requires it, so the first hours go on responding rather than contracting. Give responders named, time-limited accounts separate from your break-glass credentials, log their activity as you would any administrator's, and revoke the accounts when the engagement ends. Within the response team, apply need-to-know to the most commercially sensitive facts, such as policy limits and the maximum the business would pay; the technical team rarely needs them. The trade-off is speed: controls on responders add friction at the moment you most want help, which is why the setup belongs in peacetime.

Sources: KrebsOnSecurity · US Department of Justice · iTnews

④ Fifty dollars a break-in 

Reuters reported on 19 October that a single Chinese-speaking hacker used AI agents to attack more than 1,200 websites from late September, targeting e-commerce sites in the US, Canada, Australia and Japan. Snorre Fagerland, a researcher at the security firm NorForge, found the campaign by scanning the internet for exposed copies of the open-source agent platform the hacker used. He estimates the agents broke into more than 100 companies' sites for about US$5,000 in AI usage, roughly US$50 per successful break-in, with each typically taking around 23 hours of automated probing.

Reuters confirmed several victims, including Deere, SharkNinja and Cummins. SharkNinja said the breach hit a standalone product-support site, and Cummins said it was investigating a report about a website run by one of its suppliers. Reuters could not establish how much data was taken, and Deere said it had no indication that sensitive information was accessed.

So what for business leaders

In the latest Cutting through with KSIB newsletter, Steve argued that attacker economics have changed: many organisations were safe only because nobody had found them, and AI makes finding them cheap. This campaign puts a price on that shift. At about US$50 a break-in, the economics favour trying everything.

It also shows where the attempts succeed. The named victims are large, well-resourced companies, and the reported entry points were peripheral: a product-support site, a supplier's website, an administration panel. Systems like these often sit outside the main security program because they seem unimportant, yet they carry the company's name and sometimes connect to more important systems. The useful question for leaders is not whether the business is a target, but how much of its online presence anyone is watching.

Questions worth asking:

• How many websites and online services carry our name, including those built and run by agencies and suppliers, and who is responsible for the security of each?

• If one of our minor sites were compromised this week, would we find out from our own monitoring or from someone outside?

So what for tech and cyber leaders

Measure your attack surface the way the attacker now does: by everything reachable, not by what is in the CMDB. Continuous discovery of domains, subdomains, cloud-hosted assets and vendor-run sites under your brand is now a baseline control, because an agent will find the forgotten staging site whether or not you have. Administrative and control panels deserve particular attention. They should not be reachable from the internet at all, or should sit behind SSO with phishing-resistant MFA or an identity-aware proxy. The 23 hours of probing per intrusion is also an opportunity. Automated attacks are persistent and noisy, so alerting on sustained, unusual request patterns against low-value sites, not only the crown jewels, can catch them before they succeed. The same agents are available to defenders, and running them against your own perimeter is cheaper than learning about the gaps from someone else.

Sources: Reuters, via BNN Bloomberg · The Next Web

 ⑤ The 72-hour clock is coming for privacy breaches 

On 31 August, the Attorney-General's Department released an exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, the second tranche of Privacy Act reform. Among about 40 proposed changes, the draft would require organisations to notify the Office of the Australian Information Commissioner (OAIC) of an eligible data breach within 72 hours of becoming aware of reasonable grounds to believe one has occurred. Affected individuals would be told at the same time where practicable.
Today, an organisation that suspects a breach has up to 30 days to assess it before the duty to notify applies. Consultation closed on 18 September. The draft is not law, and the department says the Bill remains subject to further consideration by government.

So what for business leaders
Seventy-two hours is becoming the standard clock for Australian cyber incidents. Ransomware payments must already be reported to ASD within 72 hours, and APRA-regulated entities must notify APRA of material information security incidents within 72 hours. If the draft passes, privacy breaches would join them.
The trigger matters more than the number. The clock would start when the organisation has reasonable grounds to believe a breach has occurred, not when the investigation finishes and not when the news reaches the board. Story ② shows how long that journey can take. In practice, the decision to notify moves from the end of an investigation to the middle of it, and leaders will have to decide on incomplete facts and update later.

Questions worth asking:

• If the clock started at the first credible report, could we decide whether to notify within three days, and who would make that call?

• Have we mapped every notification obligation we carry, to regulators, insurers and customers, into one decision process, or does each sit with a different team?

So what for tech and cyber leaders
The hard part of a 72-hour notification is not writing the notice. It is scoping: establishing which systems were touched and whose personal information they held. That depends on two things many organisations discover they lack mid-incident. The first is a data inventory that maps systems to the categories of personal information they hold, so that "which customers were in that database?" takes hours rather than weeks. The second is logging retained long enough, and protected well enough, to show what was accessed, because breaches are often discovered weeks or months after they began. Run at least one tabletop in which the clock starts from an external tip rather than an internal alert, since that is where time is most often lost. The trade-off is notifying on partial facts. The draft allows updated information later, but an early notice that overstates or understates the breach carries its own legal and reputational risk, so legal, privacy and security teams need an agreed approach before the clock starts.

Sources: Attorney-General's Department consultation · Lander & Rogers · McCullough Robertson