The Register

John Edwards has resigned as Britain's information commissioner, saying his position had become "untenable" following an investigation into conduct he admits caused offense. Edwards announced his departure in a statement posted to LinkedIn on Friday, bringing an abrupt end to a saga that has engulfed the UK's data protection watchdog for months. Edwards said he had informed technology minister Ian Murray of his resignation from the roles of Information Commissioner and chair of the Information Commission, effective immediately. "Since February of this year I have been the subject of an investigation," Edwards wrote. "While I have not agreed with how that investigation has been conducted, I accept that my position has become untenable." He added that there had been occasions where he exercised "poor judgement" and made attempts at humor that were "inappropriate and caused offence." "It is for this reason that I have decided that it is appropriate that I resign from my position," he wrote. "I do not wish to be a distraction to the ICO's important work." The resignation comes just over a week after the Information Commissioner's Office announced that an independent workplace probe had concluded there was "a case to answer," prompting the regulator to strip Edwards of his remaining responsibilities while the process continued. At the time, neither the ICO nor the Department for Science, Innovation and Technology (DSIT) disclosed the nature of the allegations. The probe first surfaced publicly in April, when the ICO confirmed Edwards had voluntarily stepped back from his duties on February 26 while an independent investigation into "HR matters" was carried out. Edwards' resignation statement sheds slightly more light on what prompted the investigation. He accepts that some of his conduct caused offense, but offers no details about the incidents in question or the investigation's findings. The former New Zealand privacy commissioner spent much of his statement reflecting on the challenges facing regulators, including AI governance, online safety, and international cooperation. He also praised ICO staff and said he remained committed to the principles that had guided his professional life. Notably, Edwards has disabled comments on the resignation post, and his profile now carries LinkedIn's green "Open to Work" banner, a reminder that even Britain's former privacy regulator eventually can end up marketing himself on LinkedIn. Questions remain for both the ICO and the Department for Science, Innovation and Technology (DSIT). Neither has yet explained the conduct that triggered the investigation, whether the investigation's findings will be published, or how the process reached the point where the UK's top privacy regulator concluded he could no longer remain in office. A spokesperson at DSIT told The Register: "John Edwards has resigned from the post of Information Commissioner and Chair of the Information Commission with immediate effect. This follows an independent investigation that took place regarding allegations made against him. “The government expects the highest standards of conduct from all senior leaders in public life. Mr Edwards has acknowledged that his conduct fell below these standards." The ICO did not immediately respond to a request for comment. For now, deputy commissioner and chief executive Paul Arnold continues to carry out the commissioner's statutory responsibilities while the government works out what comes next. ®

More than 60 rights groups have told the UK government to scrap plans to use AI-powered facial age estimation on asylum-seeking children, warning the technology is biased, inaccurate, and potentially unlawful. In an open letter sent to border security and asylum minister Alex Norris, 62 organizations, including Amnesty International, Human Rights Watch, Liberty, the Electronic Frontier Foundation, Foxglove, and the Open Rights Group, called on the Home Office to halt deployment of facial age estimation (FAE) technology, currently slated for rollout from 2027. The intervention comes after the Home Office unveiled plans to use AI-powered facial age estimation to help immigration officers decide whether someone claiming to be a child is likely to be over or under 18. Ministers insist the technology will support, rather than replace, human decision-making. But the coalition behind the letter is unconvinced. "There are substantial and well-founded concerns about the bias of FAE," the groups wrote, arguing that the technology has "baked-in failures and discrimination," particularly affecting women and people of color. The groups also highlighted an uncomfortable detail in the Home Office's own guidance: the technology's performance varies by ethnicity and skin tone. That makes it difficult to see why officials believe it will be reliable for assessing asylum-seeking children, who are predominantly people of color, they argued. The organizations also took aim at what may be the technology's biggest practical problem: age estimation systems are least precise around the exact boundary the Home Office wants them to assess. "The Home Office admits FAE systems are imprecise at the crucial 16-to-18-year-old boundary," the letter notes, citing government figures showing even the best-performing systems have an error margin of roughly 2.5 years in that range. The groups argue that the technology may fare even worse on asylum-seeking children. Their letter says trauma, violence, malnutrition, dehydration, sleep deprivation, and long journeys can leave children looking older than they are, potentially skewing the results. "As such... we can see no basis upon which the Home Office has concluded this technology will increase the accuracy of its decision making," the groups wrote. The coalition also raised questions about the data used to develop and test the systems and demanded details about the images and datasets used for training, arguing it is unclear how consent could lawfully have been obtained if asylum-seeking children were included. The Register asked the Home Office to comment. The Home Office has so far released only limited details about its testing program. The groups noted that officials have yet to publish detailed results, methodologies, or impact assessments that would allow independent scrutiny of the technology's performance. The letter also noted that no Equality Impact Assessment or Data Protection Impact Assessment has been made public. The groups have given the department 21 days to respond to a series of questions covering testing methods, training data, safeguards, appeal mechanisms, and how facial age estimates would ultimately influence asylum decisions. The row also exposes a broader disagreement over age assessments. While the Home Office has emphasized cases involving adults claiming to be children, campaigners argue the greater risk is that vulnerable children end up being treated as adults. Until then, the government's AI age guesser remains a technology it says works, but has yet to fully show its workings. ®

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