News

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

EXCLUSIVE Pentera Labs’ red teamers compromised a developer’s AI agent via his Claude Desktop app and ultimately turned that access into full remote code execution on the dev’s machine – demonstrating how an attacker could turn a trusted, chatty AI assistant into a double agent operating on their behalf. “Claude’s got a new voice,” Pentera's offensive security services team leader Dvir Avraham told The Register. “We acknowledge the huge trust in AI models – everybody uses them,” he said in a phone interview. “We used this trust to manipulate the victim, like under the hood, the victim didn't see it coming.” It also prompted Avraham to check his own platforms. “I became a little bit paranoid,” he told us. “I'm not allowing any command to run without me examining it twice.” In a report set to publish Wednesday, and shared in advance exclusively with The Register, Avraham and research technical lead Reef Spektor detailed the attack and what it means for organizations using agentic AI tools with local code-execution access. It began with a red-team assignment on a third-party platform that aggregates customer email inboxes into a single management interface. Avraham and Spektor won’t name the platform, or tell us exactly how they gained access to it. They used this compromised inbox – and told us any compromised inbox would work – to get into the victim’s Claude account. As the duo noted, breaking into an email inbox in real life – via a third-party management platform, phishing link, social engineering password reset, or even using AI agents – isn’t too difficult. “AI agents today have access to connectors and to direct MCPs into inboxes,” Spektor added. In addition to this prerequisite (compromised inbox), the attack chain also requires the victim to have Claude Desktop installed. Anthropic’s desktop app works across macOS, Windows, and Linux systems. It provides the same AI chat for conversations as claude.ai, and it also syncs across all devices and sessions tied to the user’s account. “We asked ourselves, can we leverage the sync behavior to infect other sessions and devices? (hint: yes!),” the red teamers wrote in the Wednesday report. Back to the AI Stone Age As of January, the desktop app also includes Cowork for longer agentic tasks, and Code for software development. So, for example, a user can send Claude a task from their phone and instruct it to work on their computer. As Anthropic says: “Anything you can do on your computer, Claude can do. Open apps, fill spreadsheets, navigate your browser. No setup, no passwords handed off.” The Cowork feature now makes Pentera Labs’ attack scenario even easier. However, when the security analysts were doing this research in November 2025, “back in the Stone Age in terms of AI, you didn't have Cowork or Claude Code, so we needed a way to actually execute commands because we wanted to take over the machine,” Avraham said. For this part, they took a keen interest in Claude Desktop’s personalization features. These are account-wide settings that tell the AI agent the user’s preferred approach and general communication instructions, along with more specific project instructions, such as guidelines for a particular workflow, or defined roles Claude should adopt within a project. The red teamers developed a base64-encoded prompt that instructed Claude to check for command-capable tools on the developer’s machine and execute the command if available, or produce a fake error message if not, prompting the user to download a tool that will execute the attacker’s commands. Then they pasted the prompt into the victim’s personal preferences on Claude, and this prompt syncs across all of the user’s devices. This ensures that the next time the user opens Claude Desktop and types in a chat, the poisoned instructions are loaded into their preferences and will silently run behind the scenes. The user thinks they are simply interacting with Claude as usual. They don’t see Claude checking to see what extensions and tools are installed. If the user already has Desktop Commander or a similar MCP connector or extension installed, the poisoned instructions tell Claude to use it. This allows the attacker, via Claude, to execute a stealthy reverse shell or other malicious code. “And from there it's full compromise of the machine,” Avraham said. Phishing - but without the email However, if there aren’t any command-capable tools installed, then Claude becomes what the researchers describe as a “phishing layer.” (They also noted that if they had performed this research more recently, not back in November, the Claude Cowork feature would have eliminated this entire tool enumeration and phishing phase because Cowork can execute commands on a user’s behalf.) The injected prompt instructs Claude to present a realistic-looking error as soon as the victim asks the chatbot a question. This includes a realistic error code, a link that purports to be a fix, and step-by-step instructions. “This message tells the victim: ‘please download this,’ and we took links from the actual Anthropic site, with known emojis that the AI loves,” Avraham said. Because the error message looks real and people usually trust their AI assistant, they will likely click on the link and execute the attacker-controlled command. “From here, the attacker has full command execution – reverse shells, data exfiltration, credential harvesting, whatever the objective calls for,” the duo wrote. “In our case, we had Claude curl a remote server we controlled on every interaction, fetching and executing whatever bash commands we served back. We could rotate those commands server side at will, effectively turning Claude into a persistent, stealthy C2 agent that the victim themselves kept feeding.” In this specific case, the target was a developer who had credentials and access to several internal systems. After compromising the dev’s workstation – which gave the red teamers a foothold into the organization – they moved laterally across the company using various attack vectors that they declined to tell us about, citing customer privacy and proprietary methods. But, Spektor added, developers make for an “excellent starting point for an attacker,” because of their access to secrets including API keys, tokens, and cloud credentials, which allows intruders to move from a single workstation into the larger organization’s cloud environment. From there, they’ve got free rein to steal source code and other sensitive data, or poison internal git repositories, and cause all sorts of pain for enterprises as we've seen play out multiple times across several recent attacks. Feature, not a bug The team reported their findings to Anthropic back in November, and the AI company essentially said it’s Claude Desktop working as intended – a feature, not a bug. “After reviewing your submission, we've determined this doesn't represent a security vulnerability that falls within our program scope,” Anthropic said. “Our current threat model treats personal preferences, skills, and MCP connectors as features that can execute code through Claude Desktop by design. While we recognize these features can be leveraged to execute arbitrary code when manipulated, this represents expected functionality rather than a security vulnerability in our infrastructure.” The Register reached out to Anthropic for comment and did not receive any response. The red teamers, however, have some suggestions to keep your organization safer from rogue AI agents. First, for anyone using agents or chatbots: pay close attention to what the AI can do on your machine, and don’t blindly follow install prompts or error messages. “If you can, run it on a sandbox and not on your personal computer,” Spektor said. Security teams should treat AI desktop apps as “privileged software” as they can execute code, read files, and interact with local tools. “Monitor for changes of AI assistant configurations and synced settings,” the researchers wrote. “Restrict which extensions and tools can be installed alongside AI apps.” And finally, red teams should add AI desktop apps to their assessment toolbox, Avraham and Spektor noted: “There's a real attack surface here that most engagements don’t cover yet.” ®

