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. The theme this week is delegated trust — to a vendor, to an AI agent, to an embedded app, to an OAuth token — and in every case the delegation is where the attacker went to work. I have left out the noise. What survives has a decision attached.

1. A critical F5 BIG-IP flaw is already being exploited, and it sits behind your VPN

On 22 September, F5 published an advisory for CVE-2026-94127, a CVSS 9.8 heap-based buffer overflow in BIG-IP Access Policy Manager. An unauthenticated attacker who can reach a vulnerable virtual server can achieve remote code execution when APM is configured as an OAuth authorisation server — a common setup wherever BIG-IP is doing double duty as the front door for VPN and single sign-on. CISA added the flaw to its Known Exploited Vulnerabilities catalogue the same day, giving US federal agencies three days to patch under its binding directive.

F5 has shipped hotfixes for the 17.1, 17.5 and 21.1 branches, and an iRule workaround is available through support for anyone who cannot patch immediately.

For boards. BIG-IP sits at the edge of the network, which is exactly where you do not want a zero-day. Ask whether your APM instances use OAuth authorisation server mode, and if so, whether the hotfix has already been applied — not scheduled, applied. "It's on the list for next patch window" is not an acceptable answer for a flaw that is already being used against real targets.

2. Revolut's third-party trail is now the story, not Revolut's own systems

On 25 September, Revolut customers learned they were caught up in a second data exposure in a month, after attackers used a "sophisticated social engineering campaign" to get into US brokerage DriveWealth, which had historically handled US stock trading for Revolut's customers before the relationship wound down between December 2023 and June 2025. The exposed data — names, addresses, phone numbers, employment details, partial account numbers — was old, but regulatory retention rules meant DriveWealth still held it.

It follows an entirely separate incident on 14 September, in which Revolut handed sensitive customer data, including passport images and verification selfies, to criminals who had spoofed a legitimate government agency's email domain. Revolut's own infrastructure was not compromised in either case.

For boards. Two incidents, two attackers, two routes in — neither of them Revolut's own network. If your organisation still has data sitting with a former processor, ask when that data is due to be deleted and who is accountable for chasing it. And test whether your own staff would recognise a fraudulent information request that arrives from what looks like a genuine government domain, because that is the exact trick that worked here.

3. Salesforce's AI agents could be told what to do by your own customers

On 24 September, AI agent security firm Zenity Labs disclosed three vulnerabilities, collectively named SalesBleed, in Salesforce's Agentforce platform. An attacker could plant a prompt injection inside a public Web-to-Lead form; when an employee later asked their Agentforce assistant to "check my latest leads," the agent would quietly query the Accounts table and exfiltrate customer data via a DNS request disguised as an image tag — no click required. A related flaw let the same poisoned lead hijack the agent's Slack identity to send phishing messages that appeared to come from a trusted internal source.

Zenity reported the issues in June and confirmed all three fixed by 21 September. The attack chains no longer work. The pattern does.

For boards. This is not a Salesforce problem so much as an agent-design problem: any AI agent that reads content submitted by outsiders, renders links back to a user, and holds access to sensitive data has the same three ingredients in the same place. Ask which of your AI agents meet that description, and whether anyone has actually tried to break them rather than just configure them.

4. Microsoft and the Met dismantled an AI phishing service built like a product

On 22 September, Microsoft's Digital Crimes Unit disrupted EvilTokens, a phishing-as-a-service platform linked to more than 12,000 compromised inboxes across 10,000-plus organisations since February. EvilTokens abused the OAuth device-code sign-in flow — the same mechanism behind "enter this code on your other device" prompts — to obtain authenticated sessions without ever needing a victim's password. Its most notable feature was an AI chatbot that read a compromised inbox, mapped internal relationships and payment authorisations, and told the criminal exactly which conversation to hijack.

The Metropolitan Police arrested two men, aged 32 and 38, on 11 September; Microsoft's court-authorised takedown, run with Cloudflare, Coinbase and others, followed on the 22nd, seizing 50 sites and disabling 150 more.

For boards. Device-code phishing defeats password hygiene and, in some configurations, multi-factor authentication too, because the victim is asked to approve a legitimate-looking sign-in rather than hand over credentials. Ask your security team whether device-code flow is disabled by default in your tenant, and if it must stay on for some use case, who is watching for it being abused.

5. A whisky retailer's four-day breach came through an app it didn't build

Online retailer Master of Malt began notifying customers this week after Ribon, a third-party app connected to its BigCommerce storefront, was compromised. Attackers stole an application key belonging to Ribon's owner and used it to access customer names, addresses, phone numbers and email addresses between 13 and 17 September — four days before BigCommerce's security team removed the app. Passwords and payment details were held separately and were not affected.

It is a small breach by the standards of this list, and that is rather the point.

For boards. Nobody signs off on "installing a third-party app" as a board-level risk decision, yet that is exactly the access an attacker used here. Ask for a current inventory of third-party apps connected to your customer-facing platforms — ecommerce, CRM, support tooling — and who reviews the permissions each one holds before it goes live.

The thread that ties this together

Every item this week involves an organisation whose own systems held up while something it had delegated trust to did not: an OAuth authorisation flow, a former data processor, an AI agent's tool access, a device-code sign-in prompt, a bolt-on ecommerce app. None of these are exotic attack surfaces. All of them are things most boards assume someone else is watching.

The question to take into next week: if you asked your executive team for a full list of the third parties, agents and delegated authentication flows that can touch your customer data, could they produce one by Friday — or would they still be compiling it?