The Register

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