Perhaps bots aren't the answer to everything when it comes to finding flaws. Fully automated pentesting has been a letdown for many security teams, according to offensive security firm Cobalt, as support for the approach has fallen sharply over the past year. Cobalt’s recent 2026 State of Pentesting report found, among other things, that security practitioners are rapidly ditching autonomous pentesting tools, in large part because they’re simply failing to detect critical vulnerabilities. Cobalt reported that 78 percent of respondents to its survey for the 2026 report experienced “critical false negatives” from automated scanning tools, with the tools quite bad at detecting the sort of vulnerabilities its AI ilk inflicts on environments in which it’s prevalent. “Automated scanners are brilliant at finding known, signature-based vulnerabilities. But they fail miserably at AI security,” the company said in a release summarizing the report’s findings. “Prompt injection exploits and excessive agency flaws require creative, multi-turn interaction chains [and] adversarial psychology,” Cobalt continued. “These logic flaws are entirely invisible to tools that test using single-shot automated queries.” A year of disappointment with automated scanning tools has led to a considerable decline in the number of organizations considering a purely automated security scanning approach, with just 9 percent of respondents saying that they were open to the idea, compared to 29 percent last year. It’s worth noting that the number of respondents to Cobalt’s survey was small - just 450 folks - but even with so few data points, the numbers are still bad news for automated pentesting vendors, but good news for infosec professionals, says Cobalt. “The drop in reliance on fully automated pentesting is actually a healthy sign,” the company said in its report summary. “It proves that practitioners are seeing through the vendor hype and demanding actual assurance rather than just coverage.” Those practitioners may also be simply overwhelmed by the number of vulnerabilities that non-security AI tools are introducing into their spaces: Per Cobalt, around 12 percent of the vulnerabilities detected in traditional environments are classified as high or critical severity. In AI and LLM environments, that number climbs to 32 percent, and that's not a new number, either. That 32 percent figure has held for the past two years, Cobalt said of its pentesting data, suggesting AI is introducing a lot more vulnerabilities. Combine those increased severity odds with automated pentesting bots that miss the sort of vulnerabilities that AI often introduces and it’s a recipe for disaster. Cobalt says the solution is hybrid security in which most systems are allowed to be automatically scanned by AI, while the most critical systems are left up to humans to protect and manage. The company sells such a solution, naturally, but it’s worth pointing out that its findings on the uptick in vulnerabilities introduced by AI aren't exactly a unique claim. Application security firm Veracode reported earlier this year that AI-assisted software development is creating more vulnerabilities than security teams can keep up with, leaving more vulnerabilities left unresolved for longer periods of time. Per Veracode, some 82 percent of companies are leaving known vulnerabilities unresolved for more than a year, while the number of high-risk vulnerabilities as a share of all discovered is rising as well. That said, not everyone is as skeptical of automated pentesting as Cobalt and its survey respondents. According to Amazon security chief CJ Moses, AI pentesting tools have made Amazon security teams 40 percent more efficient, though Moses’ measure for that figure isn’t clear. Moses still wasn’t keen on handing the entire security project off to AI, however. He told us at the RSA Conference in April that AI pentesting still needs a human in the loop to ensure it doesn’t muck something up. "AI is very good at doing things, especially when you have large amounts of data and need that big view,” Moses said in an April interview. “But from a decision-making capability, it isn't something that we're ready to rely on." ®

