Attackers are hammering servers with millions of attempts to exploit the critical PHP2Shell vulnerabilities, with Amazon revealing that someone was already going after the flaws four days before they were publicly disclosed. Cloudflare says it has recorded a staggering increase in attacks targeting the two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, since details began circulating earlier this week. According to Cloudflare CEO Matthew Prince, the company spotted thousands of exploitation attempts in the 10 hours before the vulnerabilities were publicly announced. That figure jumped to tens of thousands within 45 minutes of disclosure, hundreds of thousands within two hours, and has since climbed into the millions. And the attackers aren't simply recycling the same exploit. Cloudflare said it has seen miscreants tweaking their payloads in an attempt to sneak past its web application firewall (WAF) protections, apparently using feedback from blocked requests to work out what might get through. Security outfit Hadrian also sounded the alarm on October 21, reporting that PHP2Shell was being "exploited in the wild at scale." "Most of the attacks we observe abuse PHP's session upload-progress path, and we expect more exploit paths to appear before and after the fix ships," the company warned. More worrying, some attackers appear to have started before the vulnerabilities were even public knowledge. Amazon Threat Intelligence says it detected an attempt to exploit PHP2Shell on October 17, four days before patches were released. The activity was picked up by MadPot, Amazon's network of honeypots designed to lure attackers and record what they get up to. "While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure," Amazon said. The retail and cloud giant said it detected multiple proof-of-concept exploits on October 21, with the earliest appearing around 0200 UTC, some 12 hours before the patches were released. Over the following six hours, further attempts arrived from different anonymized infrastructure, using a variety of payloads. Amazon reckons this points to multiple attackers rather than a single group. Whether any of those attempts would have worked against real-world systems remains unclear. The findings add another layer to an already messy disclosure. As The Register reported on Wednesday, the PHP Foundation has accused supply-chain security vendor Chainguard of putting websites at risk by publishing patched PHP builds before the agreed disclosure deadline. However, Amazon's October 17 detection suggests at least one cybercrim was already trying to exploit the bugs days before that incident. The vulnerabilities themselves are particularly nasty. Both carry a critical 9.2 severity rating and affect PHP's handling of memory, potentially allowing unauthenticated attackers to execute malicious code on vulnerable servers. Unlike flaws in individual plugins or applications, these bugs affect the PHP runtime itself, putting a potentially enormous number of websites at risk regardless of which content management system they use. Cloudflare says it has deployed WAF protections across its free and paid plans, although it has stressed that these are no substitute for patching. With attackers already trying their luck before the fixes were available, admins may have more than just a patching backlog to worry about. Amazon is advising organizations to investigate suspicious activity dating back to at least October 17, rather than assuming their systems were safe until the vulnerabilities became public. ®

China-aligned attackers used AI agents and compromised ConnectWise application credentials to target more than 2,250 Microsoft 365 tenants, Microsoft says. The Windows giant revealed this week that the attackers, tracked as Storm-0940, used an open source AI penetration-testing tool called ARTEX to automate attacks against Microsoft 365 environments. In some cases, they went from picking a target to gaining privileged cloud access in less than three hours. The findings shed more light on the ConnectWise security incident, which saw the IT management vendor pull the plug on its Cloud Backup, SaaS Security, and Cloud Management services after discovering unauthorized access to application identities. ConnectWise didn't initially identify who was responsible, but Microsoft has now pointed the finger at Storm-0940, a China-linked espionage crew that's been operating since at least 2021. The group has traditionally relied on the usual tricks, including password spraying and exploiting internet-facing applications, but this time it used AI to do some of the heavy lifting. ARTEX is an open source penetration-testing framework written in Go that uses AI agents to automate everything from reconnaissance and vulnerability discovery to credential attacks and data theft. Microsoft says Storm-0940 began using it as early as September to target organizations worldwide, including government agencies, defense contractors, banks, manufacturers, and tech firms. Between October 10 and 14, the hackers made more than 151,000 failed sign-in attempts against 327 accounts at eight organizations. Microsoft observed no successful logins from that password-spraying campaign, but then the attackers shifted to compromised ConnectWise application identities. The compromised application credentials let the attackers exploit permissions customers had already granted to ConnectWise services, without needing an interactive user login. Armed with ARTEX, Storm-0940 attempted to authenticate against more than 2,250 Microsoft 365 tenants, at times reaching 2,900 attempts a minute. Microsoft also observed AI-accelerated activity through Microsoft Graph, including reconnaissance, application credential changes, and attempts to modify privileges, potentially allowing the attackers to stick around even after the original credentials were revoked. Most attempts failed, though Microsoft says the hackers still managed to establish persistent privileged access at numerous organizations. It hasn't disclosed how many customers were compromised or whether any data was stolen, cautioning that a successful login doesn't necessarily mean information was accessed. ConnectWise CEO Manny Rivelo said the company had contained the affected application connections and was gradually restoring services, although shutting down those connections wouldn't necessarily boot out attackers who had already established a foothold in customer environments. ConnectWise has been here before. In May 2025, it admitted that a "sophisticated nation-state actor" had broken into its systems and compromised a small number of customers using its ScreenConnect remote access software. There's nothing to suggest the two attacks are linked. Nor is Storm-0940 alone in making use of ARTEX. Microsoft says it has spotted attackers from several geographic regions using the framework, which is freely available for penetration testing. The underlying techniques are nothing new – stolen credentials, password spraying, and application abuse – but Microsoft says AI helped Storm-0940 execute them faster, with some attacks progressing from initial targeting to privileged cloud access in under three hours. ®

