News

The UK's second largest supermarket is tripling the number of stores that use facial recognition to try to clamp down on shoplifters – a move privacy campaigners are branding as "shameful." Sainsbury's first trialed the tech at premises in Sydenham and Bath Oldfield Park from September last year, before deploying it to shops across London earlier in 2026. More than 55 Sainsbury's supermarkets use the technology. Facial recognition will be extended to up to 200 stores by the end of 2026, according to Sainsbury's, which claimed that 90 percent of people identified through the system did not return to the store. The Sainsbury's system is provided by Facewatch. Other customers include supermarkets Budgens, Costcutter, Southern Co-op, and Spar, as well as retailers B&M and Sports Direct. Big Brother Watch said the deployment is among the biggest expansions of facial recognition "surveillance" in the UK and has "very serious consequences for our privacy rights." It urged shoppers to take their business elsewhere. Director Silkie Carlo said the campaign group was being contacted by more and more shoppers trying to clear their names after being subjected to "serious facial recognition mistakes." Earlier this year at a Sainsbury's branch in London's Elephant and Castle, Warren Rajah, a sales employee at tech reseller CDW, was wrongly booted from the premises after staff apparently responded to an alert for a different person on the system's watchlist. Rajah talked of public "humiliation" and asked: "Am I supposed to walk around fearful that I might be misidentified as a criminal?" Sainsbury's told The Register at the time it had apologized for the mishap and promised to further train staff on the use of the tech. "This was not an issue with the facial recognition technology in use but a case of the wrong person being approached in store," it said. Carlo said: "Innocent shoppers should not have to submit to Orwellian identity checks just to buy a loaf of bread or pick up nappies. The mass rollout of live facial recognition across Sainsbury's stores is a shameful decision that treats customers like suspects, putting millions of law-abiding people at serious risk of privacy intrusions and humiliating false shoplifting accusations. "Sainsbury's and the police can legitimately target shoplifters but have no right to take face scans from millions of ordinary customers. Sainsbury's should halt its decision to roll out live facial recognition immediately and listen to customers' concerns." The Register has asked the supermarket to comment. Use of facial recognition is also expanding in policing across Britain despite longstanding concerns over bias and false positives. ®

Data on more than 2.3 million people associated with Moody Bible Institute (MBI) has been exposed online after the Christian college was targeted by ShinyHunters. The attack was first disclosed by MBI in June, and the extortion crew later leaked the stolen data. Have I Been Pwned has since added the cache to its breach notification database, putting a figure on the number of exposed accounts. MBI is one of many victims of ShinyHunters' pay-or-leak attacks in 2026, and while the organization has not explicitly commented on whether it negotiated with the criminals, the leak suggests that the group's extortion demands were not met. Broadly consistent with ShinyHunters' claims, the MBI data made available for download on June 23 includes names, genders, dates of birth, physical and email addresses, phone numbers, and marital statuses. The cache also included documents concerning donor relations, MBI's supporters, students, and alumni. MBI has not spoken publicly since June 22, the day before ShinyHunters leaked its files. The organization stated that its tech team had addressed a vulnerability and brought in external cybersecurity experts to help with its incident response. It urged those affiliated with MBI to monitor their accounts and make use of free credit freezes and fraud alerts until it had completed its investigation. "Throughout this process, we are grateful for the Lord's faithfulness and for the dedicated teams and outside experts working tirelessly to protect our ministry and those we serve," said MBI. "We are confident that God remains sovereign over every circumstance, and we trust Him to grant wisdom and discernment as we navigate this situation together." MBI has various operations, or "ministries." Chief among them is its university, which offers undergraduate, graduate, and online courses for those pursuing ministry work. It also offers aviation courses with a theology component. More than 250,000 students have studied at MBI since it was first established in 1886. It also runs Moody Radio, a Christian radio network/station, and a publishing arm devoted to Christian literature. ShinyHunters' leak site lists 86 victims since January, although the number for the year is likely higher, since those who paid extortion fees would be removed from the list of breached organizations. The group has been linked to high-profile attacks involving Salesforce, Carnival, and Pitney Bowes. The gang has also claimed that a Oracle PeopleSoft campaign affected more than 100 organizations, and cited a PeopleSoft breach in the details about its attack on MBI. National security alerts were issued about ShinyHunters earlier in the year following its attack on learning platform Canvas, which compromised the data of an estimated 275 million students. ®

For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago, in an email to its mailing list, TUHS founder Warren Toomey announced the addition of KSOS to the collection. "KSOS was the US Department of Defense (DoD) Kernelized Secure Operating System (KSOS, formerly called Secure UNIX). KSOS is intended to provide a provably secure operating system for larger minicomputers," he wrote. Despite its age, KSOS sounds surprisingly modern. It was a Unix-compatible OS, implemented in a type-safe programming language, Modula, rather than C. Modula was the late great Niklaus Wirth's successor to Pascal and, in turn, the forerunner to Modula-2 – which we described when it was added to the GNU Compiler Collection in 2022. KSOS was designed to be formally verifiable, so that it could be trusted for use in highly secure systems. It ran on commodity hardware, and its development was sponsored by the US DOD. Very few OS kernels have been formally verified, and one of the best-known modern examples is the seL4 microkernel, as used in the Ironclad OS we covered last year, and also in the new QSOE RISC-V RTOS. KSOS isn't some cutting-edge experimental new Rust effort, like the Asterinas project we described last year or the even newer Maestro project. What became KSOS started in 1978 at Ford Aerospace (yes, that Ford). On the team were Peter Neumann, who later ran the RISKS Digest – The Register was quoting him in 2004 – and Tom Perrine, who described it and its modern relevance in a 2002 article for the USENIX journal ;login:. It's titled "The Kernelized Secure Operating system (KSOS)" [PDF], and at only three and a bit pages long, it's well worth a read. Even then, 24 years ago, projects were struggling to reinvent things KSOS did successfully a couple of decades earlier. That's even more true today. To learn more about how KSOS worked, there's a 1978 Executive Summary [PDF] – which, despite its title, runs to 15 pages. Clearly, executives back then had longer attention spans. Perrine gave a talk about KSOS at DEF CON 20 in 2012, which you can watch on YouTube. KSOS isn't forgotten. For instance, it came up in a talk at last year's FOSDEM: Confidential Computing's Recent Past, Emerging Present, and Long-Lasting Future. Page 8 of the slide deck [PDF] says KSOS was "among the first security-focused kernels, emphasizing formal verification" and "source code was publicly available, rejecting 'security through obscurity.'" KSOS was not confined to academic research. It was used in production. Last October, Perrine explained more in another TUHS email: "KSOS – for PDP-11, originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor-mode UNIX-system-call-compatible system. Later, there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. "KSOS was used in the Trusted Downgrade System of the multi-level-secure 'all-source' intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. "KSOS-32 – a VAX 'port' of KSOS (which was then retconned as 'KSOS-11'). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were rewritten as needed. "I worked on both systems at Logicon." It's Perrine we have to thank for KSOS reappearing in public view after 38 years – he found an old tarball of the source code, and with the help of John O Goyo and Thalia Archibald, it made its way to the TUHS code archive. Now there’s a new quest: find the original compiler used to build it. One thing that may help slightly is that KSOS was not self-hosting: it was compiled under UNIX. We have mentioned TUHS's important work before: for instance, when a tape of UNIX V4 was found in University of Utah boffin Robert Ricci's department — and successfully recovered. Bootnote Mr Goyo also found time to email The Reg FOSS desk about the recovery, for which we thank him. ®

