Reading view

Mythos discovers 'Squidbleed,' a memory leak that's gone undetected since Clinton era

Sometimes it takes a while to detect a vuln. A 29-year-old, Heartbleed-style vulnerability in Squid, a popular open-source caching proxy server, silently leaked users' plaintext HTTP requests and potentially revealed sensitive data, including credentials and session tokens, for decades - until AI (and a few humans) saved the day. A security researcher and Mythos Preview found the flaw and reported it to project maintainers, who fixed the code earlier this month. Squid is widely used by large corporations, schools, and internet service providers to cache, filter, and monitor network traffic, and Calif.io researcher Lam Jun Rong said he came across the open source proxy while attempting to connect to the internet on a flight. “As you might expect, the version of Squid deployed on that plane was released nearly 10 years ago and is affected by the vulnerability I'm about to share with you,” Rong wrote in a blog post about the bug, which he dubbed Squidbleed and investigated with help from Anthropic's Claude Mythos Preview. Rong reported the bug, tracked as CVE-2026-47729, to Squid’s maintainers back in April, and it’s fixed in Squid v7.6, released June 8. The Reg readers may remember Calif from their earlier HTTP/2 Bomb research, uncovered by OpenAI’s Codex agent, and the AI bug-finding firm also collaborated with OpenAI on its Patch the Planet initiative, announced on Monday. According to Rong, Squidbleed leaks internal memory from every version of Squid in its default configuration with two conditions. First, Squid has to be able to read and inspect the network traffic, so it must be handling cleartext HTTP (not HTTPS) or be deployed in TLS-terminating setups. Additionally, the proxy must be allowed to reach an attacker-controlled FTP (File Transfer Protocol) server via TCP port 21. FTP is an outdated protocol for moving files between machines, and Squid supports it - which is where the problem lies. The bug exists in Squid's FTP directory listing parser, and it was injected into the open source code as a commit (bb97dd37a) created in 1997 to support old NetWare servers. NetWare is a discontinued network operating system that was popular in the 1980s and 1990s, providing file and print services across local area networks before Windows and Linux servers became dominant. NetWare FTP servers also added extra whitespace between the modification timestamp and the filename, compared to most other FTP servers that just used a single spFace. The 1997 commit fixed this NetWare issue by instructing the code to skip the extra whitespace using this loop: while (strchr(w_space, *copyFrom)) ++copyFrom;. As Mythos Preview discovered, if an attacker's FTP server doesn't provide a filename after the modification timestamp, copyFrom points to the terminating NUL character at the end of the string. “strchr treats that terminating NUL as part of the string it searches, so it returns a pointer instead of NULL, and the loop never stops,” Rong explains. “It walks off the end of the buffer, and xstrdup copies whatever follows back to the attacker as a filename.” This results in a heap overread and can leak HTTP requests that often contain passwords or API keys, and Rong demonstrated this exploit in a proof of concept. “The patch is simple: check for the null terminator before calling strchr,” Rong wrote. If you use Squid, make sure to download the June release to fix this flaw. Also, as Rong suggests, you should disable FTP unless there’s a “specific, unusual need for it.” Chromium-based browsers stopped supporting FTP years ago and for good reason. This means “most organizations running Squid are getting close to zero legitimate FTP traffic,” the security sleuth noted. “Turning it off removes this entire attack surface for free.”®

  •  

Five Eyes spooks warn AI means infosec incidents can become ‘major operational and financial crises’