Welcome back to PWNED, the column where we talk about companies and organizations that leave the doors wide open to attackers. This week’s sad story involves a major American pharmacy chain that couldn’t fill a prescription for password security. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available upon request. Our tale comes courtesy of red team and pen testing specialist Dahvid Schloss, who currently serves as COO of Suzu Labs, a cybersecurity company that boasts “we break your systems before adversaries do.” Over a career spanning more than 15 years, Schloss has assessed the security of numerous businesses, including a large US pharmacy retailer that he asked us not to name. He wasn’t asked to break in, just to do an audit on all of the org’s corporate switches, routers, and firewalls. “So, I come across this firewall,” Schloss said. “That is an edge firewall, meaning this is what touches the internet. This part will add its enable password, which is the term Cisco uses for administrator. It had the enable password as 'password.' Just p-a-s-s-w-o-r-d.” As Schloss noted, the enable command on Cisco devices allows the user to gain administrative rights to the firewall, controlling network traffic. If someone connected to that firewall, either via SSH or through an exploit, and got normal user privileges, they could then elevate those privileges to admin and do something like shut off all traffic from the intranet to the outside world. Schloss actually didn’t guess that the password was “password,” but instead was able to decrypt the file holding the passwords by breaking Cisco’s own protection, something he said is easy to do. “That enable password was stored as Cisco IOS type 7, which isn’t really a hash,” he said. “It’s more of a reversible encoding with a publicly known key. Even back then, it was best practice not to use it.” But even if the password were stored in a secure place, it would be very easy for a threat actor to guess. So he marked the password failure down as a “high find,” a bad type of vuln that needs to be fixed right away. When he brought the password to the company’s auditing department, they put him on a phone call with the auditing team, the entire IT team, his own manager, and others. On the packed call, the auditing team, who had commissioned Schloss’s work, was very concerned about the firewall password, but the IT team didn’t think it was a very serious problem. The two sides screamed at each other for more than an hour while Schloss and his colleagues sat there quietly, staring at their cameras. “The audit team is like ‘yeah, we gotta fix this.’ And the directors were really harping on ‘this needs to be done’ and the IT team starts firing back,” Schloss explained. “It’s like ‘Why? Who’s gonna? What does it matter? No, this isn’t a high-priority find. This is maybe a medium. Yeah, it’s bad, but it’s not that bad.’” The call dragged on so long that Schloss was unable to finish presenting his findings and recommendations. The conflict was so severe that the client continued to follow up and ask him to explain what he found again for the next three years – long after he had moved on to other projects. He later learned that the auditing department controlled the bonuses for the IT team and there was a stipulation that any “high finding” would eliminate those bonuses. So they weren’t just arguing about “password” - they were really talking about the compensation for an entire division. The lesson here is more than “don’t use the word ‘password’ as a password.” It's also about misaligned incentives. Tying security posture to compensation seems like a good way to incentivize workers to follow best practices, but it also leads them to deny responsibility and minimize mistakes when they're found. ®

Indian certification authority eMudhra has defended the laughably weak private keys it used to sign some digital certificates it issued, and suggested others should share the blame for the incident. In case you’re coming to this one late, news broke yesterday that private keys the company used to sign certs were beyond weak: one was literally just the number “4,” and several others were short strings of easily guessed two-or-three-digit numbers. It’s easy to deduce the value of those keys, which makes it possible to forge certs and impersonate websites or other resources. That’s gold for scammers, phishers, and other miscreants. The entire infosec industry has pointed that out, urged swift adoption of better certs, and lamented the fact that implementing replacements will be a long and thankless task. eMudhra’s statement about the incident says it generated keys during “a Key Generation Ceremony (KGC) held on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules (HSMs).” Such hardware is the standard kit for the job and should in theory produce nicely complex keys and store them securely. But something went wrong. “A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys,” the statement claims. “The weak keys were the ones published to the browser root stores. eMudhra is working to establish the root cause.” The company then gets a tad defensive. “These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025,” the statement adds, seemingly shifting some blame to auditors and other stakeholders. The announcement then points out that eMudhra’s TLS business generates just one percent of its revenue, meaning this mess won’t impact its bottom line too much. That’s nice to know for the company’s investors but rather misses the point that whoever relies on the company now has an urgent, unwanted, and costly job to do replacing certs. “eMudhra is working directly with customers who may be affected to give them replacement certificates, so that critical services are not disrupted. The company is also working with the root programs and continues its root-cause investigation,” the statement adds. The company allows that the incident “may have some reputational risks on eMudhra which cannot be quantified.” Ya think? ®

PHP developers have accused software supply chain security shop Chainguard of effectively revealing critical bugs in the open-source scripting language ahead of a planned official disclosure. On Wednesday, just hours after releasing emergency patches for the two bugs collectively called PHP2shell, PHP maintainers published a blog about how the vulnerabilities were found and fixed. They credited researchers at Calif, OpenAI, and Wiz with finding the security holes between August and September. All three companies have said they used AI models to find the vulnerabilities, which are now tracked as CVE-2026-109618 and CVE-2026-109619, and can allow an unauthenticated attacker to execute code on servers running PHP. This is especially serious because PHP powers huge chunks of the public web. It also adds a dose of irony to the “leak and disrupted disclosure” part of the blog, which blames Chainguard - a company that aims to secure software supply chains by hardening open source code - for the messy disclosure. The trouble, according to PHP developers, started on Tuesday around 15:00 UTC, when “two CVE IDs began circulating on online forums and social media,” along with incorrect information about the release time and CVSS severity rating. At that point, no technical details leaked. The rumors, however, prompted PHP maintainers to warn people in advance about the critical flaws, and move the planned disclosure forward a day, from Thursday to Wednesday. “Distributors were still packaging the fix, so releasing immediately would have left many users without an easy way to update,” the PHP Foundation blog says. “Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.” A couple of hours later, Calif “mistakenly” published a video showing a proof-of-concept exploit and “additional, though limited” information about the bugs, we’re told. “Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well,” the PHP blog says, but it does not name these providers. And then it throws Chainguard under the bus: “On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.” Chainguard CEO: 'We made the call' Chainguard CEO Dan Lorenc spoke with The Register on Wednesday, and while he doesn’t dispute the timeline, said his company "didn't leak." “These things are messy,” Lorenc said. Chainguard learned “something was coming in PHP” on Friday from one of the researchers that found the bugs, Lorenc told us. Later that night, using his company’s AI harness and a frontier model, the CEO and the Chainguard team independently found the same memory corruption vulnerabilities. All it took was a “basic prompt of ‘find bad vulnerabilities in PHP,’” Lorenc wrote in a subsequent LinkedIn post. On Saturday, Chainguard began working with the PHP maintainers, confirmed that some of its findings matched the bug reports, and helped test the patches. “The patches are crazy - this is not a simple vulnerability,” Lorenc told The Register. “It really did take them months to build a real, working patch for it. And then on Monday, the rumors started, and yesterday it just spiraled.” Some people published POCs on social media, other security vendors reported seeing real-world exploitation, and late Tuesday night Lorenc told us he decided to ship the fixes, and notified the PHP coordinated disclosure channel about his plans. “People were getting hit in advance” of the official PHP disclosure, “so we made the call to ship the fixes under that,” Lorenc said. “It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild.” Also on Tuesday night, Chainguard published built artifacts and made them accessible to anyone, not just customers. “And then I woke up this morning and saw that this was all our fault,” Lorenc said. When asked if he would do anything differently, given the fallout from Chainguard’s early disclosure, Lorenc said no. “This process and policy is based on trying to coordinate as much as possible until shit hits the fan and people start weaponizing things,” he said. “It sucks, because we really are all on one team, and there's bad guys over there doing stuff.” Chainguard’s honeypots trapped IPs from China and Russia targeting the vulnerabilities on Wednesday, Lorenc added. “Just being told there's a vulnerability in a piece of software - even something as big as PHP - is enough to find it,” he told us. “I did that myself without any other knowledge on Friday." "I think this is kind of the new normal. People are able to build an exploit in hours without even knowing what the vulnerability is." What we know about the CVEs and how to exploit them While we still don’t know the scope of exploitation - or what will happen to vulnerable legacy systems that don’t have security fixes - threat hunters predict it’s going to be a doozy. “Successful exploitation could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them,” Wiz researchers Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz warned on Wednesday, adding the oft-quoted stat that PHP powers 70 percent of all websites in the world. “Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4,” the Wiz kids wrote. “Attackers can exploit them remotely, in some cases fairly easily. Immediate patching is strongly advised.” Both bugs are related to how PHP handles memory management and error handling, and both lead to remote code execution (RCE). They can cause a corrupted internal PHP state when a request ends unexpectedly, and then a later request can reuse that state, leading to memory disclosure or RCE. “Both are memory corruption vulnerabilities,” VulnCheck researcher Patrick Garrity explained. “If an attacker can shape the memory PHP trusts, they can potentially hijack what it does next, and in these cases that means remote code execution.” CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) leads to RCE via out-of-memory corruption. “If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory,” the project maintainer wrote. “On Apache with mod_php, an unauthenticated request can trigger this before any application code runs.” CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) allows RCE via stale state. “A fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request,” according to the PGP Foundation. “A later request handled by the same worker could then use that freed memory. A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php.”®