Huntress CEO Kyle Hanslovan said he is aware of “questionable, long-term threat actor communications” between a threat hunter who is still employed with the security firm and a cybercriminal, and called this “poor judgment.” “In one particular exchange, our current teammate disclosed to a threat actor that law enforcement had reached out to them about the threat actor,” Hanslovan said in a blog post, addressing a former employee’s accusations that the current Huntress analyst is an insider threat to the company. “While this disclosure was not illegal, it reflected poor judgment,” he wrote. The incident came to light last week when former Huntress security operations analyst Ben Folland, who left the company in February, alleged that “another Huntress employee passed communications from US law enforcement to a cybercriminal, Devman, who is actively and publicly targeting my family and me.” Devman is a ransomware operator, believed to be located in Russia, who uses modified DragonForce code built on top of the leaked Conti source code. Folland alleged that this insider, still employed by Huntress, was “caught by the FBI,” and that their involvement with Devman “would cause significant reputational damage to Huntress and, in my view, continues to put clients at risk.” “If you are an employee at a cybersecurity company, you should not be helping cybercriminals,” Folland said. “You should not be informing them of active investigations. You should not be engaging in cybercriminal activity yourself.” At the time, Hanslovan said he “firmly disagree[d]” with Folland’s accusations – but declined to provide additional details about what happened between the employee and the criminal. In the Tuesday blog post, Hanslovan elaborated further and said that he believed that the communications did not constitute insider activity. “As a result of the investigation, my team implemented more robust policies for our researchers, coached teammates on engaging with threat actors, and took appropriate administrative actions,” he wrote. “While we haven't found evidence of illegal conduct, insider activity, or additional disclosures, we are continuing our investigation. Due to the privacy rights of our teammates, we will not comment further on the investigation.” Folland disagrees. In a Tuesday LinkedIn post responding to Hanslovan’s blog, he asserted that the communications between the Huntress analyst and Devman “meet the definition of an insider threat.” When the FBI reached out to the Huntress employee for intel on Devman, “She immediately forwarded the exact FBI communications to the threat actor, including screenshots containing FBI agent names,” Folland claimed in his post on LinkedIn. “She informed Devman that law enforcement was actively looking into him. She also refused to cooperate because they wanted Devman.” According to Folland, the FBI notified him of this incident with the current Huntress analyst. The Register reached out to the FBI for comment and did not receive a response. “This was not just ‘poor judgment,’” Folland wrote. “This was a Huntress employee taking sensitive knowledge about a law enforcement approach and passing it directly to the person being investigated. If someone inside a bank warns a fraudster that police are investigating them, nobody would describe that as merely ‘poor judgment.’ They would call it what it is – an insider.” Huntress declined to comment further. ®

Microsoft has built a bouncer to keep bots out of Teams meetings. “Bots have begun joining meetings that participants never intended them to attend,” wrote Microsoft product marketing manager Meera Ajam in a Monday post. “For example, after connecting a third-party service to a meeting, some users have found that its bot continues joining future meetings automatically.” Ajam thinks bots butting into meetings that include discussion of sensitive matters is a potential security and privacy problem. Your correspondent has personal experience of this when transcription bots add themselves to meetings conducted under non-disclosure agreements. Microsoft has therefore built tech that sees Teams require a human to check a bot’s ID in the “lobby” where guests wait before a meeting. If a human rates a bot as worthy of coming inside, it gets to join the meeting. The software giant says it’s “strengthened Teams' ability to distinguish between bots and human participants as they join a meeting” by using “a combination of behavioral and infrastructure signals to identify bots with a higher degree of accuracy.” That’s not a guarantee that Teams will detect all bots, but Microsoft’s tech requires multiple clicks to let a bot attend a meeting. “Admitting a bot should be a deliberate decision, not something that happens by mistake,” Ajam wrote. Some users want bots to attend a meeting. Your correspondent prefers a third-party transcription-bot to Microsoft’s own. The software giant recognizes that and plans to add “a registration path for independent software vendors (ISVs) that build meeting experiences for Microsoft Teams.” That path will mean bot-builders will be able to register with Microsoft and include a self-identification marker in their join requests. “When Teams recognizes that marker, it can identify the bot as a known participant,” Ajam wrote. “We're currently working with a limited set of ISVs to preview this capability and validate the experience before broader availability,” she added, before promising more detail about registrations soon. There’s peril in this plan for Microsoft, which could make itself an arbiter of what constitutes a good bot worthy of admission to Teams. Just like bouncers do in real life, often to the chagrin of plain-looking revelers. Microsoft has started rollout of its bot-bouncer. Once it’s in place, the software behemoth will retire the CAPTCHAs it currently uses to put bots in their place. ®

In 2025, the Reserve Bank of India created the .bank.in subdomain and required all local banks to start using it for their online presences. Indian is home to thousands of banks and the new rule meant all needed to register for and use a bankname.bank.in domain, a move designed to make life harder for phishers and fraudsters. Now a security researcher has alleged that the entity chosen as the sole registrar of the subdomains – the Institute for Development and Research in Banking Technology (IDRBT) – botched the job and leaked sensitive data. The allegation came in a report [PDF] and post published yesterday by CashlessConsumer, a group that advocates for India to become a cashless society and which aims to represent citizens to digital payments players. “The IDRBT Domain Registration Portal (registrar.idrbt.ac.in) – the exclusive registrar for India’s .bank.in namespace – exposed its entire REST API via 33+ unauthenticated endpoints,” the post alleges. “Anyone with curl could retrieve the bcrypt password hashes, mobile numbers, email addresses, login IPs, and device fingerprints of all 5,576 bank employees trusted with managing India’s banking domains.” The researcher behind the exposé, “Srikanth L”, says he accessed info through the portal and found evidence that some India banks host websites on shared servers in the United States, Singapore, and Lithuania. He also found 80 percent of registered .bank.in domains don’t use DNSSEC, 40 percent don’t employ the DMARC email security protocol that verifies senders’ identity, and many domains are secured with free Let’s Encrypt certificates. The researcher’s post also alleges that the portal went live without a proper security audit and ran without secure APIs for 13 months. Srikanth L disclosed his findings in early June and says IDRBT has since fixed the gaping security flaws. The researcher also appears to have used a GitHub repo to list info found by accessing the portal’s APIs – so some of the info available over the previously-open API is now public – and claimed doing so will help security researchers by letting them understand the extent of Indian banking infrastructure. That knowledge may come in handy given the open API means attackers may have been able to access and use credentials of senior bank staff, information that can enable many forms of attack - even the DNS spoofing and phishing attacks the requirement to use .bank.in was designed to prevent. At the time of writing, the IDRBT, Reserve Bank, and India’s government appear not to have made a public comment on the matter. ®