The leaders of intelligence agencies from the Five Eyes nations – Australia, Canada, New Zealand, the USA and the UK – have together issued strongly worded advice calling for leaders to nail cybersecurity basics or fall victim to ruinous AI-powered attacks. “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years,” the advice warns, and calls for organizations to take rapid action to ensure their defenses remain potent. “While AI will help us improve cyber defence over time, it also accelerates the speed, scale, and sophistication of cyber threats,” the advice adds. “Frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.” After all that scary stuff, the spook bosses offer some antidote: “Cyber resilience is integral to advancing business continuity, market confidence, and long-term value.” And how might one achieve that resilience? The Five Eyes have four suggestions: Understand and assess risk, readiness and accountability Prioritize foundational cyber security practices and controls Empower cyber leaders with authority and resources Stay actively engaged as threats and guidance evolve “Cyber risk can no longer be treated as a purely technical issue,” the advice points out. “This is a core business risk and leadership responsibility,” because breaches are inevitable and “Breaches will occur. Preparedness helps you contain them quickly and prevent escalation into major operational and financial crises.” The intelligence chiefs therefore want organizations to test their cyber resilience rigs. “It is not enough to have controls,” they write. “Leaders must be confident those controls will perform during a real incident. This requires reassessing long-standing trade-offs and using AI deliberately to strengthen defence – not just improve efficiency.” That last sentence is a rare moment of optimism in the advice and precedes a section in which the intelligence bosses observe “Organizations that integrate AI tools into their security operations can detect vulnerabilities earlier, improve software quality, monitor unusual behaviour, and respond faster to incidents – reducing both the cost and impact of incidents.” Readers of The Register might find this advice a little quaint given that infosec vendors have for years blathered on about the need for boards and bosses to take cyber seriously. It’s also been a couple of years since it became apparent that generative and agentic AI can fuel new and unusually potent cyber-attacks. Interest in that idea spiked in the eleven weeks since Anthropic revealed the existence of its powerful flaw-finding Mythos model and hid it behind a regwall lest criminals use it to swiftly slice holes in important software. The Five Eyes bosses address their advice to “leaders” – presumably bosses of substantial organizations – who may not have watched the Mythos mess unfurl while they worried about a global energy crisis kicking holes in their supply chains. The good news is that the spy bosses don’t think leaders need to learn a lot to cope with the advent of AI, as their advice suggests five practical actions they rate as “not new,” but “now urgent to reduce not only technical risk, but also operational, financial and reputational exposure.” For the record, those actions are: 1. Reduce your attack surface: Limit unnecessary system access and external connectivity. Challenge whether systems need to be exposed at all and isolate those that do not. 2. Accelerate patching processes: AI is shortening the time between vulnerability discovery and exploitation. Delays in patching increase risk, especially for operational systems with long update cycles. Prioritize security updates accordingly to manage risks. 3. Address legacy systems: Unsupported systems are easy targets. They are not just technical debt, they are strategic liabilities. 4. Review and strengthen identity and access controls: Limit who can access critical systems. Enforce strong authentication and regularly review permissions. 5. Prepare for incidents before they happen: Test response plans, train and prepare teams, and assume breaches will occur. Focus on fast containment and recovery. Take us, and this, to your leaders, dear readers. ®

  •  

Sniff out stale AI override advice with this open source CLI

The JavaScript development ecosystem may be a security nightmare, but it's also ripe for improvement. One such tool is the CVE Lite CLI, a free open source dependency scanner that helps reduce the risk of software supply chain attacks. It runs locally and provides actionable vulnerability fixes, if any are available. The tool, endorsed by OWASP, has recently been updated to include override auditing, which has the potential to avert transitive dependency vulnerabilities such as the March 2022 node-ipc package incident. The Shai-hulud software supply chain attacks that have been vexing security professionals for the past few months underscore how common it has become for threat actors to target the developer ecosystem, including CI/CD, package registries, and developer tooling. Software developers can reduce their risk by making sure the dependencies in their apps are up to date and free of known vulnerabilities, but that's more difficult than it should be. It's generally apparent when a particular library or module relies on a vulnerable dependency. But there isn't necessarily an available fix or clear remediation path. Modern JavaScript applications, like many other programming languages, allow developers to incorporate pre-existing solutions to particular problems in the form of packages – modular code that can be imported to implement particular functionality. These packages commonly depend on other packages, which is why they're known as dependencies. And these dependencies in turn may also depend on still more packages, referred to as transitive or indirect dependencies. A common security scenario goes something like this: A developer creates an app using some application framework. The app includes a dependency on "Package A", which itself relies on "Package B" – the transitive or indirect dependency in this situation. If the maintainers of "Package B" have deployed a patch addressing a reported CVE, but the maintainers of "Package A" haven't gotten around to incorporating that change into their code, apps incorporating "Package A" may be vulnerable to attack. Among other possible responses, affected developers may choose to create an override to replace the outdated, vulnerable version of "Package B," a configuration entry that can be removed once "Package A" gets repaired. But Sonu Kapoor, creator of CVE Lite CLI, explained to The Register that overrides represent a legitimate security tool but have limitations. "When a transitive dependency has a CVE and the upstream maintainer hasn't shipped a fix yet, you pin it via npm overrides, pnpm overrides, or Yarn resolutions," Kapoor explained in an email. "Once the vulnerability is addressed and CI passes, you move on. The problem is what happens after that." Kapoor recently added an override auditing tool to the CLI. When he scanned four popular JavaScript open source projects, he found that three of the four had broken overrides. "Cal.com has 90 override entries and 11 that are silently doing nothing," he said. "Jest has an override for its own package name pointing at nothing in the resolved tree. NoCoDB has entries using wildcard patterns that never matched any path in the graph. Next.js was the only clean one with zero findings, which tells me the tool is finding a real pattern, not noise." This can be dangerous, he said, when a project migrates between package managers (e.g. npm to pnpm) that looks for overrides in a different location. "npm reads from overrides, pnpm from pnpm.overrides, Yarn from resolutions," he explained. "When a team migrates package managers and forgets to move their security pins, the package manager silently ignores them. No error, no warning, the vulnerable package ships unconstrained." Kapoor said that AI coding assistants commonly advise developers to add override entries when asked to fix a transitive dependency vulnerability. "That advice is correct at the moment," he said. "None of them ever tell the developer to come back and verify the entry still works." CVE Lite CLI, Kapoor said, does not recommend overrides as the way to properly address a vulnerable dependency. "Overrides look like a security fix in package.json, but routinely outlive their purpose – they can point at packages no longer in the dependency tree, apply to the wrong package manager entirely, or shift to an unintended version on every install," he said. "The override hygiene feature exists precisely because of this failure mode: teams add an override to address a CVE, move on, and years later, the override does nothing while they still believe they're protected." ®

  •  

