Linus Torvalds is embracing AI to write Linux kernel code, and some people are having fits. He has a message for them. So do I. Roy Schestowitz, editor of Tux Machines, summed up his reaction to the news as "Linus Torvalds Turns to Slop." In the podcast Pivot to AI, podcaster David Gerard agreed: "Linux kernel goes full AI slop code." Meanwhile, in the Tom's Hardware comments section, commenter "LordVile" wrote: "This is a publicity stunt from his AI overlords [The Linux Foundation] who pay his wage." They followed this by saying this is the "same reason he's flipped-flopped on AI." I've known Linus for a few decades, and I don't take his use of AI as evidence that he's suddenly abandoned his standards. And the very idea that he'd do anything he didn't want to do with Linux on behalf of the Linux Foundation, or anyone else, is ludicrous. I get it, though. There are reasons to be suspicious of AI. I've written about many of them. For instance, AI model collapse, which happens when AI engines learn from other AI models and their ties to the truth fray. It's a very real problem. Not, mind you, that LLMs find the grist for their answer mills from very reliable sources in the first place. Even when AI gets good data, as it does in programming, its owners pay little to no attention to the copyrights and licenses protecting the open source code it picked up its coding tricks from. As for paying for the information it runs on, please! The very idea that Big AI must pay writers, artists, you name it, for using their work is anathema to them. All that said, when it comes to programming, the ship has sailed. AI is becoming part of the programming toolkit, whether its critics like it or not. Why? Because while you still can't vibe code your way into delivering production-quality software, when someone who knows what they're doing, like Torvalds, uses AI, it can be very useful. Anyone who says otherwise is just making the same mistake the Luddites did. Who now, some of you may ask? They were textile workers who attacked machinery in the early 19th century in protest against changes threatening their wages and livelihoods. You may have noticed that while people still weave cloth by hand, industrial production is mechanized. The same is happening now with AI and programming. I think we're about halfway through the process, and by 2030 or so, people programming by "hand" will be about as common as weavers doing it by hand are today. In short, get over it. I don't love it, either. I write for a living, and my business is being crunched too. At least in programming, quality work still counts, no matter how it's done. With writing, though, true AI slop is increasingly the rule, not the exception. Back to Linux: at the Linux Kernel Maintainers Summit in Prague the other week, Sasha Levin, a Linux kernel developer, announced that the maintainers had decided to "deprecate the Assisted-by Tag." That means you no longer need to say if you used AI in your code submissions. That doesn't mean you can turn in slop, though. That code won't pass muster. As Torvalds told me in a note the other day: "I think the whole 'don't use AI for commit messages' kind of argument … Maybe it's well-intentioned, but I think it's entirely misguided. I really think we want competent people to use AI as a tool." Competent is the key word there. Torvalds also wrote: "The 'clueless people using AI' problem is different. I do think we want to discourage that. Not discourage the people who use AI and truly want to learn and truly want to become useful members of the kernel community – but discourage the drive-by patches, and discourage people who just want to feel like they sent a patch and never really wanted to become anything more. We all start clueless, but some people spend the time and effort to become something more." Exactly so. As Torvalds said at Open Source Summit Europe: "I think [vibe-coding is] a wonderful way to find joy in programming. It makes you feel like you're doing something relevant. It allows you, as a new programmer, to do things that you would otherwise have a really hard time with." He added: "I love the concept of AI as a gateway drug" to programming. Besides, AI has already proven very useful for improving Linux code. As long-term Linux kernel maintainer Greg Kroah-Hartman told me back in March: "Months ago, we were getting what we called 'AI slop,' AI-generated security reports that were obviously wrong or low quality." But then, "something happened a month ago, and the world switched. Now we have real reports." It's not just Linux, he continued. "All open source projects have real reports that are made with AI, but they're good, and they're real." True, the maintainers are getting buried in good bug reports now, but as Kroah-Hartman and discussed in Prague, AI bug finders might eventually exhaust the readily discoverable problems, easing the pressure on maintainers. Another AI win is that you can use AI to reverse-engineer Windows drivers for Linux more easily. Christian F.K. Schaller, Red Hat's director of software engineering, created hw-harness while working on a Linux driver for a slide scanner. This open source project provides "tooling for working out how a piece of hardware behaves so that you can write a Linux driver for it." By automating some seriously slow, tedious ways of figuring out what a binary-only driver was doing with the hardware, Schaller has made building Linux drivers from Windows drivers much easier. I know, because I did this myself back in the mid-2000s, and those manual methods are still what people use today. This could go a long way toward fixing one of those lingering annoyances of the Linux desktop: poor or entirely missing hardware drivers. In the meantime, Torvalds told me: "Well, in all fairness, we do clearly have an 'AI problem.' Or rather, we have two independent AI problems: we have a large codebase that AI finds real bugs in, and that adds a lot of work on already fairly overworked maintainers. And then we have people who use AI to generate patches without actually understanding the code in question." He continued: "But I'd argue that these aren't problems with AI itself; they are just problems that are exposed by AI. They are very much both very real problems, and I understand that people can really come to dislike – and even hate – AI due to them, but I do think the underlying issue isn't AI itself." It's how people misuse AI. In the right hands, as the top Linux programmers are showing us, AI can be useful. ®