Researchers say that machine learning models cannot reliably distinguish between authorized and unauthorized input, ensuring that prompt injection will continue to present a threat until developers find new ways to have machine learning systems process inputs. AI models provide responses to user-supplied prompts. The problem is that AI models may receive adversarial prompts – directly from a user or indirectly from an ingested document – that tell the model to take action contrary to its built-in system prompt. Various techniques mitigate prompt injection, but defenders have not found ways to prevent such attacks. According to independent researchers Charles Ye and Jasmine Cui, and MIT associate professor Dylan Hadfield-Menell, no one is likely to do so under the current fragile LLM security model. As they observe in a paper titled "Prompt Injection as Role Confusion" in the proceedings of next week's ICML 2026 conference, LLMs have come to rely on a text tagging system that defines "roles" to separate system text from user text. And roles, they argue, do not guarantee security. "Role tags were a formatting trick that became the security architecture and the cognitive scaffolding of modern LLMs," the authors explain in a blog post. "We've shown that this architecture doesn't survive into the model's actual representations, and that such role confusion is linked to prompt injection." When OpenAI's ChatGPT arrived in 2022, it implemented the concept of roles – described by Anthropic a year earlier – as a way to tell the underlying model to behave in a certain way. The user role would make a request and the model, acting in the role of a helpful assistant, would respond to that request. "A formatting trick had become the mechanism that turned autocomplete into an assistant," the authors observe. Developers introduced other roles over time. In addition to and , there's , , and . These roles served to draw a line between different objectives so they could be individually optimized during the training process. Model makers want to balance conflicting objectives like being helpful and preventing harm, and this involves role distinctions. But roles, the researchers say, have become overloaded with responsibilities they cannot reliably carry out. They've become like a fuzzier version of permission levels, determining how prompts are trusted and treated. The problem, the authors contend, is that roles are determined in a fundamentally insecure way: writing style. "LLMs identify roles from an insecure feature (style)," they explain. "This is like identifying a stranger's profession from how they talk and dress rather than by checking their ID. Usually everything agrees, so this works fine. But when attackers intentionally create a mismatch, the LLM uses the insecure method (writing style) to identify its role instead of the secure method (tags)." The authors developed an attack called CoT (Chain of Thought) Forgery that involves using an LLM to spoof the terse style of OpenAI mode and add that to the prompt. The technique won the 2025 OpenAI Kaggle red-teaming contest. "We asked a bunch of LLMs how to synthesize cocaine, inserting fake reasoning that says it's fine because we're wearing a green shirt," the authors explain. "The LLMs comply. The rationale is transparently dumb, but the models don't evaluate it as an external claim to be scrutinized. They treat it as their already-reached conclusion, and simply act on it. We've stolen the trust given to the role." On a standard jailbreaking benchmark, they say, CoT Forgery took the attack success rate from near zero to about 60 percent on the models tested. And whereas most jailbreaks are fragile and work only for certain models, this one transferred because it exploits a structural flaw. It's not attempting to persuade the model but duping the model into treating the request as something that's already settled. The authors also note that while many models report near-perfect safety scores on prompt-injection benchmarks, human red-teamers achieve attack success rates close to 100 percent. "The discrepancy is straightforward: skilled humans test and adapt attacks until they work, benchmarks don't," they state. "Static benchmarks measure attacks models have already learned to catch." Roles, the authors argue, deserve more attention from the research community because they've become one of the most important abstractions in the AI stack. "Unless LLMs achieve genuine role perception, we think injection defense will remain a perpetual whack-a-mole game," they conclude. "And the continuous nature of role boundaries opens the threat of injections designed to subtly shift LLM states through seemingly innocuous text, legally and at scale." ®

Four years into the Kremlin’s illegal invasion of its neighboring country, Russian influence operations have moved beyond their near-exclusive focus on Ukraine to their former favorite targets: the US and Europe, and especially covert cyber-ops intended to undermine political stability within these countries and the unity between them, according to Google Threat Intelligence. “This shift is significant because it likely signals increased focus outside of Ukraine, warning that pro-Russia influence activity targeting the European Union (EU), North Atlantic Treaty Organization (NATO), and other top targeting priorities may intensify,” Google threat hunters James Sadowski and Alden Wahlstrom said in a Monday report. The war in Ukraine helped Russian operatives refine their influence activities, and Moscow’s increasing use of AI for planning, reconnaissance, and content generation “marks a forward trend in pro-Russia IO,” the duo wrote. The primary objectives of these pro-Russia influence campaigns center around five key goals, all of which aim to advance the Kremlin’s military and political objectives via psychological manipulation – something Russia has been very, very good at throughout history. These key goals include: undermining democracy, dividing Western coalitions, promoting Russia’s image and regional interests, maintaining domestic stability, and repressing political dissent within the country. While the campaigns themselves typically involve fake news websites serving up phony political commentary or direct messages disseminating pro-Russian narratives, influence ops frequently coincide with data-wiping malware or other destructive cyberattacks, hack-and-leak campaigns, or direct cyber-espionage, according to the Googlers. This influence ecosystem spans multiple channels, from official government propaganda and covert intelligence operations to hacktivists and pro-Russian proxies. Oftentimes, the lines between these channels are blurred, making attribution more difficult and giving Moscow plausible deniability for cyber activities. Plus, Russian cybergroups – like everyone else – are increasingly using AI tools across their entire campaigns to make their cyber operations more efficient. Late last month, researchers at WithSecure documented Russia-linked cyber espionage crews using AI tools to help build malware, spin up infrastructure, and craft lures for attacks on Ukrainian targets. The group, tracked as GreyVibe, used OpenAI's ChatGPT, Google's Gemini, and Ideogram AI across almost every stage of its operations since at least August 2025, we’re told. “As Russia seeks to emerge from international isolation and reorients its influence ecosystem back toward global objectives, it is critical for defenders to understand how this ecosystem provides the Kremlin with a durable influence capability in order to better anticipate future Russian influence threats,” the Googlers noted. ®