OpenAI: Yoo-hoo, look over here, we do that security stuff too!

OpenAI announced a flurry of cybersecurity-related AI news on Monday, releasing an improved version of GPT‑5.5‑Cyber, its most advanced vulnerability-finding model, along with an expanded partner program for cybersecurity vendors, an update to its Codex Security scanner⁠, and an initiative to “Patch the Planet” – or at least 30 high-profile open source projects. The announcements come as Anthropic’s Mythos mess keeps getting more complicated, with national security concerns clouding defenders’ abilities to use that AI company’s most advanced models to find and fix vulnerabilities – or perhaps it’s just politics as usual. They also coincide with a general feeling of FUD around AI cyberattacks and the impending vulnpocalype. The Reg’s vultures will keep out collective eyes on all of this. First off: GPT‑5.5‑Cyber. After releasing a preview version of the model to a select group of “trusted defenders,” OpenAI on Monday released an update that it says makes the model even better at finding – and also fixing – bugs in code. “It is our strongest model yet for finding and helping patch software vulnerabilities, while retaining GPT‑5.5’s general-purpose intelligence and ability to work across long, complex tasks,” the AI shop said. “The model can sustain deeper analysis across large codebases: identifying security-relevant components, tracing whether vulnerable code is reachable, validating likely issues in controlled environments, developing and testing patches, and preparing evidence for human review.” OpenAI said it evaluated the update and 5.5 preview using a few different benchmarks: CyberGym, which test how well AI systems can reproduce known vulnerabilities; ExploitGym, which determines how well models can turn known vulnerabilities into working exploits that achieve unauthorized code execution; and SEC-bench Pro, which measures AI systems’ long-horizon vulnerability discovery and proof-of-concept generation capabilities. The updated version 5.5 outperformed the preview model in all three tests, we’re told. On CyberGym, the updated GPT‑5.5‑Cyber reached 85.6 percent success, compared with 81.8 percent for GPT‑5.5. On ExploitGym, it outperformed the earlier model 39.5 percent versus 25.95 percent. And on SEC-bench Pro, GPT‑5.5‑Cyber hit 69.8 percent, compared with 63.1 percent for GPT‑5.5. Plus, OpenAI assures everyone that it’s had “ongoing dialogue” with the US government, including about its latest model plus upcoming releases, so hopefully that insulates the company against any surprise export controls. OpenAI also expanded its partner program. The OpenAI Daybreak Cyber Partner Program currently has about 30 security-vendor and service-provider partners, and only these select firms get to use the updated GPT‑5.5‑Cyber model. OpenAI says it plans to add more organizations to the elite group “in the coming months.” FOSS flaw-finding Also on Monday, OpenAI announced Patch the Planet, an initiative to help open source project maintainers find and patch vulnerabilities. This initiative, co-founded with Trail of Bits and launched in collaboration with HackerOne and AI-powered bug hunting outfit Calif, provides participating open source projects with ChatGPT Pro, conditional access to its Codex Security scanner, and API credits for core development, maintainer automation, and release workflows. “Maintainers define their priorities, preferences, and established disclosure processes,” according to OpenAI. “Patch the Planet security researchers then manage the work end to end - validating and deduplicating both vulnerabilities and patches before they reach maintainers, significantly reducing the burden on maintainers and speeding up remediation.” Trail of Bits reports that in the first week alone, Patch the Planet uncovered hundreds of bugs, and generated 64 pull requests with 51 issues filed across 19 projects. The 19 projects Patch the Planet assists includes cURL, NATS, pyca, Sigstore, aiohttp, the Go project, freenginx, Python and python.org, urllib3, PyPI, SimpleX, Valkey, and RustCrypto. More than 30 projects have joined so far, and project maintainers can apply to join the initiative. Some of the initiative’s highlights from the week include using GPT-5.5-Cyber to build a full-scale fuzzing lab in under a day – an effort we’re told would have take human fuzzing experts two or three weeks to do manually. Patch the Planet also used Codex to build a CVE variant analysis pipeline. This also took less than a day to complete. Speaking of Codex: OpenAI on Monday released a Codex Security plugin⁠ that the company says “enables out-of-the-box defensive security workflows,” allowing developers to integrate Codex into their workflows and CI/CD pipelines. The scanner, which was released as a research preview in March, has so far scanned more than 30 million commits across more than 30,000 codebases, according to OpenAI. Of these, human reviewers have manually marked about 70,000 findings as fixed, and AIs have auto-determined that more than 500,000 findings are fixed. In addition to performing automated scans and reviewing code changes, the new plugin can “triage and validate existing findings from scanners, advisories, bug-bounty reports, or ticketing systems, then automate patch generation at scale to quickly close a backlog of vulnerabilities,” OpenAI said. After it completes a scan, the AI coding agent can export reports to existing vulnerability management systems or integrate into tools with SARIF files and CodeQL queries. “The plugin makes these capabilities much more accessible to support automated pipelines with Codex CLI or integrate into developer workflows in the Codex app,” according to OpenAI. ®

  •  

