News

EXCLUSIVE Google has a security hole in a Kubernetes operator that could allow attackers to bypass Google Cloud Platform (GCP) identity and access protections and gain full control over any organization's cloud environment. Or it has a serious communication and transparency problem when it comes to its bug bounty programs. Maybe both. Researcher and frequent cloud bug hunter Justin O'Leary told us that he found and reported to Google a major flaw that allows any Kubernetes namespace user to bypass GCP's Identity and Access Management (IAM) controls and therefore gain root access to managing an organization's cloud resources. Google initially rated the bug high priority and high severity, with a rep telling O'Leary "Nice Catch!" Then, the cloud giant changed course and told O'Leary and The Register that there's no vulnerability, so no fix and no reward payout. The bug report, however, is still marked high-priority and accepted. O'Leary spoke exclusively with The Register about the vulnerability, which he named ConfigConfusion, and what has happened since he reported it to Google on March 8. He is also releasing a blog post with more details. It stems from an issue in Config Connector, an open source Kubernetes add-on that lets users manage Google Cloud resources through Kubernetes. According to O'Leary, Config Connector doesn't perform an authorization check, and this allows any Config Connector service account with org-level permissions to bypass Identity and Access Management (IAM) authorization and gain the highest level of control (roles/owner) to an entire GCP Organization – the root node of all of a company's resources within Google Cloud. On March 27, a Google security engineer accepted O'Leary's report and told him: "Nice catch!" The employee said that they filed a bug based on O'Leary's report with the relevant product team and assured him the Chocolate Factory's security squad would work with relevant Google Cloud people to fix the flaw. "We'll work with the product team to ensure this issue is address. We'll let you know when the issue was fixed," the engineer said. "In the meantime, review the payment option selected in your bughunters.google.com profile." Google assigned the bug P1 priority and S1 severity, signifying a flaw worthy of urgent repair because it affects a large percentage of users and can disrupt core organizational functions. "I figured that was the end of that," O'Leary said in a phone interview with The Register. Eleven days later, on April 7, he received a new message from a Google Security Bot reversing the earlier decision. The Reg viewed the email, and O'Leary included a screenshot in his Thursday writeup. The message said that the Cloud Vulnerability Reward Program panel decided that the "security impact of this issue does not meet the criteria to qualify for a reward." After reviewing the bug report, Google determined the software "is working as intended," the message continued. It also noted that the program's decision not to pay a bounty "does not mean that the product team won't fix the issue." Nearly three months later, the case remains P1/S1 with the status "in progress (accepted)." Google hasn't assigned a CVE or issued a fix. O'Leary didn't receive any reward for his research. This isn't the first time this has happened to O'Leary – or other security researchers submitting bug bounty reports. O'Leary had a similar experience with Microsoft earlier this year. In a story that has become all too familiar among bug hunters, O'Leary disclosed a privilege escalation vulnerability in Azure Backup for AKS. Microsoft rejected his report – and then silently patched the flaw without assigning a CVE or publishing a security advisory. "This is a pattern," O'Leary told us. "This is just how these trillion-dollar companies deal with people like me. In my day job, we use GKE, and it's incredibly frustrating on my end, when I find a critical vulnerability in the system that's being widely used, and I can't even get the vendor to patch their own stuff." Google's response When The Reg asked Google about O'Leary's situation, the company told us that it didn't issue a bug bounty reward because there's no vulnerability. “The issue reported does not qualify for a reward because the GCP IAM authorization bypass is only exploitable if an attacker has access to a Config Connector Service Account that’s been granted the Organization Admin role by the organization (i.e., it is privileged)," a Google spokesperson said in an email to The Register. "Additionally, an attacker would first need to gain entry to an organization's environment (e.g., an exposed container) in order to leverage the privileged Config Connector instance and execute commands with administrative authority, such as the IAM bypass," the spokesperson continued. "Granting this level of access to the Config Connector Service Account goes against Google Cloud’s publicly shared best practices and the principle of least privilege." Google did not answer The Register's questions about why the bug report case remains marked in progress – and not closed – on its end of things. O'Leary told us this is the same explanation he received. And he doesn't buy it. Yes, the Config Connector service account does need org-level permissions to manage resources across multiple GKE clusters. But Google's own documentation instructs users how to do this, he noted. We confirmed this as well. Moreover, "having those permissions doesn't mean any namespace user should be able to abuse them," O'Leary posited. "A developer with kubectl access to one namespace – and zero GCP IAM permissions – should not be able to become Organization Owner. They also shouldn't be able to impersonate any service account in the project with no audit trail." According to O'Leary: "The vulnerability is the missing authorization check. Config Connector executes privileged operations on behalf of users without verifying those users are authorized." Three lines, five seconds, full admin control In a video demonstrating ConfigConfusion, O'Leary shows how an attacker can write three lines of YAML to achieve full administrative control of a GCP Organization in about five seconds. "Config Connector has these missing validation checks," he said. "Config Connector is basically a Google-managed Kubernetes operator, and I found that having these missing validation checks creates these confused deputies, which means there's no validation of who's asking for what." Confused deputies pose a major security challenge because they allow an entity that doesn't have permission to perform an action to force a more-privileged entity to perform the action. To exploit this issue, a user with kubectl access to one namespace – and no GCP permissions – submits a malicious IAMPolicyMember, which escalates the attacker's privileges. Config Connector passes the user-controlled organization ID directly to the GCP IAM API without performing an authorization check, making the user a GCP Organization owner. This gives the attacker full admin control over everything in the environment – projects, secrets, billing, and Gmail accounts. "And there's no record of it," O'Leary said. This is because "the attacker's Kubernetes identity never touches GCP IAM," he wrote in the disclosure. "Config Connector executes the request using its own elevated credentials." 'Jenga' vulnerabilities According to O'Leary, Google has fixed this confused-deputy issue twice before in different services that access GCP. Tenable Research documented those issues and reported them to Google. One, called ImageRunner, abused permissions in Google Cloud Run to pull private Google Artifact Registry and Google Container Registry images in the same account. The second, ConfusedComposer, allowed an identity with edit permissions inside a Cloud Composer environment to escalate privileges to the default Cloud Build service account. "This privilege-escalation vulnerability in GCP builds upon a broader attack class of vulnerabilities in cloud services that we call 'Jenga,'" Tenable security researcher Liv Matan said at the time. ConfusedComposer "exploits the somewhat-hidden cloud provider misconfigurations related to cloud services permissions to escalate privileges beyond intended access levels," Matan explained. "This variant highlights how attackers can abuse interconnected services the cloud provider automatically deploys behind the scenes, as part of a service-orchestration process." Google ultimately added authorization checks to both Cloud Run and Cloud Composer. O'Leary says he doesn't understand why Google can't also add that check to Config Connector. Or perhaps he does. "It's just me versus Google," he said. "They can't do that same level of gaslighting to Tenable because they have PR teams and legal teams to fight them. I'm just a guy saying I don't understand how this is true" – that is, how something can be both a high-severity, high-priority bug and also working as intended. "And they just say: 'Well, it is true.'" ®