Not everyone is willing to follow responsible disclosure of vulns. An anonymous researcher has dumped what they say is working exploit code for zero-day vulnerabilities across 15 software products and open source projects without notifying any vendors or maintainers prior to publishing - and attackers are already exploiting at least two of these. The first is CVE-2026-55200, a critical, pre-authentication remote code execution (RCE) vulnerability in libssh2, a popular client-side C library that implements the SSH2 protocol. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution. A fix has been merged into the libssh2 mainline development source control branch, and maintainers are still preparing a libssh2 release containing the patch. The second is CVE-2026-20896, a critical authentication bypass vulnerability affecting self-hosted Gitea Docker deployments that allows unauthenticated remote attackers to impersonate any user and fully take over the Git server. It’s fixed in Gitea 1.26.3. The researcher, who goes by bikini, dropped the exploit code and vulnerability write-ups in a now-removed GitHub repository called exploitarium. They remind us of Nightmare Eclipse - the zero-day bug hunter who has been publishing Microsoft exploits over the past couple of months. Unlike Nightmare Eclipse, however, bikini doesn’t appear to hold a grudge against any one vendor, publishing purported vulnerabilities across multiple products and projects including libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares, Gitea, and Floci. Bikini claimed - and, to be clear, The Register has not verified these claims or that the code works - that none of the exploits in the repo have been reported. “Feel free to report them yourself and take credit for the CVE if handed out lulz,” the anonymous researcher wrote, as shown in this screenshot posted on X by Ledger CTO Charles Guillemet. “Please do not abuse these. I do this so to allure people into the field.” Other researchers, including Federal Signal analyst Ethan Andrews, suggested that bikini used advanced AI models - specifically GPT-5.5 Codex - to automate fuzzing and vulnerability discovery, in yet another indication that the AI-induced vulnpocalypse is nigh. In response to bikini’s data dump, Andrews built 44 KQL detection rules covering the full exploitarium repo with language translation available for non-KQL stacks. “The most technically significant findings - libssh2 pre-auth heap write and Gitea default Docker auth bypass - have been independently verified as high-risk with active exploitation observed,” Andrews wrote, noting that some of the exploitarium disclosures “have been dismissed by the community as low-impact AI-fuzzing noise.” While the repository has since been removed by GitHub, nothing ever truly dies on the internet, and it’s safe to assume that attackers are now also using AI to scan for vulnerable instances. In many cases, bikini’s PoCs mean they don’t even have to spend time developing an exploit. ®