OPINION I write a weekly column called PWNED, about how poor security practices can lead to serious damage. Usually, there’s something funny in the malfeasance, like a CEO who kept every employee’s password in an Excel file on his desktop. However, I wasn’t laughing back in May when professional thieves invaded my 84-year-old mother’s entire financial life and managed to make off with $30,000 from her bank accounts alone. And they wouldn’t have gotten in if her financial institutions required multi-factor authentication (aka MFA or 2FA), a step too many institutions won’t take. One day in May, Mom got a call from the institution that runs her retirement savings account, who had identified a suspicious transaction and asked her if it was legit. She said no and they immediately protected her account. Then she checked her bank account at a different institution to see if it was compromised and found thousands of dollars transferred out of her checking and savings accounts. The thieves knew exactly how much they could withdraw each day, and used both withdrawals and transfers to a strange account. But the financial institution hadn't flagged the fraudulent activity. The thieves were so slick that they broke into her Gmail account and created spam filters to filter any mail from her bank or retirement savings provider to the trash so she wouldn’t get alerts about the transfers or about the fake accounts they made in her name. She spent hours on the phone reporting the theft to an unhelpful and incredulous fraud department who asked “Are you sure a relative didn’t do this?” We don’t know for certain how the crims got into my mom’s accounts, but we know she used the same or similar passwords on all of her accounts, and at least one of her accounts was part of a data breach a few years ago, so that info was probably available somewhere online. The miscreants then could have used this info to get into her retirement account, her bank, and her Gmail. None of this would have been possible if she had MFA enabled on those accounts, but neither Google nor her financial institutions require it. “Many consumers assume every bank requires 2FA, but that's not the reality,” said Gregory Shein, CEO of Nomadic Soft, a SaaS company that serves fintech clients. “Some financial institutions still treat it as an optional feature because they're balancing security against friction. Every extra login step can reduce conversions, increase support tickets, and frustrate less technical customers.” Indeed, while some banks such as PNC require MFA, others such as Bank of America, Chase, Capital One, and Citibank leave it as optional. Google’s accounts are also MFA-optional. Fortunately, after they spent hours telling my mom that someone in her family could have done the deed, and repeatedly putting her on hold, then forcing her to navigate a labyrinthine phone tree, the bank eventually agreed to investigate. A few weeks later, they restored the stolen funds. A not entirely happy ending My mother was lucky, because if money is stolen from your bank account, there is no guarantee that you will get it back, at least in the US. According to the Consumer Financial Protection Bureau, you have 60 days from the date of a bank statement to dispute any transactions. The bank also has 45 days to investigate, unless your bank account was just opened in the last 30 days or the fraudulent transactions took place outside the US. But the bank could very well decide that those fraudulent transactions look legitimate and refuse to reimburse you. If the bank doesn’t agree to reimburse you, your next step is to get a lawyer and attempt to sue. A quick search revealed dozens of lawyers in my area who specialize in dealing with this problem. It would be easy to blame my mom for being robbed. Using the same password in multiple places left her wide open for exploitation. However, her bank’s lack of a required second authentication factor also contributed. The bank doesn’t let you transact without a password, and it doesn’t issue you an ATM card without a PIN, because it knows that there has to be a required minimum level of security. Banks and other financial institutions know better. Google knows better. But they’re all putting convenience ahead of security when it’s your money that’s on the line. “Different segments of the population adopt technology faster or slower. If I’m a bank, I have to consider that very closely because I don’t want to lose any banking relationships.” Andrew Shikiar, CEO of the FIDO Alliance, an industry association that advocates for stronger login security, told me in an interview. “So I think there’s some concerns around friction that have held some banks and other service providers back from really pushing this more aggressively.” How effective is MFA? According to a 2019 article from Microsoft, MFA prevents 99.9 percent of attacks on your accounts. However, other experts say this number is exaggerated, as there are many ways to get past MFA if you’re a criminal, including social engineering and interception. One of the most common types of MFA, issuing a one-time passcode via an SMS message or an email, is inherently flawed. A determined thief can use social engineering to get a SIM card with your phone number on it, then get to your texts. And if your email itself isn’t perfectly secure and it is receiving an OTP, they can get to that too. Phishers can also trick you into giving up your OTPs by creating a fake website that looks like your bank’s login page. The right way to do MFA today is with a passkey. Passkeys are cryptographic key pairs where there’s a private key on the user’s device and a public key on the server. To access the key on the device, the user must either enter a PIN, touch a physical security key like a Yubikey, or enter a biometric login such as their face or fingerprint. Passkeys cannot be phished or intercepted, which is why they are known as “phishing-resistant MFA.” Unfortunately, a lot of banks are sticking with their OTPs. For example, when I went to set up MFA for a family member’s account with US bank Chase, using its website. Chase offered the chance to receive an OTP via email, SMS, or a phone call. The bank is rolling out passkeys, according to the FIDO Alliance. So are Wells Fargo, US Bank, and Bank of America. Some banks may be using better MFA only within their mobile apps. Chase’s app, for example, asks users to use a fingerprint or facial recognition at login, even though the website does not. However, if a thief wants to log in at Chase's website, there will be no biometric challenge. And if a user doesn’t have MFA enabled at all, it’s even easier for thieves to get in. “OTP is just another password. So it’s a shorter-lived one, but it really is just another password,” Shikiar said. “And there’s also usability issues. You’re juggling between your mobile and your desktop. It’s insecure, inefficient, and a really inadequate user experience.” What banks don’t seem to understand is that you’re only as secure as your weakest entry point. If security controls only exist on mobile apps, it doesn’t help with web-based attacks. If a level of security is optional, the majority of people won’t enable it. Thieves will take the path of least resistance, so service operators need to lock down all entry paths equally by default. Unfortunately, an approach that favors convenience over security will lead to a lot more people losing their money. And, ultimately, banks will lose money when they have to reimburse people for those fraudulent transactions. “I don't expect banks to be mandating passkeys and only passkeys for some time, but the more they push them, the more comfort there is,” Shikiar told us. “The sooner we’ll get to that point where it becomes a de facto default and then becomes really something that's either required or essentially required.” That time should be now. ®