PWNED Welcome back to PWNED, the weekly column where we register some of the worst tech security mistakes our readers have ever seen. Our goal: to help you not do the same. 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. This week's tale of code carelessness comes courtesy of a database administrator we'll Regomize as Joker. Back in the first decade of the 21st century, she went for a job interview at one of the USA's leading national cellular carriers. What she saw would make you want to swap your SIM. After a successful meeting with a hiring manager, Joker was hired on the spot. Within hours the company sudo-level access to a database server, then instructed her to "take a look" at some of the databases. Joker soon realized the carrier's security was no laughing matter as she found herself accessing the main production server for the company's data services division, overseeing all services for the mobile web. This story took place in a time before the iPhone, so she was looking at nasty little versions of websites comressed for viewing on their BlackBerries or flip phones. After peeking around some more, Joker discovered that she had access to the master customer table. It contained nightmarish quantities of personally identifiable information: names, addresses, Social Security numbers, billing info, and even full 16-digit credit card numbers. All of this info was stored in the clear, with no encryption or obfuscation. The CVVs were missing from some credit card info, but many were present. "There was a central billing system upstream on Amdocs servers, but this database also had billing details so they didn't have to reach back upstream to Amdocs if users asked to provision new services," Joker said. After Joker informed management about the mess, they deleted the offending info and forced the developers to go upstream again for billing information, just like they should have been doing in the first place. Joker, like any reasonable DBA, assumed access to this information would be tightly controlled - not made available to new staff with full access rights on their first day. She also assumed her new employer would tokenize key pieces of data because that technique means certain info – say credit card and Social Security numbers – would not be visible in the same table as a customer's name and address. Instead, there would be tokens linking back to the actual numbers stored in a secure token vault. This is common in payment systems. If Joker were less ethical or someone else had gained admin access, they could have exfiltrated large amounts of sensitive data. Permissions should start from a zero-trust assumption and provide only what someone needs to do their job. Joker said that when she later moved on to work for a major online retailer, security was front and center, proving that some people did get it, even back in the George W. Bush era. ®

Cybercrime now accounts for more than 30 percent of all offenses across the Asia and South Pacific (ASP) region, according to the latest figures from Interpol. The international cop shop said on Wednesday that the region has seen “a dramatic increase” in the number of recorded cybercrimes, driven largely by an uptake of digital infrastructure, new technologies, and the increasingly organized nature of criminal networks. Interpol’s latest ASP Cyberthreat Assessment Report states that online scams and phishing attacks dominate cybercrime in the region. Data taken from 2024-2025 shows that phishing campaigns have matured beyond the spray-and-pray mass emails of yesteryear and now resemble the more sophisticated techniques deployed elsewhere in the world. Targeted spear phishing is more common nowadays, and the growing use of AI helps even low-skilled script kiddies to apply a layer of authenticity to their attacks. The region’s problem with organized scamming gangs that run camps where hundreds of people are compelled to commit crimes is especially pronounced and well-documented. A United Nations report published last year described scam call centers across Southeast Asia as an epidemic that is metastasizing across the region “like a cancer.” These compounds can be found across countries such as Cambodia, Laos, Myanmar, and the Philippines, and often see vulnerable individuals trafficked into the scam centers to work under poor conditions – or even as slaves. Interpol cited Singaporean research, which estimated the regional scam industry generates close to $40 billion each year. AI tools, especially those capable of generating convincing deepfake imagery, have also proven popular with cybercriminals across ASP, just as they have beyond the region. In 2024, the same scam compounds were found using deepfake imagery to support romance scams. In February 2024, an employee at a multinational business in Hong Kong was duped into authorizing a $25 million payment because the faces of company execs were convincingly deepfaked on a video call. A similar case was also reported in Singapore in March 2025, when a finance director at a different multinational was tricked into transferring more than $499 million following a Zoom call in which fraudsters assumed the identities of company chiefs, including the CEO and CFO. Interpol’s report highlights how cyber threats are evolving into large-scale challenges for multiple jurisdictions, and no longer represent relatively uncommon, isolated incidents. While digitization across the region is growing, opening new economic opportunities for these countries, law enforcement agencies are struggling to keep pace with the increase in cybercrime. Many lack the skills and tools needed to investigate these crimes. The issue is especially pronounced in developing countries and small island states in the Pacific, which face “significant resource and capacity constraints,” and are thus more vulnerable to direct targeting in attacks by criminals who have a greater chance of evading consequences. Neal Jetton, cybercrime director at Interpol, said: “The findings in this report highlight a rapidly evolving cyber threat landscape across Asia and the South Pacific, where cybercriminals are leveraging artificial intelligence, ransomware-as-a-service models, and sophisticated social engineering techniques on an industrial scale. “As digital adoption accelerates across the region, strengthening operational cooperation, information sharing, and cyber resilience remains essential to protecting communities and critical infrastructure.” Some improvement Interpol lauded many jurisdictions and governments within the ASP region for their proactive approaches to countering cybercrime growth. Hong Kong and the Republic of Korea are two areas that have made strides by introducing new cybersecurity legislation, while others have established national task forces, codified national action plans, and launched awareness campaigns. But even in more developed countries globally, and those with more mature cybersecurity regulatory and legislative landscapes, the issue of increasing rates of cybercrime persists. While Interpol does not collect cybercrime figures for other regions, such as Europe and North America, in the same way that it does for ASP, it’s easy to see that problems persist everywhere. The UK’s Office for National Statistics (ONS) publishes crime rates by type across England and Wales each year, and while computer misuse offenses in 2025 decreased by 58 percent compared to 2017’s figures, there were still an estimated 735,000 cases across the year. Expanding the data to look beyond pure cyber offenses to cyber-supported crimes, such as banking and credit fraud, these offenses account for more than 2.7 million of the circa 9.6 million total crimes committed. The FBI in the US produces its annual IC3 report examining the rates of cybercrime across the country. Although it doesn’t compare it to total offenses or other crime types, the latest report reflecting 2025’s figures showed cybercrime reports topped one million for the first time, and total losses reached a record $20.87 billion. ®

UPDATED If you have a Fortinet firewall, it's time to stop and change your passwords. Intruders somehow gained access to around 75,000 Fortinet firewall devices and stole credentials belonging to major corporations across 194 countries, in some cases leading to full network compromise. Security researchers say that they have verified the data, and the cracked FortiGate passwords belong to accounts spanning multinational corporations including FoxConn, Samsung, Comcast, Siemens, Lenovo, FedEx, PxW, Accenture, Oracle and many others. Check to see if your organization made the list of affected domains – and immediately rotate all passwords associated with Fortinet VPN and administrative interfaces. Make sure multi-factor authentication is turned on, too, as this type of massive credential leak can lead to very serious consequences, giving attackers full, remote access to not only the firewall but the entire corporate network. Hudson Rock, which analyzed the data, said the leak affects 21,632 unique domains. “The scale of this breach touches nearly every sector of the global economy, sparing no industry. The threat actors have built a verified database of working credentials for some of the largest enterprises on the planet,” the security shop said on its Infostealer blog. Researcher Volodymyr “Bob” Diachenko first spotted the intrusions and attributed them to a Russian-speaking group. “They intercept SSL VPN authentication, crack hashes on a 45-GPU cluster managed via Hashtopolis, and pivot into internal Active Directory environments,” he wrote on LinkedIn. “The operation processed 1.16 billion credential attempts against 320,777 FortiGate targets and 2.1 billion attempts against 163,650 MSSQL servers.” Plus, according to Diachenko, the criminals fully pwned at least four organizations, including a Turkish NATO defense contractor, and, in that case, stole classified defense documents. Security sleuth Kevin Beaumont, who also verified the stolen credentials, said “the data is legit.” “I have worked with several orgs listed, and can confirm the logins and passwords are real,” Beaumont wrote. “Many of the devices sampled are on fairly recent patches.” According to device search engine Shodan, the massive heist comprises about half of all internet-facing Fortinet firewalls. Plus, Beaumont noted, most of the compromised Fortinet devices remain online. So if you’re still reading this story: stop now, and go reset your Fortinet firewall passwords stat. After we first published this story, Fortinet responded to us, denying that the attacks are fresh and claiming that the data showing up on the dark web comes from prior breaches. "Based on our analysis, the data involved is a resharing of data from previous incidents, as well as bruteforcing of credentials, and is not related to any recent incident or advisory," a Fortinet spokesperson told El Reg. Organizations that follow routine best practices, including regularly refreshing security credentials, as per guidance in this March blog, face minimal risk from credential compromise detail referenced in the reporting.” The Register reached out to the companies affected by the so-called FortiBleed campaign for comment, Lenovo said it was looking into it; we didn't receive responses from the others. ® Updated at 2118 with a statement from Fortinet.