Canadian utility fesses up to data breach, but key details remain off-grid

A Canadian power utility says customer data may have walked out the door during a security incident, but isn't yet saying whether the intruders got anywhere near the systems responsible for keeping the lights on. London Hydro, which distributes electricity to more than 160,000 customers in and around London, Ontario, said on Saturday that it is investigating a data security incident that "may have impacted a portion of personal information on some accounts" and has started notifying affected customers. The utility said the potentially exposed information includes names, addresses, email addresses, phone numbers, account and billing numbers, service addresses, pricing plans, contract start dates, and meter information. The good news, according to London Hydro, is that the incident did not involve banking information, payment card details, dates of birth, government-issued identification numbers, or other sensitive financial data. The less good news is that the company has disclosed little else. Its statement focuses on customer information and contains no indication that operational technology or grid systems were affected. London Hydro has yet to explain what systems were compromised, how the incident occurred, whether data was stolen or merely accessed, or how many customers may have been caught up in the incident. The haul may not include bank details, but it contains enough account information to make a fake utility bill, payment demand, or customer service call look considerably more believable. London Hydro is warning customers to watch for suspicious communications, unexpected bills, unfamiliar account activity, or requests to change payment arrangements. The company also reminded customers that it does not ask for banking details by email, phone, or SMS. The Register asked London Hydro when it discovered the intrusion, whether information was exfiltrated, how many customers were affected, whether ransomware or extortion was involved, whether any third-party systems were implicated, and whether operational or grid-related systems were touched during the incident. At the time of writing, London Hydro had not responded. The company has drawn a fairly clear boundary around the customer information that may have been exposed. Where the attackers went and what else they may have touched remains unclear. ®

  •  

Brazil probes emergency warning system after nationwide rogue alert