Vendors are trying to position "confidential computing" as the technical backbone of Europe's sovereign cloud ambitions. But new research shows that a security protocol used to prove cryptographic trust in the system may have a fundamental architectural flaw. Confidential computing rests on a mechanism called remote attestation, in which a server cryptographically proves to a client that it is running inside a genuine, unmodified Trusted Execution Environment (TEE) before any sensitive data changes hands. Intel's product pages promise TDX will "add safeguards to data sovereignty and governance." Google Cloud describes its confidential computing infrastructure as offering "full, auditable control over access to customer data." In May, The Register reported that the chip beneath the chip, the management engines running below the operating system on Intel and AMD silicon, falls outside what European sovereignty frameworks like SecNumCloud actually assess. That left an open question about the layer above the silicon: the protocol meant to prove the chip itself can be trusted. New, independently verified research answers it, and the answer is not reassuring. A protocol that promises more than it proves Muhammad Usama Sardar, a researcher at TU Dresden, has spent the past two years formally verifying whether that protocol, known as attested TLS, actually does what it claims. Using ProVerif, a tool for the symbolic security analysis of protocols, he and his co-authors discovered that it largely does not. Their recent paper, Identity Crisis in Confidential Computing, published with co-authors Mariam Moustafa and Tuomas Aura and presented at the AsiaCCS 2026 conference, found diversion attacks against two state-of-the-art attested TLS protocols. A connection intended for one server can be silently redirected to a different, compromised machine running identical software, anywhere in the world, without the client ever knowing. The intended server has done nothing wrong. The attacker simply exploits the fact that the protocol checks the software's integrity, not its location. The most recent paper, Intra-handshake.fail, published with co-authors Viacheslav Dubeyko and Jean-Marie Jacquet and accepted for ESORICS 2026, goes further. It examines what the industry calls intra-handshake attestation, where evidence is generated during the TLS handshake itself, and tests seven different ways of cryptographically binding that evidence to the underlying connection. None of them prevent relay attacks, in which a client verifies the evidence of a genuine, trustworthy AI agent or server but ends up encrypting its traffic to an entirely different, malicious one. The starting assumption in all of this is that the hardware itself can be trusted. "In confidential computing, you have to trust the hardware manufacturer anyway," Sardar told The Register. "There is absolutely no way around this." With that root of trust accepted, he argues, the protocol layer was supposed to provide everything else. His research shows it provides far less than assumed. Three levels of trust The researchers formalise the problem as three increasingly strict levels of cryptographic binding between the attestation evidence and the actual TLS connection it is meant to vouch for. The weakest, level one, ties evidence only to the very first key exchange in the handshake, the Diffie-Hellman step, where client and server agree on a shared secret before either side has proven who they are. Level two ties it to the client's handshake traffic key, covering everything up to the server's identity confirmation. Level three, the strongest and the one that matters most in practice, ties evidence to the application traffic key itself, the key actually used to encrypt the sensitive data a client sends once the connection is live. Sardar's extensive analysis in ProVerif focused on intra-handshake attestation; post-handshake attestation fell outside its scope. Three of the seven binding mechanisms examined achieve level one. The rest fail even that baseline. His team's own proposed mitigation, a cryptographic binder built from the TLS handshake secret combined with the server's public key, formally achieves level two. Level three, the paper concludes, "may not be possible" within intra-handshake attestation as currently architected, without breaking properties of TLS 1.3 that the protocol was never designed to give up. In plain terms: the best fix available today proves a client is talking to the right machine at the start of a handshake. It cannot prove that the data sent minutes later is still going to that same machine. Production systems, not laboratory proofs of concept The vulnerability is not confined to academic models. Sardar's team formally analysed four real-world implementations of intra-handshake attestation: Meta's Private Processing system for WhatsApp, Edgeless Systems' Contrast, the open-source Cocos AI platform, and a proof-of-concept maintained by the Confidential Computing Consortium's (CCC) Attestation Special Interest Group. The first three of the four are running in production today. The attacks apply to every version of Cocos AI between 0.4.0 and 0.8.2. The class of flaw itself is not new. Sardar's team notes the attacks are subtle enough to have gone undiscovered for years before formal analysis caught them. The responsible disclosure resulted in CVE-2026-33697, rated 7.5 on the Common Vulnerability Scoring System, high severity. For comparison, the researchers note in their paper that BadRAM, the 2024 memory aliasing attack against AMD's SEV-SNP that made headlines in its own right, scored 5.3. The CCC Attestation SIG's repository lists CVE-2026-33697 as the highest-scoring vulnerability among a cluster of recent confidential computing flaws, ahead of Fabricked (5.9), BreakFAST (5.9) and Staleus (4.0). The working group and the IETF's TLS working group have both formally acknowledged the relay attacks. "As implemented today, attested TLS is not mature yet," Sardar told The Register. "We are investigating further, and we are confident there are more issues yet to be discovered." What makes the finding more pointed is who missed it first. Meta commissioned an extensive security review of its WhatsApp implementation from Trail of Bits, a well-regarded security firm, before Sardar's team examined it. That review did not detect the relay attack. It is methodology, not incompetence, that explains the gap. The ESORICS paper records that Sardar's team contacted Trail of Bits directly, who confirmed no formal methods were used in their review process. Formal verification tools like ProVerif check a protocol exhaustively against every scenario a defined threat model allows. A manual audit, however thorough, samples. A subtle flaw in how evidence is bound to a connection can slip past a sampled review and still be provably broken under exhaustive formal analysis. The Attestation Special Interest Group of the CCC, which governs the adopted proof-of-concept project Sardar tested, found its own system vulnerable to the same relay attacks. A repository nobody would create The vulnerability itself had already been through a lengthy, orderly disclosure process. Sardar's team flagged it to Cocos AI in October 2025, the vendor acknowledged it two months later, and the CVE was published in March 2026. What happened next was different. On 14 June, Sardar wrote to the chairs of the CCC's Attestation Special Interest Group requesting a new public GitHub repository, named relay-attacks-in-intra-handshake, so his formal analysis artefacts for the relay attacks could be released under an Apache 2.0 licence, for use by researchers and the standardization community. He referenced an existing, adopted project under the same group's governance, the kind of administrative step that, on paper, should take minutes. Three days later, on 17 June, he sent a reminder. The following day, a second, noting the artefact link was needed for the paper's final version. On 24 June, ten days after the original request, he wrote again, this time without the diplomatic padding: "I do not see a good reason for such a delay, since the requested repo is part of an adopted project and creation of a new repo is not such a time-consuming task." The new repository still did not exist. The CCC's Attestation Special Interest Group is made up of representatives from the hardware and cloud vendors whose products the research concerns. That fact requires no embellishment. A working group populated by the companies whose attestation implementations were just shown to be vulnerable to relay attacks did not act, for over a week and across three written reminders, on a request to publish proof of that vulnerability. Since no repository had been created before the paper's final version went to the publisher, Sardar published the artefacts anyway, but inside an existing CCC-affiliated repository rather than the dedicated one he had asked for. He told The Register the repository had originally been built for an unrelated project: "Since the monopoly [of vendor-dominated working groups over this infrastructure] continues, we have released the artifacts to inform the community and for researchers to analyse it independently." The CVE stands regardless, credited and public. The delay changes nothing about the underlying mathematics. BSI reaches the same verdict None of this requires taking Sardar's interpretation on faith. A world away from the IETF mailing lists, Germany's Federal Office for Information Security (BSI) arrived at a closely related conclusion through its own, entirely separate channel. Carina Hilt, deputy press spokesperson at BSI, was asked directly about confidential computing's role in digital sovereignty. She told The Register the technology functions as "a defense-in-depth component," strengthening tenant isolation and protecting confidentiality and integrity, but not availability. Crucially, she added that "dependencies on other services, such as identity and key management etc., are also not mitigated by CC." That is, in other words, an institutional echo of exactly the gap Sardar's protocol analysis exposes: confidential computing's guarantees stop well short of guaranteeing who actually controls the keys and the identity infrastructure a deployment depends on. Pressed further on vendor marketing claims, BSI did not soften its position. "The vendors' positioning on CC might give too much weight to its technical capabilities," the spokesperson told The Register. "CC alone cannot satisfy the requirements for digital sovereignty." What the chipmakers say Mikael Moreau, Intel's France Communication Manager, was asked specifically about the attestation infrastructure underpinning its TDX confidential computing technology, and whether Intel's own role in that infrastructure constitutes a dependency. He said the company does "not consider its attestation infrastructure to be a limitation to sovereignty guarantees," arguing that any reliance on Intel's silicon and certificate root of trust is "bounded." Intel is not in the customer's workload data path, does not receive customer plaintext through attestation, and the operational trust decision can be delegated to an independent verifier or retained by the customer. That is a carefully constructed, technically defensible answer. It explains the architecture, not the law. Intel was asked whether its attestation infrastructure poses a sovereignty risk under RISAA, the 2024 US law that can compel hardware manufacturers to cooperate with secret intelligence orders. That question went unanswered. Google did not respond to a request for comment for this article. Acknowledged everywhere except the sales pitch Sardar's findings prompted four different institutional responses. The IETF's Secure Evidence and Attestation Transport (SEAT) working group, formed after a group including Sardar successfully argued for it at a Birds of a Feather session at IETF 123 in Madrid in July 2025, wrote his correlation properties directly into its charter as an explicit, mandatory requirement for any new specification work. That is a standards body doing exactly what it should, building formal verification into the process rather than bolting it on afterwards. The IETF's TLS working group formally acknowledged the same attacks, without adopting a binding requirement of its own. The CCC's inaction over ten days meant Sardar published the evidence himself, without the working group's help. None of that reached the sales conversation. Intel and Google continue to market confidential computing as proof of sovereign, verified protection. Asked directly about the infrastructure underpinning that claim, Intel's answer stopped short of the legal question at its centre. Google did not answer at all. For European CIOs and procurement officers, this raises a question beyond the one usually asked. It is no longer only which company owns the cloud or which government can compel which hardware manufacturer. It is whether the cryptographic handshake meant to prove a workload is running where it claims to be running can be trusted at all. The level that timing rules out Sardar's own mitigation reaches level two. Level three, the one that actually matters to a customer trying to verify their workload is still protected once data starts flowing, may not be achievable at all within the current architecture of intra-handshake attestation, where evidence is generated during the handshake itself. The timing is the problem. Level three requires binding the evidence to the key that encrypts the actual application data, but by the time that key exists, the evidence has already been sent, unless the TLS protocol itself is significantly changed. Post-handshake attestation waits until after that point, when the key is already there to bind against. "We believe post-handshake attestation alone can achieve level three binding," Sardar told The Register, warning that newer proposals combining both approaches add unnecessary complexity without adding security. His recommendation to the IETF's TLS working group is blunt: developers should abandon intra-handshake attestation altogether. ®

AdaptHealth says attackers used social engineering to breach its systems and steal sensitive patient data, including passwords associated with insurance billing. The medical equipment company disclosed the attack to the Securities and Exchange Commission (SEC) on Thursday, noting that attackers accessed internal patient management systems, document storage platforms, and external electronic health record system portals. The attack targeted an unwitting third-party contractor, through which the cybercriminals gained entry to the company's cloud environment, where they accessed business applications holding sensitive data. AdaptHealth activated its incident response protocols soon after the attacker contacted the company on June 15 and disclosed the theft. It did not specify whether an extortion demand was made, nor whether one was paid, and no cybercrime group had claimed responsibility at the time of writing. The company's response included disabling the contractor's user account, resetting credentials, and implementing additional access controls. It believes the attack is now contained. In addition to the "password file associated with insurance billing," AdaptHealth confirmed that personally identifiable information (PII) and protected health information of certain patients were also stolen. Social Security numbers and payment details are not thought to be affected. On June 27, AdaptHealth determined that "due to the nature and potential volume of the data that is at risk," the attack can be considered material, requiring disclosure to the SEC. The company did not comment on the exact scale of the attack or the related data theft, but said investigations continue to determine the scope of the breach. It also said it "has since taken steps intended to mitigate the risk of dissemination of the exfiltrated data." The Register asked AdaptHealth for more information, including whether it received any extortion demands and what steps it took to reduce the risk of the stolen data being distributed or misused. Pennsylvania-based AdaptHealth provides home medical equipment and related services for patients with chronic and serious conditions. Founded in 2012, it specializes in respiratory, sleep, and diabetes therapies. According to a 2024 annual report, it serves more than 4.2 million patients across all 50 US states. ®