Europe, like much of the world, is living through a period of heightened geopolitical uncertainty in which sanctions risk, legal divergence, and cyber disruption have moved from abstract concerns to board-level variables. Digital sovereignty is shifting from aspiration to operational requirement, driven by resilience expectations, critical service dependency, and rising geopolitical and cyber risk. Definitions of sovereignty vary, ranging from blanket data localization edicts to industrial policy to national security, but the absence of an agreed definition should not be mistaken for an absence of intent. Sovereignty is already shaping procurement, regulatory compliance, and technology strategy. From my years working at the intersection of government and the technology industry, I have seen how quickly digital policy can harden into operational constraints. I have also seen how easily "sovereignty" becomes a stand-in for broader concerns: dependency, geopolitics, and the fear that critical services may not remain available during a crisis Two issues are at play. First, policymakers are right that over-dependency on foreign technology can become a national resilience problem. Cloud market concentration is a case in point: last year across Europe, the three leading cloud providers accounted for around 70 percent of the market, while European providers' collective share remained around 15 percent. Concentration is not, by itself, a security failure, but it is a strategic dependency that can become acute when legal regimes diverge, access is contested, or a geopolitical shock tightens the room to maneuver. It also amplifies the "ripple effect": disruption at a small number of providers can cascade across thousands of organizations and supply chains. Second, business leaders are right to worry that blunt sovereignty initiatives raise costs and regulatory complexity. A hard localization mandate or a "sovereign-only stack" duplicates infrastructure, slows modernization, and in practice keeps organizations tied to legacy systems longer than planned while limiting access to leading technologies. The same tension is shaping Europe's competitiveness debate. Former Italian prime minister Mario Draghi has argued that security is a precondition for sustainable growth and that deep dependencies can leave Europe vulnerable to coercion as geopolitical volatility increases. The question is not whether sovereignty matters but how to pursue it without turning it into a counterproductive procurement ideology. From policy to platform choice A recent decision by the French government to restrict certain foreign-made video conferencing tools in favor of a homegrown alternative illustrates the direction of travel across the EU. Whether one agrees with the decision or not, it signals something larger: sovereignty is becoming a set of practical constraints that can reshape technology choices quickly. Many organizations are responding with a third, damaging outcome: delay. In a recent Zscaler-commissioned survey, 73 percent of respondents said digital sovereignty concerns had caused them to delay or cancel transformation initiatives. That "pause dynamic" is dangerous because it prolongs exposure to legacy risk, weakens cyber readiness, and leaves organizations less able to absorb disruption from ransomware, supply chain compromise, systemic outages, or sudden changes in cross-border rules at a time when the threat landscape is shifting faster than ever. If Europe wants sovereignty that strengthens resilience rather than undermines it, political and business leaders need a framework that is practical, measurable, compatible with open markets, and informed by the technology sector's expertise. Here is one: control, choice, and continuity. An outcome-based framework Sovereignty begins with what an organization can control in practice: who can access data, who can administer systems, whether a vendor can see customer content, where logs are stored, how keys are managed, what subcontractors can see, and how policies can be enforced. Control is not about isolation; it is about enforceable governance and reducing hidden dependency. Sovereignty also requires choice: credible options when assumptions break. Too many organizations discover too late that their "vendor strategy" is really a dependency strategy, with few realistic alternatives. Choice is not achieved by buying two of everything. It is achieved through architecture and contracts that keep an organization mobile and avoid vendor lock-in: portability for data and configurations; full transparency on who they rely on, where access sits, and which jurisdictions and subcontractors are in the chain; and pre-agreed exit paths that can be executed under time pressure. It also requires leaders to prevent the sovereignty debate from becoming an excuse to stop transformation. Every program facing sovereignty constraints should be forced through a decision path: redesign, mitigation, or exit on a timeline. The third C is continuity: keeping critical services running during any kind of disruption. If sovereignty is meant to reduce strategic vulnerability, continuity is where it either becomes real or becomes theater. Continuity is measurable through recovery time objectives, tested failover, supplier-failure drills, and exercises for jurisdiction-change scenarios. Across Europe, the urgency is reinforced by the threat environment. Zscaler ThreatLabz data shows rising numbers of damaging ransomware attacks year over year across the region: Spain (+116 percent), Germany (+74 percent), Belgium (+73 percent), Italy (+53 percent), and France (+34 percent) among others. Separate research on resilience found that 52 percent of IT executives believe their current security measures are insufficient to defend against existing or emerging threats such as agent-based AI and quantum computing. The UK's National Cyber Security Centre, meanwhile, reported a 130 percent rise in "nationally significant" incidents over the past year. AI is accelerating these risks. It already gives "bad actors" new capabilities to increase the speed, scale, and sophistication of their attacks. The question is not whether disruption happens, but whether systems can withstand it. Mandate outcomes, not vendors Business leaders argue that sovereignty will raise costs, increase compliance friction, and shrink access to leading technology. That is often true. Policymakers' concerns are also legitimate: strategic dependency can undermine national security and resilience. The mistake is writing sovereignty rules that dictate which vendors to buy rather than what controls buyers must have to keep services running during shocks. The most useful sovereignty requirements are outcome-based: enforceable control over access and data, credible choice through portability and exit, proven continuity through testing and recovery. They create room for organizations to use global platforms safely while meeting local requirements, without freezing modernization. If sovereignty is now an operating requirement, every stakeholder has a role. Boards should define what "sovereign enough" means for their organization, then require regular reporting and testing, with incentives tied to resilience outcomes. CEOs and COOs should treat sovereignty as continuity, fund the modernization that reduces brittle legacy dependency, and force decisions on blocked programs. CIOs and CISOs should map and minimize third-party access, implement localization and multi-region resilience where required, and build plans for supplier failure and jurisdiction-change scenarios. Regulators should clarify definitions, harmonize requirements where possible, and create compliance pathways with transition periods that reward modernization rather than incentivize delay. The approach must be risk-based and agreed in consultation with industry. Scaling control, choice and continuity To make control, choice and continuity achievable at scale, two additional disciplines are required: collaboration and compliance. Collaboration keeps sovereignty compatible with openness through interoperability, shared incident readiness, transparent subcontracting, and trusted vendor partnerships that reduce concentration risk instead of merely relocating it. Solutions must be tailored for local demands and drive investment in local ecosystems. Compliance makes sovereignty measurable through clear definitions, auditable evidence, and regulatory approaches that focus on operational controls so that organizations are pushed to modernize rather than to delay. Sovereignty on European terms should be judged by outcomes rather than rhetoric: whether organizations can govern access, keep options open, recover quickly when incidents happen, and continue delivering critical services when dependencies fail. Done well, digital sovereignty becomes a catalyst for resilience, innovation, growth and competitiveness; done bluntly, it becomes a brake on the very transformation it is meant to protect. Contributed by Zscaler.