Unknown crims compromised LiteLLM's release process on Wednesday, distributing a malicious version (1.107.0) containing malware designed to steal cloud and AI credentials and a remote access trojan (RAT) capable of executing arbitrary code on infected machines through PyPI and Docker registries. PyPI quarantined the trojanized version of the popular open source AI gateway within hours, and the Docker image (litellm/litellm:1.107.0) was removed from both Docker Hub and GHCR soon after - but anyone who ran the compromised package on any platform should assume their secrets have been stolen. “Check for /tmp/.pc_once_* (the exfil has already fired if this file exists) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if this file exists),” advised Aikido Security malware hunter Ilyas Makari. “The same applies to anyone who ran the official Docker image litellm/litellm:1.107.0, or pulled it via the latest, main-latest, or main-stable tags.” The most recent safe version is v1.106.2. While it’s too early to tell the scale of this latest LiteLLM supply chain attack – an earlier LiteLLM compromise in March potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines worldwide, according to CloudSEK – make sure to take these measures seriously, and check environments for any indicators of compromise. Aikido, Google’s Wiz cloud security biz, and supply-chain security provider Socket have all published extensive threat-hunting and mitigation instructions for LiteLLM users and security teams, so give those a read stat. LiteLLM, developed by BerriAI, provides a common interface for LLM providers, including OpenAI, Anthropic, and Google Gemini, and receives about 23 million weekly downloads. This means a compromised installation can run alongside LLM provider API keys, cloud identities, and database connection strings - and expose a ton of valuable credentials, secrets, and other sensitive data to whoever uploaded the malicious package. “Teams using 1.107.0 should stop deploying it and investigate environments where Python ran after installation, including proxy containers and CI runners,” Socket researchers said on Wednesday. The malicious version was uploaded at 11:39 UTC, and according to Wiz kids Benjamin Read and Rami McCarthy, the payload originates with malicious commits made on github.com/Berri-AI/litellm, which is a hyphenated variant of the legitimate BerriAI organization. Miscreants used this repo to inject the three malicious files into the LiteLLM release pipeline. These, according to Makari, include cook.pth, which causes the second file, cook.py, to run automatically every time Python is invoked on the machine, without any additional user action. Meanwhile, cook.py contains the infostealer, and the third file, sitecustomize.py, is the RAT. Python also executes the RAT at interpreter startup, and this file spawns a background daemon that polls the attacker's infrastructure every hour for new commands to execute. Upon executing, the infostealer harvests a ton of sensitive data across 16 modules targeting browsers, cloud providers, and AI services, according to Read and McCarthy. It steals browser credentials and cookies from Chrome, Firefox, Edge, and Safari, along with AWS credentials from ~/.aws/, environment variables, and EC2/ECS instance metadata (IMDS). It also collects users’ Google Cloud Platform service account keys and application default credentials, along with Microsoft Azure tokens from the CLI cache. And then it also swipes API keys for OpenAI, Anthropic, Cohere, and other LLM providers, plus SSH private keys, GPG keys, and shell history files. The malware then encrypts all of this stolen data using AES-256-CBC, wraps the encryption key with an RSA-4096 public key, and sends the encrypted data via HTTP POST to an attacker-controlled domain: http://www[.]litellm[.]dev/healthcheck. BerriAI did not respond to The Register’s inquiries. This is an emerging story, and we will continue to update it as we learn more details.®

Make sure you don’t say anything mean or secret after hanging up a call on Signal, as a bug in the encrypted messaging app’s calling library could prevent a call from ending properly, potentially leaving audio and possibly video active. The vulnerability, CVE-2026-113380, was published by MITRE on Tuesday and given a CVSS score of 9.3, marking it as a critical issue in Signal’s open-source RingRTC library in every single version before 2.72.0. That update was pushed out last month, but the vulnerability wasn’t made public until now. RingRTC is Signal’s own calling library built on top of WebRTC, a technology introduced in 2011 that has since become widely used for voice and video communication over the internet. RingRTC provides Signal-specific calling functionality using WebRTC, which already encrypts media traffic, but that isn't stopping RingRTC from failing to hang up calls in certain conditions, according to the CVE report. What’s happening is, in essence, a denial-of-service attack on RingRTC’s finite state machine (FSM) event queue, which handles events involved in managing calls. If one of the people on the call saturates the FSM queue with requests, it can become overwhelmed and fail to process a hangup request, preventing the call from terminating properly. The vulnerability is classified as CWE-754, or improper checking for unusual or exceptional conditions, according to a report posted to GitHub. A conceptual proof of concept is available in the GitHub report linked above, using a Python script to simulate how flooding an event queue can prevent a hangup request from being processed. Were a malicious actor to exploit this, the person on the other end may think the call has been terminated, but either or both of their video and audio channels could still be open. The attack complexity is considered low according to the CVE, and while CISA’s known exploited vulnerabilities catalog doesn’t indicate this has been spotted in the wild, Signal users ought to ensure they’ve updated their apps - mobile and desktop - to the latest versions to ensure they don’t end up being caught on a hot mic without any notice. Comparing RingRTC 2.72.0 to the previous version indicates that Signal's fix allows the call's finite state machine (FSM) to detect termination requests independently of the event queue, while adding a timeout to prevent stalled processing from indefinitely blocking a hangup. It's not entirely clear from Signal's release notes when the fixed version of RingRTC reached the Android, iOS, and desktop versions of its apps. Signal Desktop's release history indicates that RingRTC 2.72.0 was incorporated in September, but the precise rollout dates across all platforms remain unclear. We’ve reached out to Signal to learn more, but haven’t heard back. In the meantime, best to update your installation to be sure you’re not still vulnerable. That, and watch what you say after hanging up a call. ®