The Brazilian National Secretariat for Civil Protection and Defense (SEDEC) and Federal Police (PF) are investigating a suspected hack of the country's emergency alert system after an unauthorized "extreme" alert pinged devices across the country. Defesa Civil Nacional confirmed that its dispatch platform, often used to inform the public about severe weather events, was taken offline in the early hours of Saturday, June 20, after Brazilians reported the alert, which read: "Alerta extremo - Defesa Civil:misantropi4." "Misantropia" is Portuguese for misanthropy, hatred of humankind. The message reached an unknown number of devices, with reports coming from São Paulo, Rio de Janeiro, Paraná, and the Federal District. Civil defense authorities in all four areas confirmed the alerts were bogus and likely stemmed from an attack on the system overseen by Brazil's National Telecommunications Agency, Anatel. "Anatel clarifies that the alert messages received by mobile phone users during the early hours of this Saturday were not issued by the competent authorities responsible for the population alert system," it said in a statement. "There is currently no reason for concern on the part of the population as a result of the messages received." The agency went on to say that it remained confident in the alert broadcast system's capability to help save lives during periods of disaster. National Civil Defense officials have not confirmed whether anyone responsible for the suspected breach has been identified or apprehended, although they are not believed to be part of government staff. "The Defesa Civil Alerta dispatch platform was taken offline at 01:30 this Saturday (6/20), after suffering a breach and issuing an alert to various regions of the country, remotely ordered by someone outside the National System of Protection and Civil Defense," the department stated. "The message issued was of the Extreme Alert type and contained the word 'misanthropy' – which means hatred of humanity. It is likely a hacker attack." A Defesa Civil Nacional chief said in a press conference that a new dispatch system was already under development that would place greater emphasis on security and preventing unauthorized intrusions. The agency also committed to relaunching the affected system as soon as possible after ensuring it is properly secured. ®

  •  

Health board apologizes for phishing staff with with bogus vacation day

A Canadian healthcare organization has apologized after its IT team carried out a phishing test falsely offering staff an additional paid day off work. Newfoundland and Labrador Health Services said the phishing test was sent to employees and physicians, acknowledging the theme was inappropriate. "We acknowledge the approach taken in this particular exercise was not appropriate, and we sincerely apologize to employees, physicians, and union representatives," said Ron Johnson, interim CEO at NL Health Services. "We value the feedback and are reviewing how future awareness exercises are developed and communicated. It is important they reflect employee and physician perspectives, as well as our organizational values, to foster a respectful and supportive workplace culture." The test came during an already fractious period for healthcare staff, who had recently worked long hours to launch the new software system CorCare across the organization. NL Health Services referenced CorCare in the test email, thanking staff for their hard work on the launch. The email contained a button to click to redeem an additional paid vacation day, but clicking the button resulted in a fail mark. The Registered Nurses Union (RNU) in Newfoundland and Labrador said the test was especially insensitive since nurses and other healthcare professionals were already struggling to secure paid time off. Burnout and staffing shortages are rife in the healthcare sector – two factors referenced by RNU president Yvette Coffey in her response to the news. "Yes, we have heard concerns from members about this, and frankly, I understand why they are upset," she said. "Nurses and other healthcare professionals have worked through enormous pressure over the last number of years, including ongoing staffing shortages, burnout, organizational restructuring, and the challenges connected to the rollout of CorCare. To use the promise of an additional paid day off as the hook for a phishing exercise was in very poor taste." Coffey added: "Cybersecurity education is important, but it needs to be done with judgment and respect. There are many ways to test phishing awareness without exploiting the very real stress, fatigue, and frustration healthcare workers are experiencing." Johnson told reporters at a press conference that the test "missed a mark," and promised to investigate how it was allowed to be sent. "What happened here, obviously, is that all the lenses that were required to review the scenario weren't placed on it," he said. "It's not reflective of how we value our employees." With cybersecurity awareness being incredibly important in critical infrastructure organizations, some IT experts would argue that these kinds of tests are valuable. Cyberattacks on hospitals and healthcare facilities can lead to devastating consequences, including vital procedures being canceled, service downtime, and in the rarest cases, death. However, as others have previously pointed out, there isn't much evidence linking fire-drill-style tests to improvements in organizational security. ®

  •  

Gizmodo readers hit with ClickFix malware prompts after account compromise

