The reported Binance breach is relevant to UK businesses because it brings a familiar security problem into sharp focus: the damage an attacker can cause once they gain access to a trusted system.

The sums involved are exceptional. The questions about access, authority and response apply much more widely. A business holding client records, processing payments, developing intellectual property or providing services to other organisations has something worth protecting. Its exposure depends on the systems it operates and the access those systems provide.

Recent developments around PHP2Shell, Linux vulnerabilities and AI-assisted security research add urgency to that discussion. They show why organisations need to understand both how an attacker might get in and what would happen afterwards.

Binance has estimated the impact of its security incident at approximately $6.3bn, with around $3bn in affected assets frozen. Those figures describe different things: freezing assets may prevent further movement but does not establish that the money has been recovered and returned. The company has said it will cover losses. Binance’s initial security update

The technical account is still developing. Binance initially identified a compromised engineer’s laptop as a possible part of the attack, then reported additional points of breach. Its co-chief executive has also cautioned against reducing the incident to one engineer’s permissions or a single action. A complete explanation of the attack is still awaited. With many researchers attributing the attack to the North Korean group TraderTraitor BBC reporting | TRM’s investigation

But what lesson can UK businesses learn and put in place now? The practical starting point has to be to consider what a compromised account, laptop or internet-facing edge service would allow an attacker to do.

A smaller company may hold confidential legal advice, payroll information, engineering drawings or commercially sensitive correspondence. It may have access to a larger customer’s systems or, in GDPR terms, it may be a data custodian or data processor. It could come down to a small dependency on a single application to take orders, organise deliveries or pay staff. The loss does not have to reach a headline figure to seriously damage a business.

An organisation can also become a victim before anyone has deliberately selected it by name. The NCSC describes how criminals gather access opportunistically, including by scanning for vulnerable systems, and subsequently identify which opportunities are valuable. This is also true as AI increases the complexity of attacks. AI bots and swarms are actively hunting for unpatched systems. Company size offers little reassurance or protection when the initial selection criteria is an exposed service running vulnerable software. NCSC analysis of the cyber crime ecosystem

This is directly relevant to the assumed-breach work we are currently undertaking at CCL Solutions.

An assumed-breach assessment begins from an agreed position in which an attacker already has some access. That might be a user account, a workstation or a foothold on a server. It allows us to examine the consequences and the path of resistance that access under that user or access constraint gives to a system. How much time do the security controls buy, and under what conditions can the attackers remain hidden within the system before detection?

In Short, the purpose of our Assumed Breach is to establish whether the controls protecting important business functions work when an earlier layer of protection has already failed. The questions need specific, testable answers.

‍

What can the attacker reach? We need to understand the systems, information and further permissions available from the starting point. An ordinary account may have access to shared files containing credentials. An application may hold a service account that connects to another system. A supplier’s remote access may extend beyond the service they maintain. The assessment should establish whether these connections create a usable route to something the business cannot afford to lose.
What prevents a sensitive action? Accessing a system should not automatically grant authority to change payment details, extract an entire client database, or disable backups. Those actions need controls appropriate to their consequences. For example, a second approval offers limited protection if the same compromised administrator can alter both the payment and the approval process. Testing should establish how independently those controls operate.
How quickly would the activity be detected? Recording an event and recognising an attack are different stages of the response. We need to establish which activity generates an alert, where that alert goes and whether the recipient has enough information to investigate it. A meaningful assessment measures the time from the simulated activity to recognition and escalation, including arrangements outside normal working hours.
How quickly can the organisation contain it? Someone must be able to revoke access, invalidate sessions, isolate a device or interrupt a damaging process. They also need the authority to act. If containment requires a decision from someone who is unavailable, that dependency belongs in the findings. The response should preserve evidence, while prioritising and safeguarding the system and preventing further outbreaks or harm.

For a smaller business, this can be a focused exercise around one critical service and the accounts that support it. A larger organisation may need to examine several routes across its infrastructure such as cloud services and suppliers. The scope should follow the potential business loss, or business risk.

The outcome should be usable: a demonstrated route, evidence of where controls succeeded or failed, an owner for each necessary change, and a way to verify that the change works.

The recent PHP2Shell provides a current example of why the route beyond the first compromised system matters.

On 21 October, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow an unauthenticated attacker to execute code on affected servers. The vulnerabilities are in PHP itself, so updating a website’s content management system or plugins does not, by itself, fix the underlying runtime. PHP’s security advisory

Once an attacker can execute code on an exposed service, the consequences depend on its permissions and connections. The service may be able to read application credentials, query a database or communicate with internal management systems. A separate weakness may let the attacker gain greater privileges.