PHP developers have released emergency updates for two critical vulnerabilities after cybersecurity authorities warned organizations to patch immediately or consider taking exposed applications offline. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 address CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. The project's developers urged users to update immediately. All PHP installations serving web requests are potentially affected, including deployments using PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, and LiteSpeed, the developers said. "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Jake Knott, head of threat intelligence at watchTowr, said: "As expected, watchTowr Intel is already observing in-the-wild exploitation of the latest PHP vulnerabilities, with a variety of vibecoded PoCs already hitting our sensors featuring a variety of 'php2shell' User-Agents. Whilst nobody has been successful to date, we don't expect that will last long." "Where immediate patching is not feasible, organizations should consider isolating internet-facing applications from public networks until a fix is available," CERT-EU said in an advisory issued ahead of the patches. The body lists both vulnerabilities with CVSS scores of 9.2. Finnish government services and websites belonging to the Dutch parliament, cybersecurity authorities, and data protection regulator were taken offline as a precaution. Privacy campaign group noyb also temporarily withdrew its website. PHP "powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn't even advertise that it runs PHP under the hood," infosec vendor Huntress noted. That makes identifying exposed installations a substantial job. "The number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast," said John Hammond, Huntress's senior principal security researcher. ®

When it comes to cyberattacks that shut down power grids, drinking-water systems, and other critical infrastructure, AI doesn’t – yet – turn script kiddies into sophisticated, nation-state attackers. But “the potential is there,” according to operational technology (OT) security experts. "One thing that we've relied on for years is security by obscurity when it comes to utilities," said Steve Swick, former chief information security officer at American Electric Power. "The knowledge needed to do some of that stuff is getting less likely to be necessary," Swick added during a media panel ahead of the publication of Frenos' State of AI in Security report. AI makes it easier and faster for human attackers to target critical infrastructure, gain access to utilities and manufacturing plants, and perform OT system reconnaissance. “Basic access can recon documentation, and distill through that documentation very quickly to find out critical design features of your plant and facility,” said Paul Shaver, head of OT at Armadin, during the panel. “I can download the manual for almost any automation controller, parse through that very quickly, and come up with ways that I can exploit a dedicated feature of something that was not secure by design.” Armadin is Kevin Mandia’s new security startup that uses swarms of autonomous AI agents to simulate real-world cyberattacks. Prior to joining Armadin, Shaver spent six years as the global OT practice leader at Mandia’s earlier company, Mandiant, which Google acquired in 2022. “I will fly my Mandiant flag for a second and try to steer away from the fear, uncertainty, and death of the world is coming to an end, and every script kiddie is now a very sophisticated nation-state adversary. But I’m not going to say the potential is not there, because the tools are improving such that the access to information is so much quicker.” At Armadin, and with an AI assist, “I'm very quickly building tools in days that would normally have taken me months,” Shaver said. “If it can do that for me, it's doing something similar for the folks that have a very basic skill set. I wouldn't go so far as to script kiddies yet, but as the models improve, that becomes more of a possibility in this space.” Plus, as AI lowers the technical barriers to would-be OT hackers, “it advances the timeline,” said Harry Thomas, chief technology officer and co-founder of Frenos, a security company that does AI pentesting for OT environments. “If a better-than-average script kiddie can now perform attacks,” Thomas said, “You have more threat actors out there. There's an acceleration in timeline, more attacks could be happening, and from a defensive position, you might not know who your threat actor is anymore.” Testing the power of LLMs to help plan attacks The Frenos report, published Wednesday, examined the extent to which AI could help someone plan an attack on industrial systems. To do this, it ran several AI models through 16,980 tests between October 2025 and September 2026. These included 13,884 decision attempts, 2,520 planning attempts, and 576 simulated attacks. The company won’t disclose the models or providers’ names, but said it tested six frontier models, two US open weight models, and two foreign open weight models, on three kinds of tasks: choosing one action, planning the steps to a goal, and working through a simulated scenario. Each test gave the model background information and a set of attack actions to choose from. Before choosing, each model received details about assets, networks, and known weaknesses, plus the access each action required. Frenos then checked whether the model’s choice matched the required outcome. Depending on the model, between 6 percent and 47 percent of the choices passed. These tests found that the strongest three frontier models succeeded in about 90 percent of their planning attempts – meaning they produced a workable attack plan – but these same models weren’t consistent: 60 percent, 62.9 percent, and 74.3 percent of the attack plans passed every repeat. “A plan can look sensible and still leave out something essential,” according to the report. “The models had information about the task, but some answers skipped a step or assumed access that the plan had not established.” Meanwhile, the most successful of the four open weight models – a non-US model – achieved a 36.2 percent overall success rate. That figure, however, was still higher than the overall success rates of three other US frontier models, which scored 31.9 percent, 18.8 percent, and 17.9 percent, respectively. “We're seeing that even though AI models help us accelerate our tooling, accelerate our access and knowledge transfer, they are still prone to hallucinations – aka mistakes,” Thomas said. “We still think human judgment remains essential for these AI models to make the threat actors achieve whatever mission or goal they're trying to achieve.” In these tests, no humans asked the models to correct their plans, whereas in a real-life attack, a miscreant who understood the target could spot a gap in the AI’s plan, provide more information, and ask the model to revise its answer. “On top of that, when we were testing the AI models, we used a harness that was pretty simple: Here's some information. Here's the context. Give me an answer,” Thomas said. “A more capable harness could have given these AI models more of an edge.” Based on the findings, Frenos recommends actions for OT defenders to take, starting with a layered defense. This involves segmenting networks, limiting remote access and user permissions, and testing recovery steps. “We have our business continuity plans and disaster recovery plans for a reason,” Thomas said. “Let's execute them.” ®

Nvidia has proposed a new way to keep corporate AI agents in line. Nvidia on Wednesday introduced its OpenShell Reference Architecture. Based on the company's OpenShell secure runtime, It's a recipe for creating, operating, observing, and policing AI agents using OpenShell on Nvidia hardware. "Nvidia created OpenShell to give agents the freedom to do useful work within clearly defined boundaries — contained, monitored and under control," CEO Jensen Huang said in a canned statement. "With the OpenShell Reference Architecture, agents can think on Rubin, act on Vera and be governed on BlueField." AI agents are touted as a powerful automation technology. The reality is that they can be unruly, as demonstrated by security testing OpenAI and Anthropic conducted, during which their models exceeded their remit and attacked third-party organizations. Developers of existing agents, like Claude Code, Codex, OpenClaw, and OpenCode, therefore include controls that limit access to tools like curl and bash.Devs also create sandboxes to isolate an agentic process from the host, so that if agents go awry they're contained. OpenShell sits a level above that with a runtime that extends sandboxing to govern gateway-brokered credentials, identity and policy boundaries, and (eventually) routing and workflows too. At least mostly – OpenShell still has a few open security-related issues listed on GitHub. To implement OpenShell, organizations need Nvidia hardware. The company's blueprint calls for Nvidia Vera Rubin infrastructure to run models like Nvidia Nemotron, with agent harnesses handled via Vera CPUs, and Nvidia BlueField-4 DPUs (aka SmartNICs) propping up Nvidia Sentry security software to monitor agent behavior. The AI biz has made this blueprint available to partners capable of powering Linux and Kubernetes infrastructure. The usual suspects are aboard: Canonical, SUSE and Red Hat. Cloud hyperscalers Amazon Web Services, Google Cloud, and Microsoft Azure have also been tapped as vendors for this vision. And of course Nvidia's floor plan applies to agents from various model builders, including Anthropic, Cohere, Google, Meta, OpenAI, Perplexity, Reflection, and SpaceX. Nvidia says several banks – Europe’s BBVA and Santander – are perusing the OpenShell Reference Architecture spec to see how it aligns with their security and governance requirements. And the AI biz is not too modest to let slip that SAP is integrating the OpenShell Reference Architecture with its Joule Studio runtime for safer agent operations. It's worth noting that OpenShell collects telemetry data by default, "to improve the project," Nvidia insists. The biz allows users to opt-out, with a cautionary note: "Third-party services, model providers, inference endpoints, agents, or tools that you configure and use with OpenShell may have their own terms and privacy practices." ®

