News

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.