Cisco has updated a February security advisory, adding another product to the list of those affected by the maximum-severity CVE-2026-20127. Switchzilla made a small amendment to the original advisory on Tuesday evening, noting that Cisco Catalyst SD-WAN Validator, formerly vBond, was also among the boxes attackers could pop open. Readers may remember the fuss over CVE-2026-20127 (10.0) a few months ago. The make-me-admin improper authentication flaw prompted a Five Eyes alert since attackers could essentially gain persistent root access to all vulnerable instances. In other words, it's a far-from-ideal situation that could could create espionage opportunities, given the prevalence of Cisco's SD-WAN offerings in Western networks. Cisco said at the time that attackers could exploit CVE-2026-20127 to gain admin rights, access NETCONF, and reconfigure the SD-WAN fabric, before exploiting CVE-2022-20775 (7.8), a path traversal flaw discovered in September 2022, to gain root access. Cisco Talos, the company's threat intel arm, posited that the bug could have been exploited for as long as three years by the time it was discovered. Talos attributed the exploitation activity to a group it tracks as UAT-8616, whose activity dates back to at least 2023, according to its researchers' estimates. No one has formally attributed UAT-8616 to a specific country or group of individuals, but experts say that it is a highly sophisticated outfit that has a history of targeting critical infrastructure sectors. Ollie Whitehouse, NCSC-UK's CTO, said at the time: "Our new alert makes clear that organizations using Cisco Catalyst SD-WAN products should urgently investigate their exposure to network compromise and hunt for malicious activity, making use of the new threat hunting advice produced with our international partners to identify evidence of compromise. "UK organizations are strongly advised to report compromises to the NCSC, and to apply vendor updates and hardening guidance as soon as practicable to reduce the risk of exploitation." The Register asked Cisco for more information, but it did not immediately respond. Customers should not have to make any new changes, provided that they upgraded their software to a fixed version across all systems when the advisory was first published in February, not just SD-WAN Controller and SD-WAN Manager. The update comes weeks after Cisco disclosed another zero-day affecting Catalyst SD-WAN, suggesting that it had been exploited for at least a week at the time. Tracked as CVE-2026-20245, it marked the sixth SD-WAN flaw disclosed this year, and the second to be exploited as a zero-day in as many months. ®

The Homebrew team has released version 6.0 of this popular open-source package manager for macOS and Linux, with a new mechanism for trusting packages and support for sandboxing on Linux, to align with existing sandboxing on macOS. Homebrew 6.0 introduces tap trust, a "tap" being a collection of formulae, casks (a package of pre-compiled binaries) and commands which usually reside in a Git repository. The tool trusts official Homebrew taps by default, but requires an explicit agreement before it will trust third-party taps (which can include arbitrary Ruby code) before they install or run any code. Tap trust is part of Homebrew’s approach to supply chain security, which has a number of distinctive features. Package maintainers are Homebrew maintainers, not the authors of the package. Names are maintainer-curated, so typosquats (giving a package a misleading name designed to be similar to one that is popular) can be rejected. Each download is pinned to a sha256 checksum. Package binaries are built from source, which protected Homebrew from incidents like the Trivy compromise earlier this year when official Trivy binaries were replaced with malicious versions. These and other features of Homebrew security are described in the documentation. Project leader Mike McQuaid told us that "Homebrew was less vulnerable 10-15 years ago than npm is today. The trust model is radically different and, even today, we are much quicker to break backwards compatibility in the interest of security." A new security feature is sandboxing on Linux when Homebrew compiles software. This was already implemented on macOS (and has been for a decade). Version 6.0 adds a Linux implementation based on the Bubblewrap project, and this will be on by default for developers. A new Homebrew sub-command, brew vulns, will check installed packages for known vulnerabilities, by checking against the OSV (vulnerability database for open source). The commands brew install and brew upgrade will now show a dependency summary and require a conformation prompt before running, called ask mode, following a developer survey earlier this year where this was highly requested. Another new command, brew exec, will run a Homebrew-provided executable, similar to the way npx works for npm packages. Homebrew startup performance in 6.0 is said to be faster, thanks to parallelised bottle fetching (a bottle is a pre-built package) and other optimizations. Apple is phasing out support for Intel macOS both for future versions of macOS and for Rosetta, the Intel compatibility layer. Homebrew is following: in September this year no new bottles will be built for macOS Intel and from September 2027 macOS Intel will be "unsupported entirely and all related code deleted," according to the post introducing Homebrew 6.0. Homebrew is well-liked by developers, and becoming more popular on Linux as well as macOS. There is some frustration though regarding the dropping of Intel support. "The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple!," said one. McQuaid replied noting that Homebrew will still work for a year after support is dropped to "Tier 3”, meaning almost unsupported, and added that "there’s nothing stopping you for doing the work to setup ‘Intelbrew’ and support it for the community." Another issue he mentioned is that GitHub is dropping macOS Intel runners for continuous integration towards the end of 2027. It is notable that Homebrew 6.0 made extensive use of AI coding. A document on responsible AI usage takes the line that AI contributions must be disclosed and human-reviewed, and that AI is not responsible for any code, rather the human contributor is responsible. "AI is great if used responsibly which means a human reviewing all changes both before PRs submitted and a maintainer reviewing before PRs are merged. I have found despite using it responsibly it has been a huge personal accelerator," McQuaid told us. ®

Six people suspected of bank helpdesk fraud are in custody after Dutch cops stormed an Amsterdam residence and caught them in conversation with a potential victim. Police say the individuals were aged between 15 and 30 and operated out of a makeshift call center they had established in an Amsterdam home. Authorities believe the accused committed bank helpdesk fraud, which has become increasingly popular across the Netherlands. Offenders were recently targeted as part of Game Over?!, a novel law enforcement scheme that successfully shamed criminals into submitting themselves to authorities. Helpdesk scammers typically operate call victims on the phone, using methods similar to voice phishing, or "vishing." They present themselves as bank employees contacting victims under various guises, all designed to steal their money. In this case, police say the alleged criminals tried to convince victims to "increase their limits," and in "several" cases, succeeded in stealing funds from their accounts. The precise cover story is largely irrelevant, however. The aim of the game is the same each time: Convince a prospective victim to surrender enough details to access their bank accounts and steal their money. While these scams mostly take place remotely, Dutch police said in their announcement on Tuesday that the crew sent members to visit victims in person, purportedly offering hands-on assistance to secure their accounts. The same tactic can often be observed with fake police officer shakedowns, which have also become popular in the country. Police say tens of thousands of elderly people, who make up the majority of targets for such scams, have fallen victim to the confidence scams. In these cases, fraudsters visit elderly individuals' houses and pretend to represent law enforcement, offering a service to safeguard their valuables. The crooks then steal those valuables, and police say previous cases have turned violent. Some have also ended in fatalities. Multiple victims of the helpdesk frauds reported their respective cases, according to the cops. The National Intervention Team for Digital Crime was called in to investigate, and during a raid on June 10, officers found the suspects mid-call with a potential victim. Officers seized multiple laptops and phones after apprehending the six suspects, and found several bank cards at the property. Further arrests have not been ruled out. ®