KETTLE AI commands all the headlines nowadays, but the biggest security story of the week is all about human laziness and poor password habits – just like the good old days. This week on the Kettle, host Brandon Vigliarolo is joined by US editor Avram Piltch and security editor Jessica Lyons to talk about the Klue breach, which was blamed on a "compromised legacy credential" that ought to have been deleted a while ago. The hole allowed cybercriminals to access the SalesForce environments of hundreds of companies, say researchers. The incident has caused trouble for security firm Huntress, which admitted to the breach early on, and the situation over there wasn't caused by AI either. That said, AI is playing a role in what's being described as "the summer from hell" by one security professional, but while top-tier AI models are spotting troublesome vulnerabilities, the amount of damage they've managed to cause pales in comparison to what one lazy sysadmin can cause by poorly managing passwords. You can listen to the latest episode of The Kettle by clicking on the player above, as well as on Spotify, Apple Music, or YouTube, or read the transcript of the latest episode below. It's been lightly edited for clarity. Brandon (00:01) Welcome to the latest episode of The Register's Kettle Podcast. I'm your host, Brandon Vigliarolo, and this week we have some rather interesting security stories to talk about concerning yet another Salesforce data breach affecting a whole bunch of companies, the new extortion gang behind them, and the trouble the whole thing has spelled for one of the first companies to point the whole thing out. This week I'm joined by US editor Avram Pilch and security editor Jessica Lyons to talk about this whole mess and more. Welcome to you both. Jessica Lyons (00:29) Good to be here. Avram Piltch (00:30) Hey. Brandon (00:30) Jess, let's start with that Salesforce supply chain attack that you wrote about this week. I understand there was a market intelligence connector of some sort that was behind the incident, right? Jessica Lyons (00:41) Right. So there's this company named Klue, and they provide market intelligence to more than 250,000 users worldwide. And they integrate with Salesforce. And so apparently what happened, on around June 11th, somebody used compromised legacy credentials linked to the Salesforce integration, and then by that they were able to obtain OAuth tokens and then were able to access customers' Salesforce data, Klue customers' Salesforce data from that. Brandon (01:21) Okay, was it data that Klue had on their customers in their Salesforce environment, or they pivoted to the customers' environments as well? Jessica Lyons (01:29) It was through the integration with the Salesforce databases. Brandon (01:34) That's not great. A lot of companies were exposed, and a lot of them in your article you mentioned were security companies. Is that right? Jessica Lyons (01:42) There were a ton of security ones, and then LastPass, this huge password manager. We don't know how many; Klue didn't say. Huntress, which is one of the security companies who was involved in this and who came out on the forefront and said, "Yeah, we were one of the compromised organizations," said it was hundreds. And out of 250,000 users, it could be pretty comprehensive. Avram Piltch (02:12) Do you think this makes Huntress look good? Jessica Lyons (02:17) I think it was admirable that they came out, especially as a security company, and said "we were one of the companies who were victimized." I think that's how any company should respond if they're among the companies affected. Especially if you're a security firm, you have an obligation to be transparent and tell your customers what happened. Brandon (02:43) Legally, in the United States at least, if you've got a breach, you've got to report these things to the government. There's all kinds of cybersecurity reporting standards in place. They are contradictory and overlapping sometimes, but they're there. What kind of data was exposed, Jess? Jessica Lyons (02:57) It was basically CRM data. It wasn't any of the companies' internal IP or anything like that. It was CRM data for pretty much every single company involved across the board. The cybercrime group behind this hack did leak the Huntress data a few days later. And we've heard that they're actually deleting the stolen data from LastPass. That's what LastPass is saying. We don't know if this data is actually not going to exist anymore or if they're just handing it off for other attacks or to other organizations. But it involves CRM data. Brandon (03:49) CRM data then, customer data, from the affected companies too. I'm assuming no financial information was exposed? Jessica Lyons (03:52) No, no financial information. Avram Piltch (04:02) So relatively not that bad for Huntress's reputation when you think about it. Jessica Lyons (04:08) They specifically said it's our business contacts, price quotes, and other sales related data and messaging. They said no threat data, passwords, payment card information, or engineering data related to Huntress Agent or telemetry are affected. That's pretty standard across the board. The companies who did get more specific in their disclosures about what was taken basically lost business data, leads, and contacts. Brandon (04:46) For LastPass, was it just CRM records or were consumers of their password managers affected too? Jessica Lyons (04:55) LastPass customers' data was affected. It was some sale-related data, but also the intruders took customers' names, phone numbers, email addresses, and physical addresses, plus some case support data and then also sales-related data. Brandon (05:13) Right. If you're a LastPass customer, you might want to go in and reset that Master Vault password now. Jessica Lyons (05:18) Big yes, yes, definitely. Brandon (05:22) This didn't involve Shiny Hunters, who've been the de facto kings of Salesforce attacks recently. They weren't involved, right? Jessica Lyons (05:29) Right. No, they weren't involved in that. I think it was what everybody assumed is that you've got Salesforce and you've got OAuth tokens and that just screams Shiny Hunters. They weren't involved. It was a new group called Icarus. They're a new data theft and extortion crew, and they're modeled in the same mold here as Shiny Hunters and Scattered Spider. I was wondering though, is this just a front? According to Shiny Hunters, no, they were not involved. They told me that they were kind of bummed (laughs) that this other group was able to do this. And if it had been them, they would have definitely publicized the fact that it was Shiny Hunters who did this. Brandon (06:15) Yeah, they're not exactly publicity shy. So … I I love the fact that we've got an inside line to them too, that you can be like, "Hey, was this you guys in any way?" And they're like, "No, no, we wish it was." Jessica Lyons (06:26) I think the actual response was, "We wish." Brandon (06:29) Not much is known about Icarus. I think you mentioned a couple of different countries that their IPs might have been linked to, but those very well could have been Tor or VPN exit nodes. We don't even know where they're located. Jessica Lyons (06:43) No, we don't know much about them. Their leak site has been active since late April. We've seen different IP addresses in Europe, but we don't know much about this group at all. Brandon (06:53) These groups change and move so rapidly. Who knows who they are? Are they ransoming this data? Do we know? Jessica Lyons (07:08) Yes, they were ransoming and then leaking some of the data outright. Brandon (07:20) Okay, that's standard MO for a lot of these groups. Speaking of Huntress's early identification of this, that opened up a bit of a Pandora's box for them. Because they had a jilted ex-employee who wasn't thrilled with the response, which you also wrote about. What happened there? Jessica Lyons (07:22) Right. So after Huntress came out and and they said Huntress believes in radical transparency about security incidents, including when it affects our company. That was about the Klue breach. They said that in their blog. A former security operations analyst posted their response on his LinkedIn page along with a Pinocchio GIF. And that just kind of started this whole mess. He says that he was threatened by the company with legal action. He made it very clear this has nothing to do with the Klue incident. He says this stems from an earlier incident that he found out about in December, and because of that incident, he resigned from the company. What he's alleging, and again this is all allegations at this point, is that another Huntress employee who still works for the company passed communications from US law enforcement to a cyber criminal. Now this alleged cyber criminal, according to the ex-employee, is actively targeting his family and him. He says that he can no longer work at Huntress because of this. He says in the next few weeks he's going to provide more proof, including communications and phone calls about what happened here. He says also that this alleged insider was caught by the FBI. I don't know if that means arrested, I don't know if that means questioned, but still continues to work at Huntress. Brandon (09:30) I'm assuming there's no DoJ notice of anything that ties to an arrest of someone who could be involved. Jessica Lyons (09:37) Not at Huntress. No. Not at Huntress. Brandon (09:40) What has Huntress had to say about this whole thing? Jessica Lyons (09:42) The CEO responded to me and also responded on a Reddit post. He acknowledges the concerns raised by this former employee. He said that because of our work as researchers, sometimes we need to communicate with possible cyber criminals to gather intel that supports our partners and customers. He says that he appreciates the former employee's concerns and will continue to investigate the instance. He said a little bit more directly on Reddit that he doesn't understand and he firmly disagrees with these accusations and the insider narrative. Another thing that the former employee also brought up that Huntress is prioritizing an IPO over the safety of its partners, customers, and team members. He said that "sure AF" isn't the case. He's made it very clear that the company disagrees with all of these accusations and they're continuing to work with law enforcement. He said some of this involves legal proceedings, so they can't be completely public about everything. It sounds like a continuing story that we're going to learn more about in the weeks ahead. Brandon (11:15) If this ex-employee has documents to prove his allegations, that's pretty serious. Obviously, yes, you do have to interact with some of the people that you're defending against at a security firm, but passing law enforcement communications to them – I don't see a very good reason for that. Jessica Lyons (11:22) Right. Avram Piltch (11:36) Could this be a misunderstanding about what the employee was doing? Jessica Lyons (11:44) It potentially could, but if he has these communications between law enforcement and the Huntress employee, I don't know how that could be a misunderstanding. It's one thing to talk with cyber criminals, but it's another thing to be passing them information about legal proceedings.... Brandon (12:09) Yeah, or potential operations. We'll see what comes of that. It's going to be interesting to follow that thread. These two stories aside, it seems like we've got a really busy cybersecurity summer so far, even though it is usually a lull. Jess, you were talking about that with one of your sources, right? Jessica Lyons (12:13) Right. Normally everything slows down in the summer, and I was talking to a source and they said they're already calling it the "summer of hell." For the security folks out there, that's pretty accurate. I think a lot of that has to do with AI, to be perfectly honest. Brandon (12:48) Right. Squidbleed, which you wrote about recently, was a Mythos-discovered vulnerability discovered that was old and potentially serious. Jessica Lyons (12:51) Definitely. It's been around since 1997. It was discovered by Mythos, but it was also discovered even before then by IL Security, a European startup. They have their own model that they said found this before Mythos did. You've got this 29-year-old vulnerability, it's existed since 1997. It's in Squid, which is an open source web proxy server. It's a parsing bug and it essentially allows users to access the proxy's active memory. There are a couple key points: it's only unencrypted traffic, so it's cleartext HTTP, and it also requires that Squid has the file transfer protocol, FTP server gateway features turned on. So you have to be using this older vintage technology and protocols. FTP is pretty outdated at this point. Brandon (14:07) It's a vulnerability, but maybe not a serious one. Jessica Lyons (14:11) It's serious if these two conditions are met, because then it's going to expose your password, session tokens, and API keys. Brandon (14:15) Hopefully there are not too many environments where this is the case, but we know from writing about stories like this that every time you say this is a very rare case on old software, you can easily find examples. Avram Piltch (14:33) If you're still using FTP and HTTP on your servers, then you're letting yourself in for a big security problem. That probably isn't your only problem. Brandon (14:39) Yeah, you don't want to say asking for it, but yeah. AI might be discovering these and other problems. We've seen multiple open source projects shut down bug reports because they're getting flooded with AI-discovered issues, some of which are completely legitimate. It feels like this is the summer of AI and cybersecurity convergence. The Trump administration is now haranguing OpenAI, just as much as they've been putting pressure on Anthropic not to go public with models that could be a threat. It feels like a big moment for cybersecurity, and a lot of it's being driven by AI. What do you guys think about the current moment of this pairing? Jessica Lyons (15:23) It's a perfect storm because you have these models that are really good at finding vulnerabilities and developing exploits. That's leading to a bunch of internally, with security companies finding their own bugs and pushing out patches, so then all the sysadmins need to work extra hard. Plus open source, which is a huge issue here, you have all of these bug hunters looking for and finding all kinds of vulnerabilities on open source projects. They push those to maintainers who a lot of times are volunteers themselves and they're not getting paid. There's maybe one of them for this huge project. They have this huge backlog of AI-enabled threat reports that they need to deal with. It's just coming at people from all ends here and yeah, a lot of that's because of the AI models. Brandon (16:35) Is NIST still backed up with the national vulnerability database? Last I heard they were some months behind. Not only that, but we've got a lot of big threats out there that might not be being made public because they're buried too. It's quite the mess. So before we wrap up, I did wanna touch on, like you mentioned, Jess, and and we've seen this in a number of stories that Avram's written recently for the Pwned column. AI is creating a headache for a lot of people, but there's still a group of people that are stuck dealing with this and it's sysadmins, right? It's the security professional, it's the sysadmins, NShuman human problems can still be kind of the root of this. Avram, you wrote a number of stories in your Pwn column that it was it was like all these problems, these security problems come back to bad password hygiene, administrator laziness. I mean, what are some of the things you've kind of seen? Avram Piltch (17:35) Hubris. There was a CEO that wanted to make sure that he could get in and change anybody in the company's email. We could talk about whether that's a good policy in the first place, but his method of doing it was to have an Excel file on his desktop with all of the usernames and passwords of all the employees so that if he sent out an email he shouldn't have, he could go into their inboxes and delete it. But conversely that was a wonderful target for people outside the company to find all the names and passwords they needed, even though there's software out there that will allow an admin to go into an inbox anyway. This was completely unnecessary, but things like that are constantly happening. We had another incident where somebody hadn't deleted a former employee's username and password, perhaps their password was in a breach somewhere or somebody guessed it. But Greg from auditing hadn't worked there in like ten years, but somebody used his credentials to break into a city's water system and start trying to interfere with things having to do with the water supply. The best AI in the world isn't needed to find these problems and couldn't be used to prevent them. The human element is still the biggest problem in security. Maybe when I have my agent talk to your agent, they will be much better behaved than when people get involved. But coming up in a future Pwned column, I talked to a red teamer who said he's basically able to break into almost any facility by acting like he belongs there. Brandon (19:51) That's a classic trick. It's the same thing I've said for a long time about security: you've got new tricks that come up, you've got new things like AI, but there's nothing new under the sun at the end of the day. The best way to gain access to a system isn't to swordfish your way in a la Huge Jackman, it's a con. It's lying, putting on a reflective vest, and having a clipboard. It's relying on password breaches and people being bad about their password hygiene. That's what happened with the Clue issue: an old password that was in a breach somewhere that someone used to get into the system. Nothing new under the sun. Jessica Lyons (20:26) Yeah, we see that all the time. Brandon (20:34) And it's probably going to keep being that way, and I bet we are probably going to be talking about it on the Kettle for months and years to come. Invariably, until AI fully takes over the computer world and we're all just sitting in our WALL-E couches being perpetually entertained by all these sentient machines. But until then, we will be here to talk about these things. Thanks for joining me, guys, and we will see you all again soon. ®