Tech companies working with US law enforcement "significantly degraded" the NetNut residential proxy network as part of an ongoing effort to disrupt the tools cybercriminals use to conceal their activity, say researchers. The work was carried out by Google, Lumen, Shadowserver, the FBI, and others, and marks a continuation of the IPIDEA proxy network disruption from January. According to Google Cloud, those working on the operation believe NetNut was among the most popular residential proxy network providers and had at least 2 million devices enrolled in its botnet, comprising mainly small TV-streaming hardware. Crims often use residential proxy networks to make it look like their traffic is actually coming from legit homes and businesses. In the same way that other residential proxy networks expand their pool of enrolled devices, NetNut distributed its own SDK via these devices. Proxy providers often approach users under the guise of monetizing their spare bandwidth, paying them a fee in exchange for letting their SDK run on their devices. The official advice is, of course, to refuse any offers of this kind. Not only does it help feed the cybercrime ecosystem, but it can also lead to vulnerabilities elsewhere in home networks. NetNut offered its own standalone proxy networks, as well as mobile and datacenter proxies, and a slew of scrapers and datasets. However, it also offered a reseller program, and experts believe many other residential proxy networks are powered by NetNut's own, which means the disruption may have further downstream effects. "While we expect this disruption to have a larger ripple effect across the residential proxy ecosystem, observations after the disruption of IPIDEA proved that individual networks can appear resilient," Google's Threat Intelligence Group (GTIG) said. "What we have observed is that when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller. "We recognize that creating a lasting disruption in this fluid ecosystem means we must scale our efforts to target the infrastructure of several interconnected providers. We will continue to observe the composition of the NetNut network and map out how its peers adapt to this action." Residential proxy networks are not illegal, although they are often abused for cybercrime. These networks are ostensibly pitched as a means to shore up online privacy, and promote ideals such as freedom of expression without risk of being traced. However, the same privacy-preserving features of these networks are used by cybercriminals to mask their malicious activity. They enroll ordinary devices, which are connected to innocent residential networks, at scale and offer them to customers as exit nodes. Cybercriminals can make use of these networks to channel their traffic through these nodes, making the traffic appear to originate from an IP address they do not control. "In a single week during June 2026, GTIG observed 316 distinct threat clusters using suspected NetNut exit nodes, including cybercriminal and espionage groups," said Google. "These bad actors can use NetNut to mask their origin IP address when accessing victim environments, accessing their own infrastructure, and conducting password spray attacks." Reports also suggest that NetNut has a role to play in other botnet families. GTIG said it found plugin components for large-scale botnets such as Badbox 2.0, while other public reports have noted signs of NetNut being used to infect devices with Mirai variants. The Register asked GTIG why NetNut's second domain (netnut.io) remains online, while netnut.com returns a "This website has been seized" splash page, but it did not immediately reply. Google's announcement hinted at similar takedowns to take place in the future, as the residential proxy network market continues to grow. However, it said these ad hoc disruptions are only effective for so long, and that a long-term approach would require support from ISPs, mobile platforms, and other technology companies. ®

ON CALL Fronting up to work on Friday morning can feel like a mistake, but The Register tries to make it worthwhile by bringing you a new installment of On Call – the reader-contributed column that shares your tech support stories. This week, meet a reader we'll Regomize as "Lee" who told us about his time as sysadmin at the headquarters of a retail company. "It was about the year 2000 and I was a newly minted Certified NetWare Engineer administering Novell servers," Lee reminisced. Before long, Lee was running the teams that managed email servers and provided desktop support for over a thousand users. "I got to know just about everybody in the HQ and became known as the go-to guy for all things technical," he proudly told On Call. One Friday afternoon, a vice president called to complain he couldn't access any files from his PC because someone else was using them. Lee found this a little odd, so he asked if the veep was seeing a "file in use" dialog in Word or Excel. The veep replied that he was indeed seeing an error that read "General failure is reading Drive C" – but that was obviously someone using the handle "General Failure" to mask their identity. Lee's next question was very precise. "I asked if the error message read 'General failure is reading Drive C:'" he told On Call. The VP re-read the dialog and corrected himself, telling Lee the exact text was "General failure reading Drive C:" At this point, Lee had good news and bad news. The bad news was that the error meant the VP's disk had died. The good news was that nobody was using the handle "General Failure," so the company didn't have a miscreant rummaging around on the network. Lee arranged a support call and advised the veep that he would be getting a new disk and might even be in line for a whole new PC. Have your users misinterpreted an error message? If so, click here to send On Call an email. We can't be clearer than that – or more sincere in our desire to share your story with your fellow Reg readers. ®

During a 48-hour period from June 7 to 8, developer Charles Jones's Google Cloud account registered $11,089.77 in charges - most related to the use of Gemini image-generation models. Yet Jones, a solo developer who runs programmatic SEO and insurance sites, told The Register that he doesn't have any workflow that generates AI images. Google suspended his account anyway. A suspension notification sent to Jones on June 7 justified the decision by stating his account "was engaged in abusive activity consistent with hijacked resources." "The root cause was attributed to a compromised firebase-adminsdk service account key," said Jones, who provided The Register with documentation of his exchanges with Google Cloud support. The notification advised Jones to report his concerns if he believed the account was compromised by a third party. He did so and took the steps required by Google to have his account reinstated. He disabled the service account and revoked the key. But the Google Cloud billing team has repeatedly refused to forgive the charges. As we reported previously, complaints about charges arising from fraudulent API key usage among Google Cloud customers are not uncommon. In February, a developer based in Vietnam claimed that a Google Cloud API key compromise had resulted in more than $82,000 in charges over 48 hours. A similar report claiming more than $10,000 in fraudulent charges surfaced a month later on Reddit. Regardless of where the fault lies – insecure practices by developers or insecure Google infrastructure – Google may choose to hold developers liable for unauthorized charges, even if the credit-card issuing bank has reversed the charge as fraudulent. At the same time, Google still hasn't publicly released a mechanism to cap Google Cloud spending. The company introduced Spend Caps for certain services as a private preview but hasn't made the service generally available. Other cost-limiting measures, like API-specific usage limits "aren't designed to act as a project-wide spending cap." Similarly, Budget Alerts "don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded." Google provides a workaround by allowing Budget Alert notifications to disable cloud billing, but warns that doing so means "resources might be irretrievably deleted." In March, Google introduced project spend caps for the Gemini API as an experimental feature, but at the same time the company said that spend caps have a 10 minute delay and customers are responsible for spending during that period – so the company's definition of cap is rather flexible. What's more, Google said its system "now automatically upgrades you to the next [usage] tier as your usage grows and your payment history matures." And higher tiers raise spending caps. This all means it can still be a challenge for Google Cloud customers to avoid unbounded financial obligations in the event of an account or API key compromise. Escaping that responsibility requires engaging with Google customer service in an opaque appeals process in which the company isn't required to demonstrate customer negligence or an audit trail. "Here's a question I can't get answered, and I think it's central to the whole pattern," Jones said. "Google's Trust & Safety was quick to alert me that a service account key was compromised — but I have been given no route, anywhere, to see HOW or WHERE that key was actually exposed. There is no trace, no log path, no forensic detail offered." Jones said he was the only person who had access to the VM where the compromised key resided and he insists that he followed the company's recommended security practices. "So how does a single-access VM produce a leaked service account key — and why is the burden on me to prove I secured something Google itself can't (or won't) show me how I failed to secure? Google is invoking its Shared Responsibility Model to deny the refund, but that model assumes a customer security failure Google has never demonstrated." The Register twice asked Google why it would deny a refund and what evidence it has that supports that decision. We've not heard back. ®