Veteran tech website Gizmodo confirmed a compromise on Saturday after readers reported ClickFix malware prompts appearing on article pages. Users posted screenshots of fake CAPTCHA windows appearing on Gizmodo's site. The attack aims to fool users into running malicious code via their terminals. According to Proofpoint threat researcher Tommy M, the attack was seemingly launched by an affiliate of ErrTraffic, a ClickFix-as-a-service program that allows attackers to deliver whichever malware they choose. He said the ClickFix prompt was tailored to each user's OS. The Windows version attempted to install the NetSupport RAT malware, which abuses the legitimate NetSupport Manager tool to gain access to affected systems. Darktrace says NetSupport RAT can also be used to exfiltrate files from affected systems and to load additional payloads, such as other malware strains and ransomware. The macOS version had a payload configured but appeared to be broken, requiring a password to open a ZIP archive. Gizmodo said the attacks were being displayed only "briefly," and the timeline of user reports, which span just a few hours, suggests that was indeed the case. "We identified and resolved a security incident on our site earlier today," the outlet said. "A compromised account was exploited to inject a malicious script, briefly exposing users to scam content. The site was taken offline immediately, the script removed, and the account secured. "We're back up. If you notice anything unusual, reach out." The Register confirmed that the website is no longer serving ClickFix prompts as of Monday. ®

  •  

Why Amazon hates 'human-in-the-loop' AI governance