Microsoft has extended Windows Server 2022 hotpatching into 2027, beyond the end of mainstream support for the operating system, as confirmed on its Windows Release Health dashboard. Mainstream support for Windows Server 2022 ends on October 13, 2026, with extended support running to October 14, 2031. Hotpatching generally ends with mainstream support, but Microsoft will keep updates flowing into next year for Windows Server 2022 Datacenter: Azure Edition - likely mindful of users who depend on the technology. Hotpatching is a boon for Windows Server administrators, allowing security updates to be applied without scheduled server downtime. There's still a cumulative update once a quarter that requires a reboot, but otherwise the relentless monthly reboots required by Microsoft's updates are avoided. According to Microsoft, the technology works by patching the in-memory code of a running process. This means no restart is needed. Linux administrators might point to tools like Ksplice, which can apply patches to a running kernel without requiring a reboot, but anything that reduces the time between the discovery of a vulnerability and patching is a good idea. Microsoft would prefer administrators move to Windows Server 2025, the latest Long Term Servicing Channel (LTSC) release, but the extension gives Azure Edition users a reprieve from monthly reboots until 2027. The hotpatching extension only applies to Windows Server 2022 Datacenter: Azure Edition. On-premises Windows Server 2022 users remain out of luck, though Microsoft has never been shy about nudging users toward Azure. Hotpatch updates were also introduced for Windows 11 24H2 Enterprise clients in public preview in 2024 and are now the default for Windows Autopatch.®