Britain is threatening subsea cable saboteurs with up to 14 years in prison and unlimited fines, having apparently decided that Victorian-era laws aren't quite up to the job of keeping Russian submarines away from critical infrastructure. The government on Thursday set out plans to overhaul legislation dating back to 1885 and introduce tougher penalties for damaging the underwater cables and pipelines that keep Britain's internet and energy supplies running. According to Whitehall, subsea cables carry around 99 percent of the UK's international data traffic, while underwater pipelines account for 74 percent of its gas supply. Yet much of this infrastructure is protected by laws written when the telegraph was cutting-edge technology. The Submarine Telegraph Act 1885 originally imposed a £100 maximum fine for damaging a cable through culpable negligence. That might have been a reasonable deterrent back then, but it's unlikely to give today's would-be saboteurs much pause. Under the proposals, those who intentionally damage critical subsea energy or telecoms infrastructure could face up to 14 years behind bars. The proposals also set tougher penalties, including unlimited fines, for reckless or negligent damage. Subsea telecoms operators would face new legal duties to identify and manage security risks, while ministers would gain powers to direct companies and cable repair providers to take action where necessary and proportionate to protect national security. The government also wants to regulate fiber-optic sensing technology, which uses subsea cables to detect activity at sea but could pose a security risk if sensitive data falls into hostile hands. Unsurprisingly, Russia features prominently in Whitehall's thinking. In April, British forces exposed a covert Russian submarine operation near critical undersea infrastructure. The operation reportedly involved an attack submarine acting as a decoy while two specialist vessels surveyed Britain's cable routes. "The threats we face have changed dramatically, with suspicious Russian activity around critical undersea infrastructure, yet some of the laws protecting these vital connections date back more than a century," said telecoms minister Ian Murray. The plans aren't entirely new. In May, the government announced its intention to toughen penalties and introduce security obligations for cable operators. Thursday's White Paper spells out the proposed penalties and how far ministers could go in directing operators to act. It also follows warnings from Parliament's Joint Committee on the National Security Strategy, which concluded last year that Britain was insufficiently prepared for a coordinated attack on its subsea infrastructure. MPs and peers warned that government assessments focused too heavily on individual cable failures, rather than what might happen if attackers simultaneously targeted connections to Europe and across the Atlantic. Russian submarines aren't responsible for every severed cable. Fishing boats and ships dragging their anchors do most of the damage, accounting for up to 97 percent of faults, according to previous government estimates. And even when sabotage is suspected, catching those responsible is another matter. Britain already has laws allowing life sentences for serious acts of state-backed sabotage, but they're not much use if nobody can prove who did it. That's rather difficult when the crime scene is at the bottom of the sea. And it might prove equally difficult to extradite suspects from enemy nation states. None of this is law yet. The government has opened a 12-week consultation on the plans, after which ministers will decide how to proceed. Whether the threat of a lengthy prison sentence will trouble Russian submariners is debatable. Even so, after 140 years, Britain's subsea cable laws are finally getting dragged out of the Victorian era. ®