Humans tend to be “a little bit precious about humans,” according to Eric Brandwine, distinguished engineer and VP at Amazon Security. We like to think we are all very good at our jobs, and we have high opinions of ourselves, he explained during a phone interview with The Register. “But when you actually get down to it, humans are not terribly consistent,” Brandwine said. Humans, like AI agents and systems, are non-deterministic. Neither can be guaranteed to produce the same output given the same input twice. Both will make mistakes and even make stuff up. However, we’ve got millennia of experience dealing with humans and less than a decade with more modern LLMs and the AI systems built on top of them. “We know how humans fail,” Brandwine said. “We're comfortable with it. So human-in-the-loop isn’t necessarily the gold standard.” For years, vendors have told companies that the solution for dealing with any automated system was to put a human in the loop. That battle cry became much louder with the advent of modern AI systems and reached a fever pitch when enterprises started deploying agents into their IT environments. More recently, however, big tech is changing the way it talks about agentic governance and rethinking the whole human-in-the-loop concept. Normalization of deviance In 2017, Brandwine gave a talk on the normalization of deviance at AWS’ annual re:Invent conference. It’s a gradual process that happens when people in an organization take shortcuts, or don’t follow the established procedures or standards, and sometimes it occurs over years. As long as nothing catastrophic happens, this deviant behavior becomes the norm. “It’s a thing all humans fall prey to, and one of the most heartbreaking stories I read in this area was about emergency departments and emergency rooms,” Brandwine said during a phone interview with The Register. “You’ve got all these machines, and they’re all beeping. Your first day on the job, you jump every single time one of the alarms beeps – but the patient is fine. It's a spurious alarm. You go back to your station, you sit down, and over time, after enough of these false alarms, enough of these repeated beeps with no actual consequence, your discipline slips, and you stop responding. And eventually some tragic outcome occurs.” This, he admits, is a very high-stakes example. And yet it’s a documented occurrence among healthcare workers, firefighters, and even Army pilots. “Literally, someone’s life is on the line, and people still struggle to maintain discipline,” Brandwine said. “That’s the human condition.” Here’s how this all applies to agentic AI governance and security. Humans build LLMs and AI systems, and having a “human-in-the-loop” ensures that a person reviews the AI’s output and approves (or not) any actions before the AI performs them. “If you put a human inside of this tight loop, and ask them to make approval decisions for agentic tools repeatedly, time after time, they'll do a good job,” Brandwine said. “And then they'll do an okay job. And pretty quickly they'll be doing a poor job.” This is why at Amazon, “we’re not huge fans of human-in-the-loop,” he added. “It's something that you should use judiciously, where you absolutely need it. But it’s not something that you can do at high velocity. You will not get the results that you want to get.” Big tech pulls the human-in-the-loop Amazon isn’t the first or only tech giant to start talking differently about the role humans should play in agentic governance. "It is very clear that we have moved from a human-led defense strategy, to a human-in-the-loop defense strategy, to an AI-led defense strategy that's overseen by humans," Google Cloud chief operating officer Francis deSouza told reporters during a press conference ahead of Google's annual Cloud Next shindig in April. "Our model for the future is an agentic fleet that does a lot of the routine cyber security work at a machine pace and then is overseen by humans." Microsoft CEO Satya Nadella, in an X missive earlier this week, argued for “loop learning,” instead of having a human check an AI’s output at every step. “Companies need to turn their workflows, domain knowledge, and accumulated judgment into AI systems that improve with each use,” Nadella wrote. “Private evals should capture whether a model is actually improving against outcomes that matter to the business (not just external benchmarks!). Private reinforcement learning environments should let models grow stronger on real traces from inside the organization.” Also this week, IBM execs called for human accountability – not humans in the loop – at all stages of AI development, deployment, and governance. Amazon’s alternative to human-in-the-loop is "accountability end to end," according to Brandwine. This means human identity and ownership track through the entire workflow, even when humans aren't directly approving every step. “If I sit down at my keyboard and I type a command that takes a service down, I caused an outage,” Brandwine explained. “If I run a script that takes a service down, it's still me that caused the outage. If my agent writes a script that they then run, and it causes an outage, that's still my responsibility.” (Secret) keys to the kingdom This also highlights the importance of managing and securing agentic identities – the accounts, tokens, and credentials assigned to AI agents so they can access corporate apps and data. At Amazon, all of the agents have independent identities assigned to them, we’re told. “So, as we track agentic activity across our systems, it does not show up in the logs as: ‘Eric did this.’ It shows up as: ‘this agent did this on behalf of Eric,’” Brandwine said, adding that this isn’t to “make people afraid to use this technology.” “It’s to make people pause and think: is this the right way to use this technology? Is this how I should be deploying this?” We still have the humans involved, we still have the humans making decisions, but we're trying to play to the strengths of the humans rather than placing them in this unfair, repeated decision making, human-in-the-loop position.” Brandwine told us that Amazon has run into a couple of hurdles when it comes to deploying agents across its businesses, and one of the biggest is what he calls “goal-seeking behavior.” This is when a person asks an agent to do a specific task - for example, upgrade a database – and the agent becomes laser-focused on just one action to achieve this goal, ie, deleting the database. This is separate from prompt injection because there’s no malicious input. “It’s just the agent getting stuck on the wrong action,” Brandwine said. Simply telling the agent, “you don’t have permission to do this,” is likely going to cause the agent to look for a different path to do the same thing (delete the database). Telling the agent why it doesn’t have permission to do something tends to produce a better outcome, according to Brandwine. This means telling the agent it’s not allowed to do that, and the reason why is because it would cause a production impact. And also include “don’t cause a production impact” as part of the prompt. “Giving it that extra feedback has gotten us dramatically better results,” Brandwine said. Of course, this is not a fail-proof method. “You still need to be careful with agents,” Brandwine told us. “We have millennia of experience with humans. Agentic AI is a very, very new field, we don't have an intuition for this, and one of the fundamental differences between agents and humans is that humans fear consequences,” such as losing a job or even going to jail. Agents don’t have these fears. This is where setting permissions on what the agent can and can’t do or access comes in. Much like everything else with AI, it’s nuanced, and it depends on the employee's role in the company, and the company’s tolerance for risk. “The person that wants to run the agent wants to give the agent many permissions because that makes the agent more powerful,” Brandwine said. "It could do more things for them, it can recoup more of their time, it can deliver more.” The security lead, on the other hand, wants to limit an agent’s permissions, and this causes yet more tension between the security and development teams. There is no one right solution or policy answer to solve this, according to Brandwine. Instead, it involves dynamic policies that set permissions based on the agent’s specific task. There are some overarching, static guardrails – such as an agent must never perform destructive actions or delete entire servers – and then there are policies underneath that establish the maximum set of privileges that the agent can have. “Then we’ll have a further scoped-down policy for this action, and there's various techniques for automatically generating policies based on prompt and the end-user's intent,” Brandwine said. Even for Amazon, it’s not always easy. “It's all driven by risk,” he said. “This is a space that's changing quickly, and so we're trying to balance the risk of using untried, untested software against the risk of falling behind and not being able to deliver for our customers. As with all such things, it's complicated.” ®

  •  

Researchers drop checkm8-style BootROM exploit for A12 and A13 iPhones

