The Register

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