The European Commission has opened an investigation under the Digital Services Act into whether Booking.com is doing enough to stop fraudsters running scams, phishing and smishing on its platform. Officials told The Register the probe, which opened Wednesday, covers a very large online platform (one with more than 45 million EU users) and has three strands. The first is whether Booking.com is failing to prevent fraudulent and non-compliant listings. "This is very much about people portraying themselves as the owner of premises and putting it up for rent while they are not the real owner," an EC spokesperson said. The second is whether it does enough to counter phishing and smishing (SMS phishing), and social engineering. "Scammers take over the account of a property owner and… portray themselves as the property owner, but also take over the contact details," she said. "So they start sending messages that people need to pay additional amounts." The Commission also suspects Booking.com is not sufficiently protecting the data of its consumers and business users. The third strand is advertising transparency: whether the platform clearly distinguishes ads from organic results, and whether it is clear about boosted listings, where property owners pay for higher ranking. Officials cited Booking.com's own admission in June 2024 of a 500-900 percent jump in travel scams over the previous 18 months. "What made us concerned is the very high figures," an official said. In the Netherlands alone, more than 1,000 fraud notifications were made in the first part of 2026, causing damage of €82,000, a tenfold increase on the previous year. “This is a real problem, and this is only the Dutch element,” the official said. “We have reports like that almost from all member states… So, we have clear elements where we find that the risk assessment was not sufficient, and as you know, the risk assessment is a key tool for us.” The Commission acknowledges that Booking.com assesses fraud using cases on its own platform and external reports, and takes internal measures in response. But “we feel that what they have done is absolutely substandard,” the official said. “Although they take measures, they could go much further, and they could have much more solid systems to prevent fraud.” “In the future we expect Booking.com to do a more diligent risk assessment,” she added. That could include addressing abuse of the reservation system, rapidly removing listings when fraud is reported, checking licenses, and changing how property owners are onboarded. A spokesperson at Booking.com told The Register: "We are cooperating fully with the European Commission and engaging constructively on its questions under the Digital Services Act (DSA). Security, trust and the protection of personal information are top priorities at Booking.com. We remain committed to working with relevant governments, regulators, law enforcement and industry partners to combat cybercrime and online fraud and protect travelers and partners." ®

Tragically simple private keys used by a certification authority based in India have been compromised, meaning the 60-million-plus certs it has issued can’t be trusted and necessitating a massive clean-up job. The CA of concern in this case is called eMudhra, which boasts of having issued over 60 million digital certificates to help usher in a world of digital trust. The company has instead panicked the world. News of the company’s errors appeared on Tuesday in a post by Dennis Jackson, a member of Mozilla’s cryptography engineering team. “On Saturday, October 17, at 20:06 UTC, Mozilla received a report from a community member that private keys associated with eight eMudhra intermediate certificates had been compromised,” he wrote. “These keys could allow attackers to issue fraudulent HTTPS certificates for websites they do not control.” Or as Cloudflare put it, “an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic.” Jackson has since elaborated on the incident and the response, which has thankfully seen Mozilla, Chrome, and Apple remediate the issue so their browsers won’t rely on the certificates – at least after users install an update. He also reports that eMudhra has revoked the certs, and lists many FOSS projects that have issued updates that mean they won’t recognize certs from eMudhra. That’s welcome, but sadly certs signed with these private keys are still out there and many services rely on them. Browser makers are set up to detect and reject bad certs. Others who relied on them may not be, and will likely need to dig into their environments to see if they rely on certs signed by eMudhra. Developer Geoffrey Huntley has offered some advice on automating that process. At the time of writing, eMudhra has not responded to The Register’s inquiries about the incident and its security practices. The latter question is of great interest because security researcher Scott Helme analyzed eMudhra’s certs and found one the private keys it used “is the number 4.” “Not a number that starts with 4, or the number 4 followed by a few hundred random digits, just, 4... Another one is 56, and another is 115. I know, because I recovered all of them from their public certificates on my laptop just now, and it took less than a second,” Helme wrote. Other researchers have found private keys including the numbers 66, 155, 156, 230 and 237. Those are vastly inadequate keys, because they’re easy to guess, making all certs issued by eMudhra susceptible to brute force attacks. As Helme put it: “A P-384 private key should be a random 384-bit number, which gives you 2³⁸⁴ possibilities (or roughly 10¹¹⁵), so nobody is ever going to search that.” This is a developing story and The Register will update it as more information becomes available. ®

An automotive tech startup claims that its IT systems were attacked by individuals trying to steal its driving model, and that those attacks came from an IP address associated with a rival in the space. The tech startup, IQ.Lvbs, described the alleged security incident in a recent blog post. On October 3, IQ.Lvbs introduced the private beta of NovaSpark, the first model for the company's IQ.Pilot app, in the Comma.ai Discord channel. They put it in that channel because the model requires the use of Comma.ai's camera hardware, which is built for self-driving vehicles. From there, things got weird. "From October 7 to 14, we faced repeated attempts to steal NovaSpark, access users’ devices and private driving files, and exploit our sign-in system," the IQ.Lvbs blog post claims. "The first requests came from an IP assigned to Comma.ai Inc." In addition, on October 8 – shortly after the alleged attacks began – somebody banned IQ.Lvbs' team from the Comma.ai Discord channel. Posts on the IQ.Pilot Discord channel indicate that individuals doing private beta testing for IQ.Lvbs have also been banned from that channel. One of the three people involved in IQ.Lvbs, a UI/UX designer who asked to be identified only as "Cat," speculated to The Register about the reasons for the alleged hack and Discord ban. "Our model, NovaSpark, is a good deal ahead of Comma's latest small and large models, which directly threatens their core business of making AI models good enough to sell their hardware," he said. "Comma for the most part has been stagnant in their models' improvement and that was a main driver for us making NovaSpark." An October 7, 2026 Discord message from user Torq_boi, said to be Harald Schäfer, Comma.ai’s CTO, implies NovaSpark was distilled from Comma.ai's Rebellious Hope model. “I’m glad people are training models and experimenting with this stuff," the post starts. "But don’t lie to people about what you’re doing, and saying it’s not a finetune of existing comma models when it is. That’s not cool.” IQ.Lvbs disputes that assertion and says it did the work on its own. "The claim that NovaSpark is Rebellious Hope with a short fine-tune and an unchanged policy does not survive scrutiny, and we’re not sure how Comma came to that conclusion, especially considering that they do not possess NovaSpark’s model weights or ONNX," the biz said. In the log data IQ.Lvbs published to support its claims, the company flags the username haraschax as one of those associated with Comma.ai IP addresses. Schäfer uses that username on GitHub. Comma.ai and Schäfer did not respond to requests for comment sent to several different addresses. The Discord user Torq_boi in the Comma.ai channel did not respond to a DM seeking comment. Comma.ai is currently being investigated [PDF] by the National Highway Traffic Safety Administration to assess whether its driving automation tech contributed to five crashes and three deaths. IQ.Lvbs says it's considering legal action over the alleged hack. "We are currently reviewing our legal options and looking into involving the authorities," said Cat. ®