Researchers have developed a new exploit that shows how even Address Space Layout Randomization (ASLR) on an x86-64 server cannot stop the PHP2Shell vulnerability. VulnCheck, which made it available to only the company’s Initial Access Intelligence customers, also warned that threat actors are using AI to find even more ways to attack. The team told us that it’s a “significant advance” because up until now, ASLR has been a major barrier to exploiting PHP2Shell on real-world servers. They don't expect that to hold, though. “Adversaries are clearly spending time (and tokens) on this bug,” Spencer McIntyre, director of exploit development at VulnCheck, told The Register. The PHP2Shell mess grew even bigger on Thursday amid reports of attackers abusing the security flaws days before they were disclosed and UK government websites proactively going dark. Vulncheck's exploit targets CVE-2026-109618, a critical, out-of-memory corruption bug that leads to remote code execution (RCE) in PHP, and part of the PHP2Shell pair alongside CVE-2026-109619. The PHP Foundation officially disclosed and issued patches for both on Wednesday. Overnight, VulnCheck researchers developed what they believe is the first known exploit to achieve remote code execution on ASLR-enabled x86-64 systems with PHP's recommended production configuration. ASLR is a built-in defense against memory-corruption bugs – like PHP2Shell – that randomly arranges memory locations of a program's key data areas. By scrambling these components live, in memory every time a program runs, ASLR prevents an attacker trying to achieve RCE from correctly guessing the target memory address – and thus prevents them from executing malicious code. While VulnCheck has seen “hundreds” of PHP2Shell proof-of-concept repositories on GitHub, “very few contain legitimate, working exploits,” McIntyre told us, adding that this is largely due to ASLR. “There's a significant difference between demonstrating a vulnerability and developing an exploit that can overcome the security protections found in real-world environments,” McIntyre said. “One of the biggest obstacles has been ASLR, a protection designed to make memory corruption vulnerabilities much harder to exploit.” The threat hunters’ new technique, we’re told, bypasses ASLR. It uses a confirmed memory leak chained into RCE on PHP 8.4.26, and they claim it works on x86-64 platforms even with ASLR enabled and PHP’s recommended display_errors=off production configuration. “We haven't identified another public or commercial exploit that achieves this under the same conditions,” McIntyre said. “Developing this capability was far from trivial, but it demonstrates that a major barrier to exploiting PHP2Shell on production-configured systems can be overcome.” VulnCheck says it also works on ARM64, but the RCE is not currently functional on ARM-based systems. This should be a wake-up call to all organizations that, especially now in the era of AI bug hunting and exploit development, “the technical difficulty of exploiting a vulnerability shouldn't be confused with protection against it,” McIntyre said. “Organizations running vulnerable versions of PHP should prioritize patching rather than assume existing memory protections or configuration changes will stop an attack.” ®

GitLab on Wednesday patched a maximum-severity flaw that could allow unauthenticated attackers to execute arbitrary code on self-managed servers under certain conditions. Affected software releases date back a full 12 years - so upgrade to a fixed version now. The integer overflow bug, tracked as CVE-2026-110264, affects regular-expression compilation in GitLab Community Edition (CE) and Enterprise Edition (EE), including versions dating back to GitLab 7.0, released in June 2014. The flaw, “under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression,” the vendor said in its release notes. GitLab released fixes in versions 19.5.1, 19.4.3, and 19.3.6, and backported the patch to versions 19.2.9, 19.1.9, 19.0.10, and 18.11.13. The vendor “strongly recommends” that all organizations running vulnerable software upgrade to a fixed version “as soon as possible.” GitLab-managed infrastructure, including GitLab.com and GitLab Dedicated, remains patched, and the vendor also released two threat detections (here and here) for customers with self-managed instances. Bug hunter Johan Carlsson reported the vulnerability through GitLab’s HackerOne bug bounty program. “For organizations running self-managed GitLab infrastructure, the potential impact is severe,” warned threat-detection firm SOC Prime. “GitLab repositories frequently contain source code, CI/CD configuration, deployment secrets, access tokens, infrastructure definitions, and connections to production environments. Server-level compromise could therefore create opportunities for credential theft, repository manipulation, supply chain attacks, persistence, or lateral movement.” While there’s no indication - yet - of any in-the-wild exploitation attempts, we’d expect criminals to start scanning for vulnerable instances soon. The ongoing PHP chaos may have given defenders a short head-start on this one, but considering the perfect 10 CVSS severity rating and GitLab’s reach into the enterprise - it claims 50 million registered users and more than 50 percent of the Fortune 100 - that’s not going to last long. Last month, attackers started battering another max-severity flaw in the same GitLab CE and EE products just days after the vendor issued a patch, according to the US Cybersecurity and Infrastructure Security Agency and private researchers.®