It's been reported that a campaign combined PHP2Shell with the Linux privilege-escalation Fragnesia, CVE-2026-46300. The investigation describes compromise of perimeter devices, followed in one environment by access to internal management and identity infrastructure. This is a reported investigation into a separate campaign, showing how quickly attackers utilise threat intelligence and seek to exploite a system that yesterday was considered safe; it does not explain the Binance breach. Dream Research’s findings

This sequence is useful for showing the need to review an exposed service as part of the wider business environment. The relevance is not the access or it being a breach point, but in the credentials it holds, the systems it can contact and the trust other systems place in it; very quickly, now we can see the chain effect of a weak security control, and the access and privileges attackers can gain as they move laterally through a network.

It also affects remediation. Where compromise is suspected, installing the update addresses the vulnerable software. Investigators must also establish whether the attacker obtained credentials, created additional access or changed other systems before the update was applied. We must ask whether the attackers obtained persistence. Did they introduce new weaknesses or backdoors?

AI is increasing pressure on this work, and specific research now supports that concern.

Wiz’s PHP2Shell research describes how frontier AI models helped researchers identify longstanding weaknesses and develop and adapt working exploits. The researchers report completing some of that development and adaptation in hours. These results come from a specialist research environment, but they show that complexity can become less of a barrier to exploitation. Wiz’s PHP2Shell research

A separate example is the Linux vulnerability CVE-2026-98432, discussed in Anthropic’s research published on 27 October. Anthropic reports using an unreleased internal model to produce an exploit that can run commands with root privileges on Linux servers with a multipath TCP listener, without credentials or user interaction. The result applies to the conditions described in its research; it does not establish that every Linux server is exploitable in the same way. Anthropic’s research

This Linux issue is distinct from Fragnesia. Its public CVE record dates from 15 October, and although fixes exist upstream, organisations must check their distribution and installed kernel. A fix being available in the original project does not necessarily mean it has reached every deployed product. Ubuntu’s vulnerability record

There is also a practical basis for the discussion about AI agents working in parallel. Anthropic describes running large numbers of scanning agents across codebases, checking coverage and verifying findings. This increases the amount of investigative work that can proceed simultaneously. Claims about autonomous attacking “swarms” should be judged against demonstrated capabilities, including the tools, human input and verification involved. Anthropic’s research

For defenders, the implications extend to both known vulnerabilities and zero-days.

For a known vulnerability, AI can help analyse the flaw and develop exploitation techniques, adding pressure to the interval between disclosure and remediation. For a previously unknown vulnerability, it can help researchers find weaknesses that have survived years of use and scrutiny. The NCSC assesses that AI will further shorten the time available to address disclosed vulnerabilities and enhance zero-day discovery and exploitation by skilled actors. NCSC assessment of AI and cyber threats

It is my view that businesses should plan for that pressure in their operating standards, by asking “what if”. What if someone gained access? What if a user account was exposed? What if our backup where downloaded unencrypted?

That means knowing which services are exposed, who maintains them, and how an urgent change can be approved and completed. Where an update is not yet available, there must be a decision about exposure, vendor-supported mitigations and whether the affected service can continue operating safely.

The same research gives defenders useful capabilities. AI can help review code, investigate findings, and identify related weaknesses. Its findings still need validation, and any deployment into a business environment needs appropriate controls over access and actions. NCSC guidance on using AI to find vulnerabilities

For businesses using outsourced IT or managed hosting, these responsibilities need to be explicit. Ask your provider to confirm which products and installed versions are affected, whether remediation is complete. Ask the hard question: what remaining exposure do we have? If you suspect exploitation, ask what they checked for evidence of compromise. A statement that routine updates are enabled does not answer those questions. PHP was safe a few days ago. It now needs patching and is being exploited by malicious actors.

CCL’s free PHP2Shell checker offers a practical starting point for a website you own or manage. It checks the public homepage and examines the PHP version information advertised in its response headers.

The scope is deliberately limited. It sends no exploit payload and cannot inspect hidden PHP versions or the wider hosting environment. If no version is visible, the result is inconclusive. You need to check the advertised version against the installed package and any security fixes supplied by the vendor. The checker provides evidence to take to your technical team or hosting provider.

From there, the wider work begins to establish what a compromised service or account could reach. That is where assumed-breach testing, incident response and digital forensics contribute directly to your business decisions.

I would start with one service the organisation cannot afford to lose. Identify the accounts and systems that can reach it, test the controls protecting sensitive actions, and exercise the response with those people expected to make the decisions.

The business should be able to demonstrate what stops an attacker, how quickly someone will recognise the activity, and who can act to contain it.

‍

Back to Latest menu

Binance, PHP2Shell and AI: what UK businesses should be examining now

We're here to help