Multiple ransomware groups, including Qilin and Inc, have been exploiting a high-severity authentication bypass bug in Palo Alto Networks' PAN-OS, with Unit 42 investigating attacks since early June across numerous industries, such as finance, healthcare, and manufacturing. CVE-2026-0257 affects PAN-OS GlobalProtect portals and gateways, potentially allowing attackers to bypass security restrictions and establish an unauthorized VPN connection. The security vendor first disclosed and patched the bug on May 13 and initially assigned it a medium-severity rating, saying it was aware of attempts to exploit it but had not observed any malicious exploitation. That assessment quickly changed, and by the end of the month, Rapid7 researchers said they observed successful exploitation across multiple customer environments dating back to at least May 17. On Monday, Palo Alto Networks’ consulting and incident response biz, Unit 42, said ransomware crews including Qilin and Inc continue to batter the CVE. “Attackers are leveraging this vulnerability to gain an initial foothold into corporate networks, subsequently bypassing multi-factor authentication (MFA) controls to establish a VPN session,” said Andy Piazza, a senior director of threat intelligence at Unit 42. After gaining initial access, the criminals move laterally across the networks using Remote Desktop Protocol and Server Message Block (SMB), dropping additional malware for credential harvesting and data theft before ultimately deploying ransomware, Piazza warned. In its ongoing investigations, Unit 42 has spotted the ransomware criminals infecting “numerous industries, including education, financial services, healthcare, high tech, hospitality, manufacturing, professional and legal services, government, transportation and logistics, utilities and energy, and wholesale and retail." Palo Alto Networks did not respond to The Register’s inquiries about the attacks, including how many organizations have been infected. Additionally, ReliaQuest intel analysts warned that “multiple threat groups,” including Settra ransomware operators, are also exploiting the bug to gain initial access to corporate networks via unauthorized VPN sessions. “The most significant evolution in tactics, techniques and procedures (TTPs) following successful exploitation of CVE-2026-0257 is the direct pivot to the virtualization layer,” Piazza wrote. “In one notable case, attackers moved from the compromised VPN gateway to the vCenter management appliance. From there, they disabled security controls on ESXi hypervisors (execInstalledOnly) and used a custom tool to perform offline credential dumping directly against a domain controller's virtual disk (VMDK).” This allows the miscreants to bypass in-guest endpoint detection and response products, and represents “a highly sophisticated method” of stealing domain-wide credentials, he added. Unit 42 has also spotted criminals chaining this exploit for initial access with other vulnerabilities such as CVE-2023-27532, which targets Veeam backup infrastructure. So if you haven’t already patched vulnerable PAN-OS software, do so now - and investigate whether attackers have already gained access to your network. Check Unit 42’s indicators of compromise to assist with threat-hunting activities.®

An "avalanche of vulnerability reports" is forcing curl to move lower-severity cases into public view, reserving private handling for high and critical flaws. From October 26, low and medium-severity reports should be filed in the open source data transfer tool's public GitHub repository, maintainer Daniel Stenberg said. "Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90 percent of all submissions could quickly be assessed to be less than HIGH." Stenberg already shuttered curl's bug bounty scheme this year as AI-generated submissions piled work onto its security team. Stenberg has previously acknowledged that not all AI-assisted reports are bad, but the workload now demands another response. "This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. "We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown." Public handling would let more people assess reports, develop fixes, write advisories, and check for related problems before releases ship, Stenberg said. Handling vulnerability reports publicly won't reduce the work per report, he admits, though it could spread the load and make the resulting lessons and documentation easier to find. At least that's the theory. Public disclosure also gives attackers more time to exploit flaws before fixes arrive. The maintainer agrees this is unfortunate yet unavoidable. "We limit this practice to less than HIGH for this reason: at least these problems are not terrible." Stenberg said researchers using AI are generating unusual option combinations unlikely to occur in real applications, then treating minor discrepancies as vulnerabilities. "We can't continue down this spiraling path with our sanity intact. We don't have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way." ®

A test account protected by "Password1" helped an intruder steal personal data relating to 3,300 people, mostly children, in a ransomware attack that has drawn regulatory rebukes for two Welsh organizations. The Information Commission's Office (ICO) issued reprimands rather than fines to Ogi Networks Limited (ONL) and the Local Government Data Unit – Wales, also known as Data Cymru. According to the ICO, altnet ONL provided server and connectivity infrastructure, licensing, and support to Data Cymru, which helps public bodies across Wales make effective use of data. On November 1, 2024, Data Cymru suffered a ransomware attack after a miscreant exploited a test account called Test2 to infiltrate its network and encrypt 182.7 GB of data housed in a file server and an internal database server. "Before deploying the ransomware, the threat actor exfiltrated 42 GB of data from a primary domain controller, a file server and an SQL server," the ICO said on Tuesday in its reprimand of ONL [PDF]. ONL told the ICO it created the test account on January 13, 2012, during its initial project for Data Cymru. "ONL confirmed that the creation of the 'Test2' account was likely intended to test user account access before migrating 'real' users to its services," the ICO said. "When it was created, the 'Test2' account was given the password of 'Password1'." The ICO cited Bitwarden's password strength tool, which rated "Password1" as "very weak" and estimated a cracking time of less than a second. "The local administrator accounts on the three impacted systems all had the same password. This meant that once one system had been breached, the local account hashes could be collected and used by the threat actor to authenticate access to other systems on the Data Cymru network," the regulator added. "ONL confirmed that it did not carry out any reviews of local administrator accounts following their initial deployment. This meant these accounts remained active, regardless of whether they were used, and continued to use the same default passwords set at the time of their creation in January 2012, as part of ONL's initial project with Data Cymru, for more than 12.5 years." The data watchdog reprimanded ONL under Article 32 of the UK GDPR because it failed to put in place "appropriate technical and organisational measures" to ensure processing systems and services were safe, and it didn't regularly assess or evaluate those measures. It found ONL had no auditing procedures to review user accounts within Data Cymru's Active Directory. The ICO's separate reprimand of Data Cymru [PDF] also detailed failures in its security arrangements. "Password1 is not an appropriate password, it is a wide-open door to nefarious actors," said ICO head of investigations David Doodson. "This incident shows how a single weak password, attached to an account that was no longer needed, can leave the door open to a serious cyber-attack that can affect thousands. "The responsibility for these failures did not sit with one organisation alone. ONL created the test account whilst Data Cymru retained overall control of its network, including the ability to instruct ONL to create or remove accounts. Neither had put in place sufficiently clear and effective measures to ensure that old accounts were routinely identified and removed." ®