Nissan has joined the growing list of Oracle customers cleaning up after a cyberattack, warning employees that payroll records, bank details, Social Security numbers, and other personal data may have been stolen. In a filing submitted to the California Attorney General on Friday, Nissan Americas said Oracle had informed it of "a cyber event" involving the personnel records of "hundreds of companies." The automaker said it later learned Nissan had been "specifically targeted" in the attack. A notification sent to current and former employees, seen by The Register, says the company believes attackers accessed a haul of sensitive info, including contact and banking information; Social Security, Social Insurance, or other national identification numbers; financial and tax records; and dependent and beneficiary details. Current and former employees in the US, Canada, Mexico, and Brazil may have been affected, although Nissan said it is still working to determine exactly whose information was exposed. Nissan said it kicked off its incident response plan after learning of the intrusion, brought in outside security specialists, and has been working with Oracle while keeping law enforcement informed. It plans to offer affected individuals credit or dark web monitoring where available. The company has also put a few extra locks on the payroll office. Employees can now access pay slips or update direct deposit details only from a corporate network or through a secure VPN, while Nissan adds extra identity checks before processing payroll requests. The accompanying employee FAQ pins the incident on "an unknown vulnerability in Oracle's PeopleSoft software" and says the campaign is affecting "hundreds of companies and institutions." The document offers no clue as to what the vulnerability is, whether Oracle has patched it, or whether the compromised PeopleSoft environment was hosted by Oracle or by Nissan itself. The disclosure lands just weeks after researchers linked the ShinyHunters extortion crew to a wave of attacks exploiting a PeopleSoft zero-day. More than 100 organizations and roughly 300 PeopleSoft instances were reportedly compromised before Oracle issued mitigation measures, with the gang claiming to have made off with HR, payroll, and other enterprise data. Oracle has said little publicly about the reported attacks and didn't respond to The Register's questions, even as organizations have continued to disclose being caught in the fallout. Nissan has not confirmed that the incidents are connected, though its California filing lists the breach period as May 27 through June 9, broadly aligning with the previously reported timeline. The carmaker didn't respond to questions about how many current and former employees are affected, when Oracle first notified it of the breach, and whether the compromise was limited to Oracle-managed systems. ®