After embarrassing reports revealed weak private keys, one of which was just a single digit, Indian certification authority eMudhra has decided to take the L and get out of the global SSL/TLS cert game entirely. eMudhra announced Thursday that it was abandoning that arm of its business. Sure, the intense scrutiny heaped on the company was a factor, but the firm also argued that growing compliance costs and competition from free certificate providers had made the business increasingly difficult to justify. “Global SSL/TLS is a small part of eMudhra’s business contributing to about 1 percent of the global revenue,” the company explained, noting that free SSL/TLS cert issuance from large firms and increased compliance and data sovereignty requirements have made it a minor part of the firm’s operation, and one that doesn’t merit so much bad press. “The level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business,” eMudhra explained. “In view of this, after detailed deliberations our board has concluded that withdrawing from global SSL/TLS is the right decision for eMudhra and its shareholders.” An argument could be made that, even if SSL/TLS accounts for just 1 percent of its global revenue, a private CA key with a value of 4 still deserves a thorough public shaming. It’s only been two days since eMudhra’s weak private keys were exposed in public reports, following a report to Mozilla on October 17, and it wasn’t exactly hard for security researchers to recover them: The eight affected private-key values ranged from the number 4 (yes – a plain old number 4), to 56 and 66, to the far more complicated 115, 155, 156, 230, and 237. No quantum computer required to crack those keys. Wow – better save the qubits. This wasn’t just an embarrassing collection of numbers, either: The weak keys belonged to eight intermediate certificate authorities, potentially allowing attackers to forge certificates trusted by systems that hadn’t blocked them. eMudhra, however, maintains that the affected CAs had issued no end-entity certificates. eMudhra quickly went on the defensive about its mind-boggling key-management failure, acknowledging the weak keys while pointing to independent audits and a problem during its key-generation ceremony that it said produced the weak keys alongside the intended strong ones. “A flaw in the key generation ceremony caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys,” the company said the day after the key fiasco was reported. “The weak keys were the ones published to the browser root stores.” Despite that, eMudhra said the relevant certificate infrastructure had undergone two years of independent audits and had been in browser trust lists since mid-2025, raising questions about why the weak keys weren't caught sooner. eMudhra claimed on Thursday that the affected CAs had issued no end-entity certificates, that it had revoked those CAs within 14 hours of discovering the issue, and that neither its infrastructure nor its data had been compromised as a result of its key boo-boo. Still, the incident has given eMudhra another reason to shave off a small part of its business rather than continue facing scrutiny over its certificate operations. It’s still going to issue a root-cause report and fulfill its remaining commitments to browser root programs as it winds down the business. The company said it’ll continue to serve G1 RSA roots until it transitions customers to other certificate issuers, which it will do free of charge. “Revocation and certificate status services will keep running until every issued certificate has expired or been replaced,” the company said. ®