Bullhorn is the latest tech giant finding itself on the wrong end of a cyberattack, forcing the recruitment software provider to shut down its platform while it investigates. The US-based company, which serves more than 10,000 customers worldwide, says its systems are now back online in the UK, US, and Australia. Unfortunately for customers hoping to get back to work, online doesn't necessarily mean working. In its latest status update, published on Tuesday, Bullhorn confirmed that some users were still struggling with single sign-on (SSO), password resets, and customizations, while several products continued to report degraded performance. Things started going sideways on Friday, October 16, when Bullhorn flagged problems getting job postings onto Indeed. By the following morning, the platform was suffering a full-blown outage, and Bullhorn confirmed later that day that it was dealing with something rather more serious than a technical hiccup. "We have detected a cyber incident on the Bullhorn Platform. We have temporarily disabled access to our systems in order to contain the activity while we investigate further," the company said, noting that it had roped in cybersecurity specialists from CrowdStrike to help investigate the attack and restore its services. For recruitment agencies using Bullhorn, the outage meant losing access to candidate records, job applications, placements and, in some cases, the systems used to get people paid. Services began returning on Monday, but recovery has been anything but seamless. As of Tuesday morning, Bullhorn's status page still listed degraded performance across several products, including its automation tools, Talent Platform, Onboarding365 and Time & Expense. While Bullhorn is making progress getting customers back into their accounts, it has yet to answer arguably the bigger question: whether the attackers stole anything. In its customer FAQ, it said a forensic investigation is ongoing, and has not yet determined whether attackers exfiltrated customer data. Bullhorn says it will contact affected customers if the investigation finds their information was compromised, and it also warned people to watch out for opportunistic crooks looking to exploit the chaos. "Threat actors may pose as Bullhorn personnel via email, text, or phone calls, using the incident as a pretext to request credentials or sensitive information," it warned on Tuesday, stressing that its employees would never ask customers to disclose passwords, multi-factor authentication codes, or verification tokens. The company has also required password resets for users who don’t log in through SSO, while customers using API integrations have been instructed to rotate their credentials. The cause of the intrusion remains unknown, and Bullhorn has not publicly identified the attackers or confirmed whether ransomware was involved. The company didn’t respond to The Register’s questions at publication time. The outage may be coming to an end, but Bullhorn's investigation into what the attackers actually did is far from over. ®

Britain's national digital ID scheme may be dead, but Whitehall appears to have forgotten to tell the infrastructure. Despite the government scrapping its controversial plans, officials told MPs on Monday that work continues on GOV.UK One Login, digital wallets, and a growing collection of digital credentials designed to help people prove who they are. The abandoned scheme was one of Keir Starmer's flagship policies, originally pitched as a compulsory digital ID card to crack down on illegal working. Privacy campaigners weren't impressed, warning of surveillance and government overreach, and ministers eventually made it voluntary before Andy Burnham, decided to bin the whole thing. But scrapping the scheme hasn't dented Whitehall's digital identity ambitions. Officials told MPs this week that more than 80 types of documents are earmarked for the government's digital wallet, including proof of benefits, driving test certificates, and Disclosure and Barring Service (DBS) certificates. That's quite a lot of paperwork for something that's supposedly dead. The revelations came during a Public Accounts Committee hearing on Monday, where MPs wanted to know what exactly had been scrapped. "But is it not the case, based on the answers you've given us this afternoon, that the infrastructure of digital ID in the public sector is still being pursued?" asked Sarah Green, Liberal Democrat MP for Chesham and Amersham. Susannah Storey, DCMS permanent secretary, was keen to draw a line between the national scheme ministers had scrapped and the digital identity projects Whitehall had no intention of abandoning. One Login already allows people to prove who they are online, she said, but "that is not the same as a national digital identity strategy." Rod Latham, DCMS director for cybersecurity and digital identity, had a convenient explanation for why so much of digital ID was still standing: the government had only scrapped plans for a new identity product. "We already had One Login and the Gov Wallet," he told MPs, adding that work on the digital identity trust framework was also underway before the national scheme was announced. Whitehall isn't wasting time putting that technology to use, with officials confirming that testing is already underway to enable digital credentials to work with private businesses. Natalie Jones, the senior responsible owner for GOV.UK One Login, revealed that the government had opened a testing environment for private sector providers to integrate with its digital wallet technology. This would let people use digital driving licenses to prove their age in pubs, collect parcels, or verify their identity online. "We've got a bit of a chicken and egg situation. A digital driving license is only useful if there are people ready and shops and businesses ready to receive it,” Jones said, noting that further testing is planned for December, with a national rollout of digital driving licenses targeted for 2027. MPs also pressed officials on privacy, particularly whether citizens would have to consent before their information was shared between government departments. "In the confines of digital ID used in digital services, then consent is the model," said Christine Bellamy, interim director general for digital products at the Government Digital Service. There's a catch, of course. Government departments can already share data without asking permission, and officials couldn't quite explain how that squares with their promises about consent. "The strategy needs to be fully finished," Bellamy admitted, which might not be the reassurance MPs were hoping for. Jones insisted that One Login was "not a big data lake," saying it stores identity information separately and cannot see what users do inside government services. "One Login does not issue a single identifier to people," she added. Rupert Lowe MP remained unconvinced, warning that Britain could end up getting digital ID "by the back door rather than the front door." Officials maintained that the canceled national scheme was fundamentally different from the services still being developed, and that people would retain alternatives to digital identification. National digital ID may be officially dead, but between One Login, digital wallets, and dozens of planned credentials, Whitehall still has plenty of identity-related work to keep it busy. ®