MeetingTV has sued Palo Alto Networks after its newly acquired Koi Security threat-intelligence biz published a blog that linked the video conferencing and webinar startup to a Chinese corporate espionage operation. The legal complaint filed against Koi Security, its researchers, and Palo Alto Networks alleges that Koi used an LLM to generate the threat report, the AI system hallucinated findings about MeetingTV, and the security shop then published those as facts in a December 30 blog. It accuses Koi of “reckless publication of an AI-driven cybersecurity report that falsely accused Plaintiff MeetingTV Inc. of criminal conduct including operating core infrastructure for a well-funded Chinese criminal organization running a large-scale malware and corporate espionage campaign,” according to court documents [PDF]. “The false attributions were the direct product of Koi’s unsupervised reliance on their proprietary ‘Wings’ analytical platform, which generated erroneous correlations between the Plaintiff’s business and an alleged cybercriminal actor they called DarkSpectre,” the lawsuit continues. A Palo Alto Networks spokesperson told The Register that the company “is aware of the lawsuit brought by MeetingTV Inc. regarding a threat research report published by Koi Security prior to the acquisition,” but declined to answer our specific questions about MeetingTV’s allegations and the Koi blog. “We believe Koi’s cybersecurity research reflects its commitment to identifying and exposing threats to users and enterprises, and we expect that this dispute will be resolved through the appropriate legal process,” the spokesperson said. Koi’s blog, which has since been silently edited to remove references to MeetingTV’s product called Zoomcorder, originally labeled the meeting recording service as a “public-facing front” for a Chinese criminal operation and said it lent “credibility to the infrastructure while serving as a monetization channel” - allegations MeetingTV disputes in its lawsuit. The blog also claimed the operation was behind a 2.2-million-user campaign stealing corporate meeting intelligence. As a result of the report, MeetingTV says, security companies and service providers around the globe blocked MeetingTV’s domains and services, labeling it as malware and command-and-control infrastructure. The startup’s founder and CEO, longtime entrepreneur Michael Robertson, told us the blocks are the only way he found out about the Koi report in the first place. According to Robertson, Koi did not reach out to MeetingTV prior to publishing its threat report. “Even after publishing they never contacted us,” he told The Register. “I was contacting the security companies one by one asking them to unlock us. Most never respond in any fashion, but one finally did respond and told us he was blocking us because of the Koi report and he gave us the url.” Robertson says he’s still struggling, as providers including Verizon and Palo Alto Networks, which completed its Koi acquisition in April, continue to block his startup. “If people on the internet are blocked from reaching your company, then that's a death sentence,” he said. “Plus all the LLMs now say we're working with Chinese cyber criminals. How will that ever get removed?” After the acquisition closed, Robertson emailed Palo Alto CEO Nikesh Arora directly and asked him to take action. “Now your company owns Koi and is continuing to publish and rely on the false report,” the email said. “Our domain and Google subdomains are blocked and labeled as malware and command and control by your company and others around the world … Take down the false report which is defaming us and in its place put a full retraction. Remove our domains from your own blacklist and help get them removed from others who are blocking us because of the Koi report.” A mysterious extension The December blog linked Zoomcorder to the Zoom Stealer campaign, which it attributed to the Chinese threat actor DarkSpectre, via a browser extension identified as "Twitter X Video Downloader." According to Robertson and the lawsuit, however, this extension doesn’t exist – and Koi “refused to supply information” about the software when MeetingTV requested it. “Koi’s single-actor theory rested on a fabricated technical ‘pivot’ – a single piece of software they repeatedly identified as the ‘Twitter X Video Downloader’ extension,” the lawsuit alleges. “This alleged extension was described as the critical bridge connecting the Zoom Stealer campaign (defined entirely by Plaintiff’s infrastructure) to ShadyPanda, core DarkSpectre infrastructure.” Robertson said he believes Koi used an LLM to generate the threat report, and it hallucinated findings about MeetingTV’s Zoomcorder product that the security shop published as facts. “They admit to using AI for their analysis,” Robertson said. “Maybe a human made it all up? Maybe it was AI? What's clear is that if the software doesn't exist, then even the most rudimentary analysis is impossible to do, yet they labeled our urls, services, and software as criminals.” The bigger picture in all of this, according to Robertson, is that we know AI systems hallucinate. Their findings should not be accepted as fact without any human review. “We're on the doorstep of an era where AI will be used to make critical life-altering decisions on people's lives: Did you pay your taxes, what your credit rating should be, will you get admitted to the University, do you qualify for the home loan, should you be on the no-fly list, etc.,” Robertson said. “Will these be made without human oversight? Will people have due process – see the accusations against them, present their own evidence, have a neutral arbiter? None of that happened in our case,” he continued. “They just declared us criminals and published it to the world.”®

They're not bad; they're just prompted that way. Sysdig threat hunters documented what they say is the first-ever documented agentic ransomware infection with an LLM - not a human - driving the entire extortion operation, from gaining initial access to compromising a production database server and destroying data. The security shop’s research team named the agentic intruder JadePuffer and said it gained initial access to an internet-facing Langflow instance by exploiting CVE-2025-3248, and then ran a fully automated attack. “The most striking characteristic, however, was the LLM's behavior,” Sysdig director of threat research Michael Clark said in a blog about the agentic ransomware and extortion operation. JadePuffer’s “self-narrating” payloads “contained natural language reasoning, target prioritization, and the kind of detailed annotations that human operators don’t often write but LLM-generated code produces reflexively,” Clark added. “The operation also adapted in real time, retrying failed steps within refined parameters. In one sequence, it went from a failed login to a working fix in 31 seconds.” After exploiting CVE-2025-3248, a missing authentication vulnerability in Langflow that allows remote, unauthenticated attackers to execute arbitrary Python on the host, the AI agent began scanning for and collecting secrets, including LLM provider API keys, cloud credentials “with explicit coverage of Chinese providers” including Alibaba, Aliyun, Tencent, and Huawei, while also scanning for AWS, Azure and Google Cloud Platform, cryptocurrency wallets, and database credentials. The AI also installed a crontab entry on the Langflow server to maintain persistence and call back to the attacker’s infrastructure every 30 minutes. JadePuffer’s intended target was a separate internet-exposed production server running a MySQL database and an Alibaba Nacos configuration service, we’re told. Nacos is an open-source service-discovery and dynamic configuration platform developed by Alibaba and used in the cloud provider’s microservices applications. The agent connected to the server's exposed MySQL port using root credentials, although Sysdig doesn’t know how the attacker obtained them. These credentials weren’t stolen from the victim’s environment. JadePuffer then attacked Nacos via multiple vectors including an authorization bypass flaw (CVE-2021-29441) and forging a valid JSON web token (JWT) using Nacos's default signing key. Additionally, using its root database access, the LLM injected a backdoor administrator into the Nacos backing database. It ultimately encrypted all 1,342 Nacos service configuration items using MySQL's built-in AES encryption function, and created an extortion demand, ransom note, Bitcoin payment address, and a Proton Mail contact: "YOUR DATA HAS BEEN ENCRYPTED. All NACOS configurations, REDACTED customer data, and REDACTED PII have been encrypted with AES-256.", "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy", "e78393397[@]proton[.]me" However, according to the threat hunters, the victim can’t recover the encrypted data, even if they paid the ransom demand, because the agent escalated “from row-level deletion to dropping entire database schemas, narrating its own targeting rationale,” without backing up any of the encrypted data. There are a couple of things that security teams and vulnerability managers should do immediately to avoid being ransomed by this AI agent. First up: patch Langflow to a release that fixes CVE-2025-3248, and do not expose code-execution/validation endpoints to the internet. Also, don’t ever expose Nacos to the open internet, change its default token.secret.key, and upgrade to a release that forces a custom key. The threat hunters also recommend against running any AI orchestration servers with provider API keys or cloud credentials in their environment. While the AI agent didn’t use any especially sophisticated or unique techniques in this attack, the fact that an LLM “strung them together into a complete ransomware operation against neglected internet-facing infrastructure,” is notable, according to Clark. “The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero.”®