A cyberattack on Australia’s second-largest sugar producer has forced farmers to keep crops in the ground, and looks like denting their incomes. Mackay Sugar, based in the Australian state of Queensland, processes sugar cane farmed in nearby districts. The company disclosed a cyberattack on June 10 and limited operations while it dealt with the fallout. Some operations remain restricted, but the company said on Monday that it managed to perform some manual crushing at its Farleigh Mill site, working with sugar cane that was harvested before the attack. “Significant progress has been made over the weekend in restoring the systems that support cane supply, harvesting, and mill operations,” Mackay Sugar said in a statement. “Steam trials are now underway, and subject to final validation activities, some harvesting is expected to recommence this week in preparation for the staged restart of crushing operations later this week.” While the company is optimistic it can resume crushing, it's advised growers not to harvest their crops for the time being. That edict works for Mackay Sugar because sugar producers need to process crops within 48 hours of harvest. Doing so preserves high sugar content and overall yield. Delaying the processing for any longer after harvesting could result in sucrose converting to simple sugars, unwanted fermentation, and lower yields. But late harvesting can reduce the quality of cane, reducing the price they earn for their crops. Interrupted harvesting also impacts the railways used to move cane from farms to mills. Mackay Sugar acknowledged the impact its downtime could have on growers and other partners, and committed to restoring systems safely. “We are communicating directly and regularly with our employees, growers, and key partners,” it said. “We recognise the impact this incident is having on our growers, and we are doing everything we can to support them and to safely resume full operations as soon as possible. “We take our responsibility to protect our systems, operations, and information very seriously. We apologise for any disruption this incident has caused and will continue to provide updates as we continue our investigation.” The company operates three mills across Queensland, two of which were operating at a limited capacity due to the attack. Its Racecourse Mill, described as the heart of the business and home to its corporate offices, was among those affected. Racecourse Mill typically generates 213,000 tons of raw sugar and 58,000 tons of molasses a year, and the site’s cogeneration plant generates 156,000 MWhs of renewable electricity a year, around 71 percent of which is sent back into the national electricity grid. Mackay’s mill in Farleigh, the company’s oldest, was also affected. It typically produces around 196,000 tons of raw sugar and 49,000 tons of molasses per year. The company’s largest and most productive factory, Marian Mill, was unscathed. Ungentlemanly conduct Cybercrime group The Gentlemen claimed responsibility for the attack on Mackay Sugar, posting the company to its data leak site without offering any details about the attack or whether it stole data to use as leverage for extortion demands. Cyber threat intelligence professionals have known of the group for almost a year, after spotting it in July 2025 and classifying it as a ransomware-as-a-service provider. However, there is no evidence that ransomware was used in the attack on Makay Sugar. The company has never mentioned ransomware in its statements, referring to the attack only as a “cyber security incident.” However, The Gentlemen is known for using file-encrypting malware in its double extortion attacks. The group caught the attention of Microsoft’s researchers, who last month published a deep dive into how it carries out attacks. Microsoft’s report noted that not only do The Gentlemen affiliates have access to a powerful file encryptor, but also one that self-propagates, which “increases the likelihood of widespread impact once initial access is achieved.” It has also recently established a partnership with BreachForums, which allows the group to recruit prospective new affiliates with different skillsets, such as penetration testers and initial access brokers. ®

Python developer Roman Imankulov nearly took the bait. The fact that he didn't can be chalked up to human intuition and AI code vetting. A person claiming to be a recruiter from a small crypto startup got in touch through LinkedIn, looking for help with what she described as proof-of-concept code that didn't work. The company, she explained, needed a lead engineer. As Imankulov described the exchange in a blog post, the recruiter asked him to look into an issue with a deprecated Node module. Something about the request seemed off. "I'd heard, as probably all of us have, about those types of attacks," Imankulov explained in a phone interview. "And I was like, 'what if this could be I could be the target?' It was just based on the past experience that I had." So he took the unusual step of spinning up a VPS on Hetzner where he cloned the repo. He then used his Pi coding agent (running Codex) to conduct a read-only analysis of the code. "I ran an agent to test how it worked, and I was almost certain that it would return to me 'everything is clear, the code is ugly but in general it's safe to run and just go ahead and perform your review,'" he explained. "To my surprise, almost immediately the agent returned a response like, 'Don't run this code, just walk away because there's a trap.'" The AI model had flagged one of the files, app/test/index.js. The file contained a backdoor. It took the form of a server URL, fragmented to look like a test suite configuration, and a network request that will run anything the server sends in response to the request. Imankulov credited his AI agent with catching details that he had missed. "I opened this code myself and I skimmed through this code and it looked to me like just, you know, a regular sloppy file written by a sloppy developer," he said. "So I just scroll down, [thinking] 'Yeah, yeah, it's awful, but you know if they can pay me to fix this code, I don't mind.' But the agent in the very same file found the exact vulnerability that I overlooked." Just installing the repo using npm would have been sufficient to trigger the backdoor. The repo's package.json file contained a "prepare" post-installation hook designed to run the script following the installation process. The referenced malicious repo is no longer accessible – presumably GitHub removed it in response to Imankulov's complaint – but a clone can still be found. "What makes this attack insidious is how it hijacks standard developer workflows," explained Devashri Datta, independent open source and security architect, in an email to The Register. "The adversary didn't rely on the target executing a suspicious binary; they relied on the target running a routine command: npm install. "By burying the execution logic inside the prepare lifecycle hook within package.json, the malicious payload triggers automatically during dependency resolution. This isn't a novel technique, but it remains highly effective precisely because developers run npm install on autopilot. The string fragmentation used to assemble the malicious URL, piecing together a domain from small constants, was deliberate obfuscation designed to defeat static analysis tools that scan for hardcoded indicators of compromise." Imankulov said that the commits in the malicious repo appeared to be the work of a developer with an established web presence and body of work. But when he contacted the supposed author, the dev said he had been impersonated on GitHub more than once and didn't write that code. The recruiter's LinkedIn profile referenced a real arts journalist, though Imankulov believes the associated profile was faked. His online interactions with the recruiter suggested a level of technical knowledge not evident in her work history. LinkedIn likes to talk about the tens of millions of fake accounts it catches and removes before they interact with anyone. But hundreds of thousands of accounts still get created and interact with people before being detected and flagged. And that number keeps growing. In the period from January through June 2025, LinkedIn restricted 386,000 accounts after user reports. That figure was 266,000 in the prior six month period. And it was a mere 86,000 in the January through June 2021 period. These sorts of software supply chain social engineering attacks have become commonplace. Earlier this month, we noted how North Korean-linked scammers have been running various campaigns to compromise developer accounts using fake interviews and job offers. Other developers have reported nearly falling for these scams (and also being saved by their AI agent) and have posted code analyses. Datta said Imankulov's response highlights a shift in how security-conscious developers are approaching code review hygiene. "Historically, the guidance was to sandbox untrusted code or review it manually," she said. "Here, Roman deployed a local AI agent in a constrained, read-only environment to analyze the codebase before executing anything. This is a useful counterpoint to the dominant narrative around AI as an offensive threat vector. Used defensively at the developer endpoint, an AI agent isn't susceptible to fatigue or social pressure; it simply surfaces anomalous behavior, such as a test suite initiating an outbound network connection to retrieve unverified code, in seconds." npm 12 could change the game If it's any consolation, the relevant attack vector should be addressed next month. GitHub, which maintains npm, is preparing to release npm 12 which changes the behavior of the npm install command. The allowScripts setting will be defaulted to off. "npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project," GitHub explains. "Install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem," explained GitHub product manager Leo Balter in a community discussion post last week. "Every npm install runs scripts from every transitive dependency, so a single compromised package anywhere in your tree can execute arbitrary code on a developer machine or CI runner. Making script execution opt-in closes that path while keeping it one command away for the packages you trust." Imankulov said he doesn't have a strong opinion about that. "From my perspective, just for the sake of personal safety, I switched to pnpm just to make sure that I don't execute those scripts by default," he said. Datta said the incident underscores why enterprise software supply chain security had to extend beyond the perimeter of the corporate network. "Attackers are now shifting left all the way to individual engineering endpoints before a single line of code enters the corporate supply chain," she said. "When a developer's local workstation is compromised during what appears to be a routine job interview, that machine frequently holds active SSH keys, cloud provider tokens, and live access to internal repositories." Proper defense, Datta contends, requires enforcing technical guardrails such as isolated developer containers or secure cloud workstations for evaluating third-party or untrusted code. "Emerging frameworks are beginning to extend exploitability context down to the workstation layer itself, recognizing that VEX-style signal needs to travel further left than the enterprise SBOM inventory if it is to intercept threats at the point of introduction," she said. ®