The UK's financial regulator says firms' incident reporting must cover significant AI failures and near-misses as increasingly autonomous systems raise new risks. Speaking at Bloomberg's UK Policy Series on Monday, Financial Conduct Authority chief data, information and intelligence officer Jessica Rusu said the regulator wants Britain to lead safe AI adoption in financial services. Greater autonomy, however, requires clear accountability. "Poorly governed AI can create consumer harm, cyber vulnerabilities, and operational failures, potentially at much greater speed and scale," she said. "Our rules already require firms to report major incidents, and that must extend to significant AI failures and near-misses. As the AI Minister has recognized, near-miss reporting for agentic AI is becoming a national security priority. It is a regulatory priority too." The UK punches above its weight in financial services. The sector contributed £223.6 billion to the UK economy in 2025, or 8 percent of national output. That share was the fourth highest among OECD countries. Last week, UK artificial intelligence minister Kanishka Narayan said the government plans to work with Parliament and technical experts to assess how it could strengthen the regime to better protect Britain from AI-driven cyber threats and loss-of-control risks. "That includes identifying and reporting on serious incidents and near misses, including reducing AI-driven risk across essential services, and ensuring serious AI incidents can be properly reviewed," he said. Steven Adler, co-founder and chief scientist of independent nonprofit Guidelight AI Standards, also told MPs last week that AI oversight could learn from aviation, where reporting of near-misses is mandatory in most jurisdictions. "The way this works in aviation is that you not only want to learn about the serious crashes where someone has in fact died; you want to learn about the near-misses, because you can learn from those and help avoid them in the future," he said. However, the government has yet to commit to adding AI-specific measures to the Cyber Security and Resilience (Network and Information Systems) Bill. Alexandra Jones, Director General for Growth, Science and International at the Department for Science, Innovation and Technology, told MPs last week that amendments remain under consideration. In January, the House of Commons Treasury Committee called on financial regulators to conduct stress tests to ensure businesses are ready for AI-driven market shocks. The committee said there should be clear lines of accountability when AI systems produce harmful or unfair outcomes. ®

The UK public sector has reached a cyber resilience inflection point. A new Prime Minister has taken office, and significant machinery-of-government changes have already been announced, including the scrapping of DSIT, the department that had become the center of government digital, technology and cyber policy. Its responsibilities are now being redistributed across other parts of Whitehall, creating a new policy and delivery landscape for public sector leaders to navigate. For years, cyber security was treated as a specialist operational discipline that was essential but largely delegated to technical teams. That model is no longer sustainable. Pressure is now coming from three directions at once, as policy raises expectations for boards and senior leaders, organizational reform reshapes how services, systems and suppliers connect, and technology change, from cloud and hybrid work to AI, expands both opportunity and exposure. Together, these forces mean cyber resilience can no longer sit below board level. Public services, from healthcare and benefits to transport, education, local government and emergency response, are now so digitally dependent that a cyber incident is not simply an IT outage. It is a risk to public trust, public safety and the continuity of government itself. Recent history shows what this means in practice. The 2024 ransomware attack on Synnovis, a pathology services provider to parts of the NHS, significantly reduced the capacity to process blood, urine and specimen tests, caused disruption across south-east London and contributed to delays affecting more than 11,000 outpatient and elective procedure appointments. Incidents like this turn abstract cyber risk into real-world service disruption, making resilience a boardroom issue rather than a back-office concern. Cyber resilience is no longer a technical aspiration, but a leadership obligation shaped by policy, organizational and technology change. Policy change has made cyber resilience a leadership obligation The direction from government and the National Cyber Security Centre is clear. The Cyber Resilience Pledge asks organizations to make cyber security a board-level responsibility, register for NCSC Early Warning and take a risk-based approach to Cyber Essentials across their supply chains. The NCSC’s Cyber Governance Code of Practice reinforces the point that cyber risk must be governed like any other material organizational risk. The Cyber Security and Resilience Bill will further expand expectations across essential and digital services, strengthening incident reporting and bringing more critical suppliers into scope. This matters because the scale and impact of cyber threats facing the UK are increasing sharply. The NCSC handled 204 nationally significant cyber incidents in the year to September 2025, up from 89 the previous year. That means the UK is now experiencing an average of four nationally significant cyber attacks every week. Policy has therefore changed the boardroom question. Leaders should no longer ask only whether an organization has invested in security tools. They need to ask whether they can prove resilience, evidence accountability and continue delivering critical services when systems are under pressure, suppliers are compromised, data access is disrupted or attackers are already inside the network. Organisational change is creating hidden cyber risk The second force is organizational change. Local Government Reorganisation is redrawing structures and responsibilities across England. Rail renationalization and other shifts in public ownership are changing who owns, manages and secures critical data and systems. Departmental priorities and delivery models are also evolving under a new Prime Minister, with DSIT being dismantled and functions including digital transformation, public sector AI adoption, information resilience and online harms moving into different departments and central government structures. Every one of these transitions creates potential gaps. Systems need to be integrated. Identity and access privileges need to be reassessed. Data needs to move between teams, agencies and suppliers. Contracts and responsibilities need to be redefined. During periods of change, the attack surface expands, and accountability can become blurred. This is why cyber resilience must be built into public sector reform from the outset. The question is not simply how to restructure services efficiently. It is how to ensure citizens can continue to access those services securely throughout the transition. Reorganization without resilience is a risk to the public. Technology change demands continuous assurance The third force is technology change. Public sector work now happens across hybrid environments, shared services, cloud platforms, partner ecosystems and complex supply chains. Traditional security models were built for a more stable world of fixed offices, predictable networks, known users and clearly defined organizational boundaries. That world no longer exists. AI makes this problem more urgent. AI is already being used across the public sector to improve productivity, analyze information and support better service delivery. But without governance, organizations can quickly lose track of which tools are being used, what data they can access and whether sensitive information is being exposed. Shadow AI is not a future risk. It is a present governance challenge. Resilience in this environment requires continuous assurance. Access should not be granted simply because a user is on a trusted network. Every request should be verified based on identity, context, device posture and risk. Users should only receive the access they need, when they need it. Applications should be protected from unnecessary exposure. Data should be segmented so that compromise in one area does not automatically spread across the organization. What public sector boards should do now Making cyber resilience a board-level priority does not mean every director needs to become a technical expert. It means senior leaders need the right governance, evidence and accountability to respond to the three forces reshaping risk across the public sector. That starts with treating cyber resilience as a standing board agenda item, linked directly to service continuity, citizen trust, regulatory exposure and reform delivery. It also requires boards to understand which critical services depend on which systems, suppliers and datasets, where single points of failure exist, and how disruption in one part of the ecosystem could affect citizens’ ability to access essential services. Supply chain assurance must be part of that same conversation. Public services are delivered through ecosystems, so resilience cannot stop at the boundary of a single department, council, agency or trust. Cyber Essentials, supplier checks, contractual obligations and clear incident reporting expectations should be embedded into procurement and contract management. At the same time, public bodies need to move away from implicit trust based on networks or locations and towards continuous verification based on identity, context, device posture and risk. Users should have only the access they need, when they need it, and AI adoption should be governed before it scales so innovation does not create unmanaged routes to sensitive information. Resilience is now a test of public sector leadership The UK’s policy environment has changed. Public sector organizations are changing. Technology is changing even faster. The only way to manage that complexity is to build cyber resilience into the way public services are governed, transformed and delivered. The public sector cannot afford to treat resilience as something to retrofit after legislation tightens, reform programs are complete or AI adoption has already accelerated. It must be designed in from the outset, measured at leadership level and tested continuously. Cyber resilience is not just about protecting systems. It is about protecting the public’s ability to rely on government when policy, organizations and technology are all changing at once. That makes it a board-level priority by definition. More Information on how Zscaler supports public organizations can be found here. Contributed by Zscaler