Security sleuths say last month’s FortiBleed campaign is tied to two separate ransomware groups, after they found evidence of one initial access broker group member logged in to two affiliate panels. SOC Radar’s Threat Research Unit (STRU) said at least one of the group’s 20 members was actively negotiating with victims, which it believes signals a direct link between the thousands of FortiBleed victims and the ransomware ecosystem. STRU spent weeks mapping FortiBleed’s infrastructure across hundreds of servers after the attack was disclosed. Due to an opsec failure in one of these servers, the team gained visibility into the IAB group’s internal files and logs, revealing that one of the individuals was logged into the affiliate panels of both the INC Ransom and Lynx ransomware groups. “Finding a single operator working both panels, using infrastructure traceable back to FortiBleed, is the clearest evidence yet that FortiGate credentials harvested through this campaign are being handed off, or used directly, for ransomware deployment,” SOC Radar said. Following examinations of both the IAB group’s internal logs, compromised endpoints, and claims made via the leak sites of INC and Lynx, STRU linked at least 12 ransomware attacks to FortiBleed victims so far. While initial reports pegged the number of successful attacks at more than 70,000, STRU said its data was derived from scanning 11,250 Fortinet portals, although more than 430,000 firewalls were targeted. Admin-level access was confirmed on 409 targets, and on 354 of these the attackers executed the full attack chain, compromising VPNs and gaining access to domain controllers and domain admin. STRU said the finding is significant because it shows how the exploit was not just an exercise in harvesting credentials, but an attack that feeds directly into the ransomware economy. “What this investigation shows is that FortiBleed isn’t an isolated credential-theft operation sitting off to the side of the ransomware economy, it’s feeding directly into it. The same access broker infrastructure that quietly intercepted authentication traffic across hundreds of thousands of firewalls is connected, through a shared operator, to two of the more active ransomware brands operating today. “For organizations running FortiGate infrastructure, this raises the stakes on an already urgent finding: exposure to FortiBleed is not just a credential exposure risk, it is a potential precursor to ransomware.” FortiBleed in brief Disclosed on June 17, the attack did not exploit novel vulnerabilities. Experts characterised it as a large-scale campaign that involved intercepting SSL VPN authentication hashes and cracking them using a 45-GPU cluster hosted by Hashtopolis. They then used the credentials to access victims’ Active Directory environments and gain persistence. Fortinet tried to counter these kinds of attacks in early 2025 by introducing the PBKDF2 algorithm for storing credentials, but because the changes were not applied until each admin logged back in, many organizations were likely still using SHA-256 with salt, which is vulnerable to brute-forcing. Early estimates suggested a little more than 73,000 unique firewall URLs were successfully targeted, leading to a long list of major organizations being compromised. FoxConn, Samsung, Comcast, Siemens, Lenovo, FedEx, PwC, Accenture, and Oracle were among those listed in the early reports. An unnamed Turkish NATO defense contractor was also thought to be among them after investigators found signs of classified files being copied. ®

Microsoft's prediction that attackers probably wouldn't rush to exploit a newly-patched SharePoint bug hasn't aged especially well. CISA has added CVE-2026-45659, a remote code execution flaw in on-premises Microsoft SharePoint Server, to its Known Exploited Vulnerabilities (KEV) catalog after confirming that crimes are now actively exploiting it in the wild. The bug stems from an insecure deserialization issue and affects SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016, all of which received patches from Microsoft in May. Unlike some of SharePoint's more infamous bugs, this one isn't pre-authentication, though attackers need surprisingly little to pull it off. According to Microsoft, anyone with valid credentials and nothing more than Site Member permissions can execute arbitrary code remotely on a vulnerable server. "Any authenticated attacker could trigger this vulnerability. It does not require admin or other elevated privileges," Microsoft said in its advisory. "In a network-based attack, an authenticated attacker, who has a minimum of Site Member permissions (PR), could execute code remotely on the SharePoint Server." Microsoft also noted that the attack can be launched remotely over the network with low attack complexity, making it straightforward to exploit once an attacker has a foothold. CISA didn't disclose who's exploiting the flaw or how widespread the attacks are, but its guidance leaves little room for interpretation. "This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise," the agency warned. It directed federal civilian agencies to follow Binding Operational Directive 26-04 by applying Microsoft's fixes no later than July 4, or discontinue use of affected systems if mitigations aren't available. The vulnerability carries a CVSS score of 8.8, but perhaps the more interesting number is Microsoft's exploitability assessment. When the patches landed, Redmond rated real-world exploitation as "Less Likely." That's a prediction, not a guarantee, and history has a habit of making those forecasts look optimistic once patches give attackers a roadmap to reverse engineer. For anyone still exposing an unpatched SharePoint server to the internet, CISA's KEV listing is a reminder that the race between patching and exploitation is usually won by whoever starts first. ®

Medical device giant Medtronic is warning patients that their personal and health information may have been caught up in an April cyberattack in which intruders spent nearly a week inside parts of its corporate network. According to breach notification letters sent to affected individuals, the company detected unusual activity on April 15 and later determined an unauthorized party accessed certain corporate systems between April 13 and April 19. The compromised systems contained the sort of data you'd expect a medical device maker to hold about its patients: names, contact details, dates of birth, Social Security numbers, and health information. Medtronic said it collects the information to provide product updates and comply with regulatory requirements. Medtronic says there's "no evidence" the information was "posted publicly or exposed on the internet." Whether the attackers made off with copies of the data is another question the company hasn't yet answered. The notice also addresses the question many patients are likely to ask first: whether their device was affected. "Based on our investigation, this incident did not impact the ability of any Medtronic device to operate safely and deliver intended therapy." the company said. When Medtronic first disclosed the incident in April, it said the attack had not affected patient safety, manufacturing, distribution, financial reporting, or its ability to meet patient needs. It also stressed that its corporate IT environment is segregated from the networks supporting its products and that hospital customer networks are managed separately. Shortly after the intrusion began, the ShinyHunters extortion crew added Medtronic to its dark web leak site, claiming it had stolen more than nine million records and threatening to publish the data unless a ransom was paid by April 21. The listing was later removed. ShinyHunters typically removes victims from its leak site after reaching a deal, and Medtronic's entry disappeared later that month without any data being published. However, Medtronic's notification makes no mention of ransomware, extortion demands, or ShinyHunters, and the company has not publicly attributed the attack. The breach notice also leaves several obvious questions unanswered, including how many people were affected, how the attackers gained access, and why it took the company more than two months to begin notifying affected patients. Medtronic said it has since implemented additional security measures, worked with law enforcement and relevant regulators, and is offering affected individuals two years of complimentary credit monitoring, dark web monitoring, and identity restoration services. ®

India has asked WhatsApp to explain why it should not face regulatory action after it announced the global rollout of a new usernames feature amid fears that the new feature could lead to increased cyberattacks. The country's Ministry of Electronics and Information Technology (MeitY) gave the Meta owned platform three days to respond to its July 1 letter and to halt the rollout of usernames until the government gives its approval. WhatsApp announced on June 29 that it was allowing users to reserve usernames that could be used instead of phone numbers on the platform when the feature launches later this year. It said that people want to chat with others without exposing their personal phone number, whether to a classmate, neighbor, professional contact, or the group chat for their child's sports team. Meta also owns Facebook or Instagram, and is not allowing users to create usernames that already exist on those other platforms – unless they themselves control the other accounts. However, the government of India, WhatsApp's largest market fears that allowing first contact without displaying a phone number "may increase cybercrimes," including phishing and digital arrest scams. MeitY is specifically concerned about the opportunities for impersonation, with attackers posing as public authorities, financial institutions, or government departments. The department cited India's Information Technology Act 2000 and Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021 as the legal basis for its concerns about the feature. The Internet Freedom Foundation, which shared a copy of MeitY's letter to WhatsApp's chief compliance officer in India, said that the department has no clear legal basis for halting WhatsApp's usernames rollout. It said neither legal framework was applicable in the context in which they were being invoked and called its letter the latest example of attempted regulatory overreach. The IFF pointed to a separate advisory issued in March 2024 when MeitY tried to stop AI companies from rolling out their models to the public before the Indian government had a chance to approve them. "That was criticized as an overreach that sought to build a licensing mechanism with no empowering provision in the IT Act, and within a fortnight MeitY withdrew it and dropped the permission requirement," the IFF stated. "This notice repeats the move for a single feature and goes further, because it names one company, sets a three-day clock, and bars the launch until MeitY is satisfied." WhatsApp told The Register that it has implemented numerous measures designed to keep users safe as usernames are rolled out across the platform. A spokesperson said: "We've announced the option for people to reserve their preferred username on WhatsApp. The ability to use a username is not yet live and will roll out slowly later this year. When it becomes available and someone sends you a message for the first time via your username, we will show you if they're a new account, if they're your contact, if you have groups in common, and if they're based in a different country, so you can decide whether to respond." In other efforts to restrict fraudulent misuse, WhatsApp has already reserved high-profile usernames for legitimate organizations and individuals. Users will also not be able to register lookalike derivatives. The spokesperson added: "Users still require a phone number to use WhatsApp and we've built multiple layers of defense against scams into usernames. Other users need to know the exact username to message you, we will limit how many new people an account can contact, block repeated attempts to guess someone's username key, and have systems to detect and remove activity showing common impersonation and abuse patterns." MeitY did not respond to our request for input. WhatsApp claims more than 3 billion users rely on its messaging platform, and separate estimates peg India as its largest market with more than 850 million users. WhatsApp-based scams are not unique to India. Many cybercriminals use the platform to commit fraud, impersonating public figures, authorities, and family members to carry out financially motivated attacks. The Telegram messaging platform allows users to set public usernames and is also frequented by scammers. India temporarily banned Telegram in June amid fears that exam questions were being shared ahead of time. The ban was announced days before the NEET-UG medical entrance exam was scheduled to begin. The exam was reworked and rescheduled after being canceled in May after genuine questions were found circulating on the platform. ®