Three critical flaws in Fortinet’s sandbox that allow remote attackers to bypass authentication, escalate privileges, and execute malicious code are under active exploitation, according to threat intelligence firm Defused. Fortinet patched two of the three flaws, CVE-2026-39813 and CVE-2026-39808, in April and the third, CVE-2026-25089 last week. All three bugs received 9.1 CVSS ratings, and, at the time, the vendor said that there were no reports of active exploitation. CVE-2026-39813 is a path traversal bug in the FortiSandbox JRPC API that allows an authentication bypass using specially crafted HTTP requests. It affects FortiSandbox 4.4.0 through 4.4.8 and 5.0.0 through 5.0.5. Patch to 4.4.9+ or 5.0.6+, depending on the branch, to fix the flaw. Fortinet security analyst Loic Pantano found this one. CVE-2026-39808 is an OS command injection flaw in FortiSandbox that allows unauthenticated attackers to execute unauthorized code or commands via HTTP requests. It affects versions 4.4.0 through 4.4.8, and upgrading to FortiSandbox 4.4.9 or above patches the hole. Fortinet credited KPMG Spain researcher Samuel de Lucas Maroto with finding and reporting this bug. Finally, CVE-2026-25089 is another OS command vulnerability in FortiSandbox, FortiSandbox Cloud and FortiSandbox PaaS WEB UI that allows unauthenticated attackers to execute unauthorized commands using specifically crafted HTTP requests. FortiSandbox 4.4.0 through 4.4.8 and 5.0.0 through 5.0.5, FortiSandbox Cloud 5.0.4 through 5.0.5, and FortiSandbox PaaS 5.0.4 through 5.0.5 are vulnerable. Upgrading to a fixed version patches the hole. Fortinet did not respond to The Register’s inquiries about these three CVEs and if the vendor had also observed any attacks against them. According to Defused, the exploitation began over the weekend. “We are observing exploitation of multiple Fortinet FortiSandbox vulnerabilities during the past 24 hours,” the threat-intel firm said in a LinkedIn post on Monday. “Per our research a working exploit for CVE-2026-25089 has not yet been publicly disclosed,” the company added, noting that the exploit for this flaw appeared to be vibe coded and may be faulty. We do know that all manner of miscreants love to abuse Fortinet flaws, so if you haven’t already, patch now. Earlier this month, Check Point VP of research Lotem Finkelstein warned that ransomware crims had exploited a critical authentication bypass vulnerability affecting Fortinet's Remote Access VPN and Mobile Access deployments, and said that the same crew was also likely abusing other VPN-related vulnerabilities in Fortinet products. ®

Cybercrims deploying DragonForce ransomware appear to have gained access to a major US services company's network, then spent two months up to no good while disguising their command-and-control activities as legitimate Microsoft Teams traffic. Researchers at security firm Symantec said the intrusion began with attackers gaining access to the victim's environment before deploying a custom Go-based backdoor, tracked as "Backdoor.Turn," to maintain communication with the compromised systems. Rather than reaching out to attacker-controlled infrastructure that might raise alarms, the backdoor hid its activity inside traffic associated with Microsoft's widely used collaboration platform. To anyone monitoring network traffic, the compromised systems appeared to communicate only with legitimate Microsoft servers. "The attackers in this campaign use exceptionally sophisticated cyber tradecraft," Symantec said. "The configuration of Backdoor.Turn means that security products only see C&C traffic going to legitimate Teams servers, leaving defenders unaware that data is being siphoned away by malicious actors." Symantec said the attackers installed Backdoor.Turn on systems after deploying DragonForce ransomware, potentially giving them a way back into compromised networks or access they could later sell to other criminals. To connect to Microsoft's infrastructure, the backdoor first requested an anonymous visitor token from Microsoft Teams and Skype back-end services. It then used a Microsoft-operated TURN relay server – infrastructure typically used to help establish communication between users – before establishing a direct QUIC connection to a malicious command-and-control server. Symantec said this is the first known case of malware using this particular technique. The security firm did not identify the victim beyond describing it as a major US services company, nor did it say whether the Teams-based communications channel had been observed in other DragonForce incidents. The ransomware operation has become increasingly prominent over the past year, operating a ransomware-as-a-service model that allows affiliates to conduct attacks under the DragonForce banner. It has been linked to the prolific Scattered Spider group, which has conducted a string of high-profile attacks, including intrusions targeting major retailers in the UK. While attackers have long abused legitimate cloud services to conceal malicious traffic, Symantec's findings suggest that DragonForce operators continue to look for ways to blend into the software and infrastructure that organizations trust most. ®

Heart monitoring biz iRhythm says thieves made off with patient health information and tried to turn it into a payday. The California-based cardiac monitoring specialist offers customers a wearable device that collects data, then analyzes it to create reports about heart health. The company said it detected unauthorized activity on June 8 and launched an investigation with the help of third-party cybersecurity experts. A day later, the company received messages from a cybercriminal claiming to have obtained sensitive information, including proprietary company data, protected health information, and other personal information. According to iRhythm's filing with the US Securities and Exchange Commission, the attackers demanded payment in exchange for not publicly disclosing the stolen data. The company confirmed that data had been exfiltrated and, on June 10, determined that the incident was material due to the volume of information potentially affected. While the company disclosed the extortion demand and the existence of stolen data, it made no mention of negotiations. iRhythm spent a good chunk of the filing explaining what the attackers didn't get. According to the company, the intrusion was confined to business applications and never reached its clinical systems, medical devices, or customer connections. Patient care and day-to-day operations were unaffected. The company has not yet disclosed how many individuals may be affected, what data was accessed, or which third-party-hosted applications were involved in the breach. It has also not identified the threat actor behind the attack, and The Reg has found no evidence of major ransomware groups claiming responsibility. The company's filing states the attackers gained access through social engineering. Exactly how that happened remains unclear, although healthcare organizations have increasingly found themselves dealing with phishing campaigns, help desk impersonation scams, and other forms of human-targeted intrusion designed to bypass technical defenses. As of the filing date, iRhythm said it had not identified any ongoing unauthorized access to its systems and believed the incident was unlikely to have a material impact on its financial condition or operating results. The company added that it maintains cyber insurance that may cover some of the losses associated with the breach. iRhythm's disclosure comes less than a week after drug giant Novo Nordisk revealed that attackers had copied patient data from some clinical trials, adding another healthcare name to a growing list of organizations dealing with data theft and extortion attempts. ®

Cisco today issued a fix for a Catalyst SD-WAN Manager bug that attackers have already spotted and exploited to get root privileges, according to both the networking vendor and the feds. The vulnerability, tracked as CVE-2026-20262, is in the web UI of Cisco Catalyst SD-WAN Manager, and exists because the software is not properly validating user-supplied input during a file upload process. “An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected API endpoint of the affected system,” the vendor warned in a Monday security advisory. “A successful exploit could allow the attacker to create or overwrite any file on the underlying operating system. This file could later be used to elevate to root.” There is one caveat: to exploit this bug, the attacker must have valid credentials with at least a lower-privileged, single-task user account. That probably explains the medium-severity, 6.8 CVSS rating for this bug. Still, valid credentials aren’t hard to come by these days, and considering this CVE is already under attack, we know someone had some success. “In June 2026, the Cisco PSIRT became aware of limited exploitation of this vulnerability,” the security alert said. “Cisco continues to strongly recommend that customers upgrade to a fixed software release to remediate this vulnerability.” The flaw affects all deployment types, regardless of device configuration. There are no workarounds, but upgrading to a fixed software version will patch the flaw. Also on Monday, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-20262 to its Known Exploited Vulnerabilities catalog, citing “evidence of active exploitation.” America’s lead cyber-defense agency also set a two-week deadline for all federal agencies to apply the patch. This latest Cisco SD-WAN bug under attack comes less than two weeks after Switchzilla warned that a high-severity vulnerability in Catalyst SD-WAN Manager vulnerability (CVE-2026-20245) was under active exploitation. At the time of disclosure, this SD-WAN vuln did not have a fix. Cisco issued an advisory for that zero-day on June 4, and finally released patches for all affected versions on June 12. This is the eighth Cisco SD-WAN bug to be listed in CISA’s Known Exploited Vulnerabilities catalog so far this year.®