A newly disclosed BootROM exploit affecting Apple's A12 and A13 chips gives researchers a way to break the secure boot chain on millions of iPhones and other Apple devices. The exploit, dubbed “usbliter8” by security researchers at Paradigm Shift, targets a flaw in the SecureROM code found on the iPhone XS, XR, 11, and 11 Pro models, plus other devices powered by Apple's A12 and A13 processors. Because the vulnerability resides in immutable BootROM code burned into silicon during manufacturing, it cannot be patched. The researchers traced the issue to the Synopsys DesignWare USB controller used by Apple. A flaw in how the hardware handles certain USB setup packets allows attackers to corrupt memory during Device Firmware Update (DFU) mode, and ultimately gain control of SecureROM itself. That might sound like an unremarkable minor moment in boot process, but SecureROM sits at the very bottom of Apple's chain of trust. If an attacker can compromise it, they can interfere with everything that comes afterward. For ordinary iPhone owners, there is little reason to panic. Exploitation requires physical access to a device and the ability to place it into DFU mode, which means this isn’t the sort of bug criminals are likely to weaponize in phishing campaigns or drive-by attacks. For security researchers, however, BootROM vulnerabilities are the gift that keeps on giving. Unlike software flaws that disappear after the next patch Tuesday, these bugs remain exploitable for the lifetime of the hardware. Paradigm’s proof-of-concept demonstrates the ability to run unsigned code during the boot process, load custom iBoot images without signature checks, and modify DFU behavior. The exploit also marks compromised devices with the traditional "PWND" - a string familiar to anyone who spent time around the jailbreaking community over the last decade. Not every generation of iPhone has the flaw. According to the researchers, Apple's A11 chips dodge the issue thanks to a different USB implementation, while A14 and later hardware appears to have fixed the conditions that make the exploit possible in the first place. “While newer generations have addressed the underlying issue, affected A12 and A13 devices will carry it for the remainder of their lifetime,” said Paradigm researchers. “For those who have followed the history of iPhone exploitation and jailbreaking, this research is a reminder that the BootROM still occasionally has a surprise left to give. The team said it disclosed the findings to Apple before publication and coordinated the release of the research with the company. Apple did not respond to The Register’s request for comment. The exploit doesn’t directly compromise Apple's Secure Enclave Processor, which remains responsible for protecting passcodes, encryption keys, and other sensitive data. Still, gaining control of SecureROM is about as close as researchers can get to the keys to the kingdom without crossing that final boundary. There's no fix, but a remedy is simple, if somewhat expensive: buy a new iPhone. ®

  •  

Everything's bigger and better in Texas – even data breaches

The Texas Parks and Wildlife Department (TPWD) says 3 million Texans had their data stolen following a breach at one of its suppliers. People with state-issued hunting and fishing licenses are among those affected after attackers breached the vendor that handles license sales and copied customer data. Details of victims' driving license and passport numbers may be present in the leaked data. Basic personal information, such as email addresses, phone numbers, and residential addresses also leaked. Social Security numbers (SSNs), financial data, or information relating to minors were not involved, according to the department's disclosure. According to a filing with the Office of the Attorney General, the attack on the unnamed vendor affected 3,087,721 Texans. The filing appears to contradict the department's disclosure, noting that individuals' names and SSNs were also involved. Affected Texans were offered the usual one year of free credit monitoring services provided by Kroll, as long as they enroll by September 14. A Kroll webpage dedicated to the incident reveals that an investigation has not determined when the breach took place. The department notified Texas Cyber Command on May 13, however. "We recognize the seriousness of this issue and have identified and implemented additional security options to better protect customer information," said TPWD. "Many of our staff are hunters and anglers and were affected by this incident. We are committed to continuing to work with the license system vendor to implement increased safeguards to prevent future incidents." TPWD said it is working with the affected vendor to introduce additional preventive measures, including enhanced monitoring and access controls. The org went on to say that new license sales currently scheduled for August will go ahead as planned, although the website used to purchase licenses was unreachable at the time of writing. ®

  •  

Britain's privacy watchdog quits after 'poor judgment' admission

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 told us: "As a Crown appointee and accountable to Parliament, Mr Edwards submitted his resignation to the Department for Science, Innovation and Technology." 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. ®

  •  

Rights groups brand Home Office's AI age guesser for asylum-seekers as biased and inaccurate

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

  •  

Google told researcher 'Nice catch!' Then denied bug bounty for flaw it still hasn't fixed

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

  •  

Major US carrier stored credit card info in the clear, employee learned on first day

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

  •  

Digital sovereignty needs an operating model

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 adds another SD-WAN box to max-severity bug advisory

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

  •  

Three critical Fortinet sandbox bugs splattered by unknown attackers

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

  •  

Feds freaked over Fable 5 after simple 'fix this code' prompt, not jailbreak, says researcher

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

  •  

Microsoft site throwing warnings after someone forgot to renew cert

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

  •  
❌