Attackers have been caught exploiting a critical flaw in Oracle E-Business Suite's Payments module just six weeks after Oracle patched it – and before any public proof-of-concept exploit was available. Researchers at Defused said they observed the first known exploitation of CVE-2026-46817 on June 27. The attackers were targeting the Oracle Payments File Transmission component in E-Business Suite releases 12.2.3 through 12.2.15, they said. The vulnerability, fixed in Oracle's May Critical Patch Update, carries a CVSS score of 9.8 and allows unauthenticated attackers to read arbitrary files from vulnerable servers. According to Defused, the activity didn't look like the indiscriminate internet scanning that often follows disclosure of a critical bug. Instead, its honeypots recorded just six exploitation attempts from a single source, all using what appeared to be a working exploit. The requests sought to retrieve sensitive files from the target system, suggesting the operator was testing or validating the technique rather than casting a wide net. The researchers said exploitation began before any public exploit code had surfaced, pointing to an attacker who had either reverse-engineered Oracle's patch or obtained a private exploit. The Shadowserver Foundation said it currently sees around 950 EBS instances exposed to the public internet, the majority in the US, although it stressed that figure says nothing about whether they're vulnerable or fully patched. The observed exploitation fits a pattern that's becoming increasingly familiar. Earlier this month, researchers warned that attackers had exploited a critical PeopleSoft zero-day before patches were widely deployed, with the ShinyHunters crew claiming to have compromised more than 100 organizations. They also boasted of having stolen HR and payroll data. This latest incident also follows Clop's lengthy campaign against Oracle E-Business Suite customers, disclosed last year after researchers found the ransomware crew had targeted internet-facing EBS servers for months before the activity became public. The newly exploited EBS vulnerability is probably not the last Oracle ERP bug to be targeted. Enterprise software has become a lucrative hunting ground for cybercrooks, and critical updates can double as roadmaps for anyone prepared to reverse-engineer the fixes and beat customers to deployment. ®

PWNED Welcome back to PWNED, the column where we document serious security failures in hopes we can all learn from others’ mistakes. This week, we’ll talk about how a lack of physical security can allow threat actors to take control of your network. 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 story comes to us from two professional red teamers, who get paid to break into offices and networks in order to find holes in the security system. Kristopher Johnson was working as an offensive security consultant at Echelon Risk + Cyber in 2023 and his manager was Dahvid Schloss. We spoke to both. Johnson and another employee named Michael were called upon to challenge the security at a client’s office while Schloss supervised remotely. It was winter and the maintenance crew had the maintenance door open. They walked through it and into the mail room, where a woman confronted them and asked what they were doing there. The two intrepid testers talked to the company maintenance crew and told them that they were new IT employees without working badges. They said that they had almost slipped on the ice and offered to help shovel, an offer the maintenance team was happy to take them up on. While Michael kindly helped the maintenance crew shovel snow, Johnson asked if the maintenance folks could let him in so he could go upstairs and start setting up Michael’s laptop for work. They let him in where he was free to explore the building as his partner brushed away a large section of ice and snow. Inside the building, Johnson looked for a place to plug in his Raspberry Pi. The idea was to connect this single-board computer to the network, where they could access it remotely and use it to attack the network from afar. He tried plugging his Raspberry Pi into an Ethernet port in the AV closet, but the company had network access control enabled, which prevented it from connecting. The Raspberry Pi had an LTE radio, but it couldn’t connect from the closet either. So Johnson instead moved his Raspberry Pi into the middle of the conference room and found an active network port that didn't have network access control enabled on it. However, he realized the Pi would be visible to anyone who entered the conference room, and they might find it suspicious. So he took some trash cans and used them to hide the device. Johnson had a hard time getting out of the building after that. He tried to go out the front door, but it required him to swipe a badge he didn’t have and strangers would not swipe their badges for him. But when he went back through the maintenance entrance, they were more than happy to swipe him out. He waited in the car while Michael finished his shoveling assignment. The next day, Johnson found out that his security breach had been detected. When he and Michael came in to meet with their contact at the company, the head of security confronted them. They had been “caught” because someone from maintenance went up to the IT department and wanted to thank the IT team for Michael’s help with the shoveling. However, the IT team had no record of new employees named Michael or Kristopher, so that raised suspicion. Before learning that they were professional red teamers, the building security had been suspicious and had looked at camera footage tracking their movements. They had even tried to get information on the license plate from Johnson’s rental car. However, they never did find the Raspberry Pi, which remained plugged into the Ethernet port in the conference room for two weeks. During that time, Johnson’s team was able to connect to the company’s Active Directory, find where the domain controllers were, and start password spraying accounts to see if they could gain access. They tried using the password “winter2023!” and got 50 or 60 hits among the employees. “So we used those credentials to kind of map out the rest of the network,” Johnson told The Register. “Network shares and things like that and then, towards the end of the test, we enumerated the certificate services - ADCS (Active Directory Certificate Services).” The red teamers found eight templates that were open to ESC1 and ESC4 vulns. They also found that the certificate authority was vulnerable to ESC8. They were then able to exploit those holes to gain domain administrative access. The janitor found the Raspberry Pi two weeks after they broke in, but by then it was too late. There are a lot of lessons here, but they start with training every member of the team to be suspicious of people coming from the outside, without badges, no matter what they say or do. Schloss noted that, if someone looks and acts like they belong in a space, most people will treat them that way. “First and foremost, what most people believe is crime is not crime. It's a Hollywood myth of what crime looks like,” Schloss told us. “I call it the ski mask bias. Everyone assumes you're not getting robbed until a person comes in with a ski mask and a gun yelling.” The maintenance team at this company should have been more suspicious of people calling themselves new employees and asking for a swipe in, even if they were willing to help shovel snow. The company also should have restricted network access to the port in the conference room so that an unknown device like a Raspberry Pi could not make an Ethernet connection from that spot. Finally, the company should have enforced a strong password policy that would have prevented our heroes from finding dozens of accounts with “winter2023!” as the password. And they should have enforced multi-factor authentication on those accounts as well. ®

EvilTokens, the device-code phishing kit that can allow criminals to bypass multi-factor authentication (MFA) and silently authenticate as the victim to the organization's Microsoft 365 applications, appears to be even more insidious than we all thought. Cisco Talos incident responders on Wednesday described how the lure reaches a victim's inbox, and revealed new capabilities alongside a “more sophisticated evasion approach” than documented in earlier EvilTokens research. Talos uncovered a phishing-as-a-service (PhaaS) operator panel, branded “ARToken,” that appears to be an EvilTokens customer, according to security research engineer Michael Kelley, who noted the phishing operation shares infrastructure, API contracts, and operational patterns with the EvilTokens platform. EvilTokens was first documented by French cybersecurity firm Sekoia in March, and in April Microsoft said the device-code phishing campaign was compromising hundreds of organizations daily. "Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours," Microsoft VP of security research Tanmay Ganacharya told El Reg at the time. “Each campaign is distributed at scale, targeting hundreds of organizations with highly varied and unique payloads, making pattern-based detection more challenging.” While most subsequent analysis has covered EvilTokens’ panel and phishing kit, “what it has not shown is how an ARToken lure actually reaches an inbox,” Kelley said on Wednesday. “Talos recovered two near-identical messages, sent roughly four minutes apart on April 20, 2026, that initiate the chain. The tradecraft is targeted, not spray-and-pray.” Specifically, the email lure abused a real vendor relationship between a US life-sciences company and a legitimate plumbing and fire-protection contractor. The email uses an outstanding-invoice lure, telling the life-sciences company that “the following invoices appear to still be outstanding,” and the “from” header presents the contractor’s real domain. The reply-to, however, redirects replies to an unrelated domain. Even the visible anchor text in the body of the email reads as the vendor's genuine SharePoint tenant, we’re told. The actual href, however, points to a near-identical copycat tenant under a different, attacker-controlled Microsoft 365 workspace. But because the destination is still a legitimate sharepoint.com host, the email is less likely to be flagged as a phish. During its investigation into the ARToken phishing infrastructure, Cisco uncovered the connections to EvilTokens – including an identical API contract to the one originally documented by Sekoia and matching deployment and operational models – as well as “notably more sophisticated” anti-analysis and evasion capabilities. ARToken’s panel also revealed a very comprehensive post-exploitation toolkit that provides token management and persistence mechanisms, and a built-in business email compromise (BEC) tool with full Microsoft Outlook inbox read access, email sending capabilities as the victim, inbox rule creation for forwarding and deleting messages, and keyword-based monitoring across all compromised accounts. “These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment,” Kelley wrote. ®