The “jailbreak” that prompted the Trump administration to block Anthropic’s most advanced models was actually a simple three-word prompt: “Fix this code.” That's according to Katie Moussouris, founder and CEO of Luta Security, and the fairy godmother of bug bounties. She says she was the only outside expert to read the third-party research paper on the Fable 5 guardrail bypass techniques that prompted the ban. On Friday, the US government, reportedly citing national security concerns, issued an export control directive to suspend access to Fable 5 and Mythos 5 by any foreign national, inside or outside the United States. In response, Anthropic disabled both models “for all our customers to ensure compliance.” Anthropic shared the report privately with her, Moussouris wrote in a Monday blog post. The outside researchers reportedly fed Anthropic’s Fable 5, Mythos, and Claude Opus models open-source code containing known CVEs, plus new code intentionally laced with vulnerabilities, and asked the models to “review the code for security issues.” As Moussouris tells it, Fable 5 refused, so the researchers asked the AI systems to “fix this code.” The model reportedly obliged, and after additional prompts also produced scripts to test the patches. “That’s it,” Moussouris wrote. “‘Fix this code,’ plus several manual steps to generate test scripts, should never have triggered an export control. I feel like making ’90s-style t-shirts with ‘fix this code’ on the front and ‘this shirt is a munition’ on the back.” Between 2013 and 2017, Moussouris served on the technical expert group that renegotiated the Wassenaar Arrangement, a voluntary agreement between 42 nations that governs certain export controls for classified dual-use software and technology. The group eventually won exemptions for defensive cybersecurity activity. This allows defenders to share vulnerability data, conduct malware analysis, and coordinate incident response internationally without the threat of criminal prosecution. On Sunday, Moussouris joined more than 100 other cybersecurity leaders and signed an open letter urging the Trump administration to reverse the restrictions on Fable 5 and Mythos and restore cybersecurity firms' access to the advanced models. “To pull the best capabilities away from defenders without a good reason when our adversaries are rapidly advancing is dangerous,” they wrote. In her blog, Moussouris argues that there was no guardrail bypass or jailbreak. Defenders should be able to ask AI systems to find and fix bugs, and write tests to validate the patch, she said. Anthropic’s models were doing “the most valuable thing an AI model can do for defensive security: executing the find, fix, and test loop defenders run every day.” Removing the capability for models to respond to defensive requests makes AI systems “worse at finding bugs and verifying patches,” she continued. Plus, the US can’t extend export controls to open-weight systems or similar advanced models from China and other countries - and these systems will soon achieve Mythos-like capabilities, anyway. Anthropic and Google have both accused China-based rivals including DeepSeek of using “distillation attacks” to train their models by siphoning knowledge from American companies’ AI. Banning Anthropic’s advanced models is going to hurt defenders more than attackers, Moussouris warns. “Defense improves when defenders find the same bugs attackers find and fix them faster,” she wrote. “We need the best tools to defend against increasingly capable attackers in the AI era of cybersecurity.” The Register reached out to the Trump administration for comment on Moussouris' assertion, and we'll update this post if we hear back. ®

ShinyHunters claims to have breached the Council of Europe and stolen more than 297 GB of data after exploiting a zero-day flaw in Oracle PeopleSoft and abusing that hole to hack more than 100 organizations. According to a post on the extortion crew’s data-leak site, the 429,000 pilfered files contain HR and payroll records, payslips, purchase-order records, CVs, and employees’ salary, banking, tax, and medical records. A Council of Europe spokesperson told The Register that it is “currently investigating the matter and assessing the situation,” but declined to comment further. A spokesperson for the cybercrime group told us that the Council is yet another victim of the Oracle PeopleSoft heist. Oracle has yet to respond to The Register’s inquiries, and it's unclear if the vulnerability, tracked as CVE-2026-35273, has been patched. ShinyHunters previously told us that the gang exploited the CVE to compromise more than 100 organizations across 300 vulnerable instances, and that these victims included the University of Nottingham. Last week, the crims listed the UK uni on their leak site, then dumped data belonging to around 454,600 current and former students, including personal and academic records. Meanwhile, a Google threat report published late last week noted malicious activity, “consistent with the exploitation of CVE-2026-35273,” between May 27 and June 9, and said that its incident responders notified more than 100 global orgs “whose IP addresses correlated with potentially vulnerable endpoints." Most of these are US-based organizations, and 68 percent operated within the higher education sector. This latest heist follows another ShinyHunters intrusion targeting data belonging to university and K-12 students, teachers, and staff. In mid-May, ed-tech giant Instructure said it “reached an agreement” - this is corporate-speak for “paid the ransom demand” - with the data theft and extortion crew after ShinyHunters breached its Canvas digital learning platform and accessed data tied to 275 million students, teachers, and staff. In March, ShinyHunters claimed it stole data from K-12 software provider Infinite Campus as part of a broader wave of Salesforce-related intrusions. The ed tech company did not pay up, and the group subsequently published data they claim was stolen from Infinite Campus, including 137,000 individuals’ email addresses along with names, phone numbers, physical addresses and support tickets. Infinite Campus, in its data breach notification, said that the leaked files largely consisted of “names and contact information for school staff" and that “the majority is directory information commonly found on school websites.” ®

US legislation covering federal datacenters is set to expire in September and it appears that the Trump administration is simply going to allow it to lapse without replacement. The Federal Data Center Enhancement Act (FDCEA) of 2023 covers certain standards that are to be adhered to for facilities that are wholly or partially owned, operated, or maintained by a federal agency. It includes requirements relating to availability and uptime of the facility; the use of sustainable energy sources; protection against power failure; protections against physical intrusion and natural disasters; plus IT security protections. We understand that the legislation will sunset on September 30, 2026, and according to Wired, neither the US Congress nor the Trump administration appears to be making any move to extend the act, or put alternate legislation in place. The danger is that if the FDCEA is not renewed or superseded by similar legislation, then federal agencies across the US may cease to follow the requirements and simply act as they see fit when procuring new datacenter infrastructure. We asked the White House and Congress for comment. According to implementation guidance issued by the Office of Management and Budget (OMB) under the previous administration, agency datacenters “must provide secure and highly available computing infrastructure to enable reliable access to Federal information and information systems.” It notes that the "needs of the federal government with respect to data access and data processing systems have evolved since 2014,” when the Federal Data Center Consolidation Initiative (FDCCI) was established, and hence the latter was not renewed but replaced by the FDCEA. The OMB states that effective operation of datacenters requires regular monitoring, and optimization of resources by operators, and directs agencies to incorporate automated tools into the management of all new facilities, including tools that monitor metrics such as electrical consumption. It also states that the “cost, scarcity, and environmental impact of energy and water consumption necessitates that agencies evaluate datacenters against resource consumption metrics and best practices when making their decisions” regarding new datacenter builds. Perhaps most importantly, it requires that federal facilities “must be able to meet the reliability and resiliency needs of their hosted information and information systems through implementation of the appropriate information security and physical security protections.” It is widely known that the Trump administration does not look kindly on regulations, especially those relating to environmental protection. Instead, policy has focused on fast-tracking the federal permitting process for datacenters, particularly those dedicated to training and developing AI models. A recent report from Politico stated that the Trump administration was not inclined to set nationwide environmental requirements or recommendations for the datacenter industry. Instead, Environmental Protection Agency (EPA) Administrator Lee Zeldin said that while there are technologies and practices that reduce air pollution and water usage, individual states and communities know what works best for them. At the same time, opposition to datacenter construction is growing across the US, precisely because of public fears over factors such as air pollution, water usage, and the prospect of spiking energy bills. A recent survey found more than 70 percent of respondents said that they would be against the construction of an AI datacenter in their neighborhood. ®