The PHP2Shell security fiasco has forced 32 UK government services offline and left another four partially unavailable as Whitehall scrambles to patch the critical vulnerabilities wreaking havoc across the web. The figures were disclosed in the House of Lords on Thursday, where tech minister Baroness Lloyd of Effra outlined the disruption following the discovery of two critical flaws in PHP. "Currently, the information I have is that 32 government services are unavailable and four are partially unavailable," Lloyd told peers. "That has resulted largely from precautionary measures taken to protect systems while security updates and mitigations are applied." "We are working very carefully with departments to restore the services safely and securely following that remediation activity," she added. Whitehall has not published a full list of affected services, although the Office for Budget Responsibility (OBR) is among those known to have taken their websites offline, rather inconveniently with next week's Budget looming. Peers also raised reports of disruption affecting the DVLA and police services. Britain isn't alone in pulling the plug. Government websites in Germany, France, Belgium, Finland, and the Netherlands have also been taken offline as a precaution, along with Australia's own cybersecurity agency website. Across the Atlantic, the NSA has urged organizations to patch or disconnect vulnerable systems, although the US government has not publicly confirmed any website shutdowns. PHP2Shell comprises two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that could allow unauthenticated attackers to execute code on vulnerable servers. The National Cyber Security Centre (NCSC) warned organizations to patch immediately or consider pulling affected systems offline until they could be fixed. "The NCSC was briefed by OpenAI last week on this potential specific vulnerability and has been working to ensure that disclosure happened in a co-ordinated way with vendors, so there was sufficient preparation to protect customers," Lloyd said. Security firm Calif found one of the PHP bugs using OpenAI's GPT-5.6 Sol model, while Google's Wiz separately uncovered both flaws with the help of AI tools. OpenAI then dug into the vulnerabilities itself and worked with vendors and government agencies to get the word out. The government established a cross-departmental incident response operation before public disclosure, Lloyd said. The NCSC also sent 50,000 warnings to businesses and other organizations. The disruption has spread beyond central government. Liberal Democrat peer Baroness Ludford pointed to several councils whose services had reportedly been taken offline, including Edinburgh, Oxford, Bristol, Lambeth, and Barnet. She questioned why central government and local authorities remain outside the statutory duties proposed under the government's Cyber Security and Resilience Bill, which returns to the Lords on Monday. "We are not currently aware of any confirmed compromise of central government systems resulting from these vulnerabilities," Lloyd told peers, later extending that assessment to the wider UK public sector. AWS says attackers were exploiting the flaws four days before they were publicly disclosed, while Cloudflare has since recorded millions of attempts to weaponize them. ®