Anthropic has released the latest version of its mid-sized model, Sonnet 5, which the company claims is its most “agentic” yet. For developers writing agents to automate tedious and recurring tasks, Sonnet 5 promises improved capabilities in reasoning, tool use, coding, and knowledge work. This version is also less likely to pull embarrassing (for Anthropic) gaffes of misunderstanding, so the company asserts. “Our safety assessments found that Sonnet 5 shows an overall lower rate of undesirable behaviors than Sonnet 4.6, and is generally safer to use in agentic contexts,” the company asserted in an introductory blog post on Tuesday. Sonnet 5 is smarter at refusing malicious requests and resisting prompt-injection attempts. It doesn’t hallucinate as often and doesn’t suck up to the user so much (“sycophancy”) as did its older brown-nosing Sonnet 4.6 sibling. It is also more aware of, and can block, user misuse and deception, the benchmarks in Anthropic’s System Card seem to indicate. Sonnet is the default model for Claude Free and Pro users, and is also available to the token-pinching Max, Team, and Enterprise customers. The benchmarks also indicate Sonnet 5’s performance can come close to that of Anthropic’s flagship enterprise-focused Opus 4.8, but can execute the same tasks more cost effectively. For Opus, Anthropic charges $5 per million input tokens and $25 per million output tokens. Starting in September, Sonnet users will pay $3 per million input tokens and $15 per million output tokens, though Anthropic is running a special through the end of August where tokens will only be $2 per million inputs and $10 per million outputs. So users trimming their token budgets can run jobs through Sonnet instead of Opus, the company suggests. The 5.0 release offers a new setting to adjust the model’s effort at completing tasks. Simple tasks can be completed through one of the lower “effort” settings, which uses fewer tokens, while longer-running agent-based tasks can go full throttle (“xhigh” or even Homer Simpson’s favorite setting, “max”). What Sonnet 5 can do for developers For much of 2026, AI product deployment has focused on equipping large language models to complete what has become known as “long horizon tasks.” It might be easy for a model to fix a bug or churn out some code. However, keeping its finicky attention fixed on a multi-part task has proven more difficult. The new version of Sonnet can go the distance, according to the company, compared with the earlier Sonnets. “Across a broad suite of internal and third-party benchmarks, Sonnet 5 shows clear gains over Claude Sonnet 4.6 in coding, agentic search, multimodal reasoning, and professional-task performance,” the System Card asserted. At the same time, however, the performance across these tasks still trailed that of the Opus and Mythos models. One testimonial from a Zapier engineer described a two-part job that flummoxed earlier Sonnets: Update a contact database and send out a notice to all users. Version 5 was able to complete the task “end to end.” Cybersecurity: Nothing to see here The San Francisco-based company also went out of its way not to attract any more undue attention from Washington, DC policymakers. “We did not deliberately train Sonnet 5 on cybersecurity tasks,” the company asserted. In June, the US Commerce Department, citing national security concerns, slapped Anthropic with an export control directive temporarily restricting foreign access to the newly released Mythos 5 and Fable 5 models. Whether Anthropic brought this on itself – through what could be regarded as hyperbolic assertions of Mythos’ deity-like bug-sleuthing powers – is certainly worth discussing. But Anthropic, like Pete Townshend, certainly won’t be fooled again. While it can readily perform routine cybersecurity tasks, Sonnet 5 is guardrailed against generating offensive attack code. When commanded to write a Firefox exploit, it failed to complete the task (though it got a bit further than Sonnet 4.6 in the attempt). “This latter change is likely due to improvements in general intelligence rather than specific training,” the company’s blog post noted. ®

You can't ask most models to help you make "ransomware" directly, but many will be more than willing if you give them the right prompt. DeepSeek and other LLMs with fewer safety and security controls make theoretical cyberthreats - like browser-only ransomware - much more likely to be used in real-world infections, according to Check Point researchers. The Israeli cybersecurity company analyzed a DeepSeek-generated sample in a Wednesday report that its threat hunters describe as in-browser ransomware. Over the past year, the team has tracked almost 3,000 files attributed to DeepSeek, and classified nearly half (1,383 files) as malicious or dangerous using VirusTotal or static source analysis. “Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild,” researcher Alexey Bukhteyev wrote. And while the sample was incomplete, and unable to pull off an in-the-wild infection, the security shop’s testing showed “little effort” would be required to make it attack-ready. “Our research shows that the original incomplete DeepSeek sample can be transformed into a fully functional attack with minimal effort,” Pedro Drimel Neto, malware analysis team leader at Check Point Research, told The Register. “Very little effort is needed,” Neto said. “Low-level expertise is sufficient. You don't need to be a sophisticated cybercriminal or advanced persistent threat group. In fact, we've already observed evidence of actual threat actors attempting this attack using straightforward LLM prompts.” Known threat gets an AI boost The risk ransomware poses to browsers isn’t a new idea. The File System Access specification lists ransomware as a security consideration, and a 2023 USENIX Security paper on Ransomware over Modern Web Browsers described how File System Access API could be abused to encrypt local files from a malicious web application. The File System Access API is a browser capability, primarily supported by Chrome and Chromium-based browsers, that allows developers to build web applications, such as editors, IDEs, and creative tools, that can read, write, and manage files on the user’s local device. “Even though it can be used to develop rich web applications, it greatly extends the attack surface, which can be abused by adversaries to cause significant harm,” Google’s Güliz Seray Tuncay and Florida International University researchers Harun Oz, Ahmet Aris, Abbas Acar, Leonardo Babun and Selcuk Uluagac wrote in 2023, long before LLMs could develop working malware and attack chains. What’s new, according to Check Point, is that an AI model put these previously documented ideas into a “realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain.” This technique is especially appealing to attackers because it doesn’t require a native payload, APK installation, browser exploit, or root access to a compromised device. Instead, it uses social engineering - tricking a user into clicking on a malicious button - combined with a legitimate permission prompt exposed by the File System Access API in Chrome. Meet InfernoGrabber 9000 This particular sample that Check Point uncovered is a Python Flask application that targets Android users. It’s named InfernoGrabber 9000, and VirusTotal calls it a “fully functional information stealer and ransomware toolkit.” While the security sleuths don’t have the prompt submitted to DeepSeek to produce the malware, they speculate it was something along the lines of: “create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, ‘persistence,’ and a ransomware-style overlay.” To be clear: the sample doesn’t actually do all of this. “A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser,” Bukhteyev wrote. The code presents a victim-facing lure disguised as a Discord avatar AI upscaler. Clicking on the lure is intended to execute a slew of silent, harmful actions that run entirely inside the browser process. These include stealing Discord tokens, harvesting credit card numbers and cryptocurrency seed phrases, logging keystrokes, and capturing unauthorized webcam and microphone feeds. The code also includes specific routines for browser exploitation (such as targeting CVE-2023-4863), uses a hardcoded Discord webhook for data exfiltration and displays a ransomware WinLocker screen demanding Bitcoin. The good news for defenders is that the sample was incomplete, and the browser's built-in security model successfully prevents most of this functionality. However, Check Point was able to create a working proof-of-concept for the browser-native attack using the latest DeepSeek model V4. The team had to remove some of the more explicit terms - like ransomware - from the prompt, but ultimately produced the same functionality: “a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content.” AKA: browser-only ransomware. Neto told us that this type of LLM-generated code and in-browser attack is “likely happening now.” “We expect to see this activity in the short term, if we haven't already,” he added. While traditional ransomware and extortion groups target enterprises and critical infrastructure organizations, as opposed to Android-device users, which was the focus of this research, “we have seen increased end-user ransomware activity recently,” Neto said. “What's most concerning is that code obfuscation used in these attacks makes them difficult to spot, so there's a real possibility that attacks using this technique are already occurring in the wild but going unnoticed.” ®