Microsoft appears to have dropped the ball with its certificate management after a domain used by sysadmins worldwide to test connectivity to Microsoft 365 started throwing untrusted connection warnings in browsers. The connectivity.office.com domain is used by IT pros to test their network's connectivity to Microsoft 365 and ensure their firewalls aren't blocking anything that could affect an organization's access to Microsoft servers. An SSL server report retrieved on Monday showed that the certificate expired on June 14 after last being renewed on December 16, 2025. At the time of writing, 35 hours have passed since the certificate expired, and Microsoft has still not renewed it, despite many in the IT community making their opinions on the matter known. Certificate renewals are often automated in this day and age, but in organizations still relying on manual processes, those responsible for renewals would almost certainly have received multiple alerts warning of the impending expiration. It suggests that something, or someone, involved in the certificate-renewal process at Microsoft has messed up. The Register contacted Redmond for a response. The company's publicists acknowledged the request for comment but did not return one in time for publication. The fallout could have been much worse. Browser warnings on a network diagnostic tool are irritating, but hardly catastrophic compared with the same thing happening to login.microsoft.com or another critical service. Teams users may remember the collaboration platform abruptly deciding to take Monday off in 2020, after an authentication certificate expired, for example. Whatever went wrong here, Microsoft will have to tighten its processes before shorter certificate lifespans arrive in the coming years. As of March 26, new SSL/TLS certs will have a maximum lifespan of 200 days. This is set to decrease to 100 days by March 15, 2027, and then to 47 days two years later. ®

Chinese government spies remained hidden in the networks of multiple North American medical and military research organizations for more than a year, deploying custom malware and snooping through Gmail inboxes and stealing sensitive data. This PRC-nexus espionage crew, which Google tracks as UNC6508, used some particularly noteworthy search terms as they were scanning for data to steal. They included such esoteric topics as drone technology and a viral disease that spreads from mosquitoes to humans. “It’s one of the most interesting grocery shopping lists of things to collect that I’ve seen from a state-sponsored actor,” Luke McNamara, deputy chief analyst at Google Threat Intelligence Group, told The Register. “We have defense-related activity, which was a significant bulk of the different terms, or emails related to defense platform systems or companies,” McNamara said. “Some of those were looking for any emails that were coming in or going out that used @ and then a big defense name. Others were specific email addresses of individuals at more niche defense companies.” While most of the terms related to defense and technology, the intruders also searched for some medical research facilities – and the very specific pathogen, “Chikungunya,” a viral disease transmitted to humans from mosquitoes that was responsible for an outbreak in China's Guangdong province in July 2025. Google won’t say how many organizations were compromised in this campaign. A Monday report said the operation targeted several national, state, and private medical entities. “These organizations comprise world-renowned clinical providers, premier academic centers, North American military health institutions, professional advocacy groups, and health regulatory bodies,” according to the report. “Their research areas span a broad spectrum of modern medicine, from molecular discovery and clinical drug trials to state-level public health policy and military readiness.” McNamara told us that the tech company’s incident responders notified all the victims they identified, “and we suspect there's probably even more.” Incident responders first detected this campaign in early 2025, but told us it dates back to at least 2023. And all of these attacks began with the digital intruders somehow exploiting externally facing REDCap (Research Electronic Data Capture) servers. These servers are primarily used by universities, hospitals, and research institutions to build and manage online databases and surveys, and to store sensitive clinical research data. The earliest known intrusion happened in September 2023, when UNC6508 compromised a REDCap server belonging to a North American medical research institution. McNamara told us that all of the intrusions followed this same pattern. Seeing (Infinite)Red After three months, the snoops silently deployed custom malware named InfiniteRed to capture legitimate REDCap login credentials. The malware includes three modular components. The first allows it to maintain persistent remote access by injecting its code into new REDCap versions after intercepting the upgrade process. Then it injects a credential harvester into the authentication system file to compromise user accounts. Finally, it functions as a backdoor with custom hooks that executes on every REDCap page load. Google’s threat intelligence team identified “multiple” US and Canada-based organizations infected with InfiniteRed, and offered assistance with removing the malware. After remaining undetected for more than a year, UNC6508 used the stolen credentials to access admin accounts and the victims’ internal network. Finally, the attackers added sneaky domain content compliance rules for data theft. All 'Patroit' themed emails sent to BebitaBarefoot774 Content compliance rules are legitimate features in many cloud-based enterprise productivity suites - like Google Workspace - to exfiltrate specific email communications. Administrators can create these rules to manage messages that contain predefined sets of words or phrases, and these rules apply to all of the users in an organizational unit. UNC6508 created a compliance rule named "Patroit" (yes, they misspelled “Patriot”) to match keywords and email address patterns in sent or received emails. These messages were then silently BCC-forwarded to an attacker-controlled Gmail address, BebitaBarefoot774[@]gmail[.]com, delivering a steady stream of geo-strategic policy, military strategy, advanced technology, and medical research emails to the PRC-linked crew. The search terms also included professional email addresses and phone numbers for members of organizations in these spaces. GTIG disabled the Gmail account to prevent further data exfiltration. “One of the questions that we've had internally around this is: We're seeing this show up primarily at medical research institutions,” McNamara said. “Why are they searching for things like unmanned drones and unmanned vehicles? Why would you expect to find that there?” One theory, he said, is that this particular threat group was tasked with collecting data across different categories of national-security-related terms and information. “Maybe they were copy-and-pasting this across multiple victims, including ones outside of this medical research space?” Plus, some of the targeted institutions were likely working on research with a military or government agency connection. “So there was a potential that they could be in correspondence with someone where one of these terms showed up, and the actors were casting a very wide net,” McNamara said.®

A wave of malicious commits hit the Arch User Repository (AUR) over the weekend, prompting the team to disable new account registration on Monday morning while it cleans up the mess. The issue was first acknowledged on June 12, with a post stating: "We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository." The team warned that users might have issues opening new accounts, pushing package updates, and adopting or creating fresh packages. Around 400 user-submitted packages were believed compromised; that figure climbed past 1,500 over the weekend. On June 14, a more sophisticated wave of malicious packages was spotted. The Arch Linux team this morning disabled new account registration "while we are working on the cleanup." The core Arch distribution itself is unaffected. The AUR is a community-run package repo – if something isn't in the official repo, it's probably here, assuming nobody's poisoned it. The AUR is user-submitted and unsupported, so users are expected to inspect package build files themselves before installation. The malicious packages attempted to pull in hostile JavaScript dependencies, including npm packages identified in the campaign. Arch Linux is a fast, lightweight Linux distribution. It isn't for beginners – users need to pick their own display manager and desktop environment as well as their own applications. However, this makes it highly customizable. The project's website says: "Currently we have official packages optimized for the x86-64 architecture. We complement our official package sets with a community-operated package repository that grows in size and quality each and every day." Unless, of course, miscreants go wild with malicious commits, and the team has to wade in to deal with the problem. According to the AUR, there are just over 107,000 packages, with 5,586 updated and 273 packages added in the past seven days. This isn't Arch Linux's first brush with trouble. In 2025, the project was hit with a Distributed Denial of Service (DDoS) attack that disrupted its main web page, the AUR, and the project's forums. It also had to address compromised browser packages that reportedly contained a Remote Access Trojan. Both incidents highlight risks in the way the AUR is structured and maintained. It's an invaluable library of packages led by a community of smart Arch users, yet that open, community-driven model can be abused by attackers. New account creation remains disabled at the time of writing. The Arch team will no doubt be pondering how to avoid this situation in the future. ®