In a world full of cyber risk, account takeover has emerged as one of the most insidious of all threats. If an attacker can successfully compromise a legitimate email account, they are then able to pose as a trusted individual or organization without triggering any warnings. Traditional email security will see nothing wrong. From there the threat actor can pick their moment to cause havoc with objectives that range from stealing money, expropriating sensitive data and propagating catastrophic malware. Serious financial loss and a damaged corporate reputation are commonplace outcomes. The typical account takeover lifecycle starts with the bad guys obtaining credentials, usually through the medium of phishing. Generative AI (GenAI) has made it easy for an attacker to trick an unwary individual into giving away login data, perhaps by posing as a colleague or other trusted party or by encouraging them to enter confidential information on a fake login page. You might expect, once a legitimate identity has been successfully compromised, that all hell would immediately break loose. These days the typical account takeover artist is more stealthy and sinister than that, in no rush to act at this early stage since no alarm bells have been triggered. Most will take their time to test out and verify their stolen login data, and see where it might take them. “Conventionally attackers would take over an account and immediately start firing off spam and phishing,” says Dave Baggett, SVP Cybersecurity with software developer Kaseya. “Now they are starting to get clever. They’ll get access to an account and sit tight, watching all the email traffic passing and waiting for an opportune moment to inject themselves into the conversation.” From the inside out Once they’ve figured out an organisation’s weak points and come up with a plan of attack, the bad guys will start to weaponize the compromised email account to target other employees and internal systems. Assuming their motivation is financial, they might be on the hunt for a way into payroll or invoicing databases. But their ultimate aim might lie further afield in the form of the organisation’s customers and suppliers, and that’s when the real nightmare can start. So called outbound phishing offers the criminal a way to assert control over a whole new range of sensitive end points. Victims of outbound phishing are highly vulnerable in the face of what seem to be messages from a trusted partner and ally. It is one thing for an organisation to protect its own email accounts with robust controls like multifactor authentication (MFA), but no one has control over the authentication practices of other parties: “Let’s say we have a customer who we’re protecting,” explains Baggett. “They’re safe, but imagine that they start getting suspicious emails from a third party. Our customer has no idea what is or isn’t protecting that third party. Emails coming from that source might appear to be from a real account, but it could be a hacker typing them.” Given that you can’t run checks on third party organisations, something more sophisticated than regular email security is required. Ideally this would be a GenAI-powered solution that can bring language understanding to bear, able to examine conversation histories in depth to see if something anomalous can be spotted. It makes life even harder for defenders when the bad actor has successfully assumed the identity of somebody senior. If they are impersonating a top-tier manager with an extensive and trusted reputation then they have a powerful asset on their hands. All the trust and goodwill of that senior individual is now inherited by the criminal. Conventional email filtering systems will often be configured to allow senior personnel past certain defensive layers with minimal friction, so as not to restrict important business communications. Recipients of mail from such sources may be disinclined to challenge and report them, should suspicions be raised by the nature of what they are asking for. It takes a bold employee to call out as fraud what seems to be a message from somebody at C-level, especially when the email system has apparently green lighted it as authentic. Bringing the power of AI to bear The heat is on not just for IT departments but for MSPs who have multiple organisations under their protection, many of which will have no real in-house security knowledge of their own. Kaseya’s own research shows just how exposed many are. New approaches are needed that deal with the menace of account takeover before damage can be caused. And should a takeover transpire, consideration must be given to containing its impact before vital data and infrastructure are affected. The good news is that modern tools exist that perform just these tasks. INKY is Kaseya's generative AI-driven email analysis tool. It has capabilities that go well beyond any kind of traditional email security, tuned to detect, through the most subtle and marginal signs, when an email conversation is in the process of being infiltrated. Using techniques such as advanced sender profiling, stylometry and machine learning, INKY is adept at identifying inconsistencies between the known writing patterns of a legitimate employee and the slightly unfamiliar tone of a fake message. It can sniff out that something is wrong, even when message headers seem real, just by spotting the kind of contextual anomalies that expose a phoney message. INKY is especially useful when it comes to third party account takeover. It achieves this by building and maintaining detailed profiles of trusted senders based on technical and behavioural characteristics. Over time it learns what “normal” looks like and can see when a third-party email doesn’t match a sender’s established profile. Containing an attack If a takeover attempt has been successful, there’s more to stemming the damage than just putting a block on a suspect account. By the time of its discovery, a compromised identity may have already led to inroads being made into connected SaaS apps, cloud storage and collaboration tools, widening the possible blast zone well beyond a single email thread. Modern IT environments are a jungle of identity-driven endpoints and gateways, and therefore increasingly difficult to defend against intruders armed with legitimate credentials. To compound matters, when the bad guys have AI at their disposal they are able to treat these SaaS-driven ecosystems as a single attack surface. Defence that relies on a patchwork of individual tools, each created to solve a particular challenge in one silo of the organisation, will not be up to countering this kind of threat. That’s why INKY is configured to work with Kaseya SaaS Alerts, a cloud-based detection and response platform designed to help MSPs and others to monitor and protect business applications. Once INKY has picked up that a mailbox has been hijacked, it isolates the user and blocks outbound mail. It then sends an event to SaaS Alerts so that it can lock down that user's access across the rest of the stack. The tools work as a team, INKY blocking the compromised account and SaaS Alerts preventing the damage from spreading. The power of this partnership comes from INKY’s ability to stream real-time email security telemetry into SaaS Alerts, including inbound analysis results and threat detections, user-reported phishing activity and outbound mail protection events. This type of integration helps to automate real-time threat detection across a complex SaaS ecosystem. “It means if we see suspicious mail going out, we can shut the account down, and take other remedial actions,” says Baggett. “The more you understand the meaning of the mail, the more you can catch.” Smart tools to the rescue The battle against account takeover is never won, and future innovation is always needed. We’ve seen how AI is a dangerous weapon in the hands of the attacker. It’s also a very handy tool for the defender – but there are some qualifications: “You can’t just put every inbound and outbound mail through an LLM since the economics don’t add up,” points out Baggett. “You’ve got to be more clever than that.” One of the most important and cleverest emerging uses for GenAI lies in not simply protecting against account takeover but predicting where weakness might lie, helping to stop a problem before it happens. Baggett believes that the security industry is at the very beginning of being able to use models to predict in this way. An essential preliminary is making sure the many different components that go into securing an organisation can share information with each other. That integration work is underway, an early example being the real time dialogue between INKY Mail Protection System and SaaS Alerts. Next step is a unified data layer where any security component can publish an event in real time, and any other component can subscribe. “We’ll continue to make more integrations of this sort over time,” promises Baggett. “We’re also building a centralised capability for AI. With so many of the different components having their own AI, you need an underpinning platform. We also have a service bureau of Machine Learning experts who can make customised models for different tasks. There’s no sleeping on the job. The volume of attacks is clearly going to increase.” Read more in Kaseya’s Cybersecurity Report here Sponsored by Kaseya

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. ®