Beacon, a CRM provider for charities and nonprofits, says an AWS access key "potentially exposed in public JavaScript build artifacts" is the leading suspect in its July breach. The revelation came in the company's first update on the attack in more than a week. If the access key was exposed in public build artifacts, it raises questions about why Beacon's development pipeline and code review controls failed to catch it. Beacon used stronger wording about the potential data loss, confirming that a copy of the database was made and assessing that it was probably downloaded in readable form. "This update confirms… that a copy of the database which holds all Beacon customer data, including attachment files, was made and likely downloaded in a readable format by the threat actor," wrote CTO David Simpson. "Analysis of the AWS Cost & Usage reports across May-July 2026 has been conducted. This data showed a significant increase in data transfer on 27-28 July 2026. This timing correlates with the malicious activity, which supports an assessment that substantial downloads occurred." Beacon's logs cannot reveal which specific records left its systems, although the company has confirmed that a copy of the database containing all customer data and attachments was made. In an FAQ accompanying the update, Beacon advises customers to assess the likely exposure by reviewing what they stored in their CRM instance. Many of the charities that have confirmed they are affected have said the data mainly pertains to personal information and details about donations. Simpson said Beacon's AWS data was encrypted at rest, but the compromised access key may have allowed the attacker to retrieve it in readable form. The malicious activity began in the early hours of July 27, according to Beacon's root cause analysis, matching its initial estimate of the incident timeline. The company has more than 1,500 customers, although it has not established how many had data taken. The malicious activity lasted one hour and 27 minutes, Beacon said, and the attacker established no persistence mechanisms in AWS. Simpson warned customers that "there are things we may never be able to find out about this incident," and that other details won't be shared to protect Beacon's security position. He promised to provide customers with a summary when the investigation concludes in a few weeks, but warned that "the level of detail contained in this next and final update may not be any more than" Beacon published on Wednesday. "I recognise this is frustrating, but unfortunately it is the reality of complex incidents like this. With this in mind, we would recommend making your own risk assessments now regarding onward notification to impacted data subjects using your knowledge of the data you process and store with Beacon." Since Beacon disclosed the attack on August 4, the number of high-profile charities confirming they are affected has grown every day. Early confirmations came from the likes of Molly Rose Foundation, Macmillan Cancer Support Jersey, and English National Ballet. Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, the British Deaf Association, and Lincoln Cathedral are among those that have since joined the list. The Charity Commission said that "a number of charities have submitted serious incident reports," and that the volume of these reports is causing delays to responses. "We appreciate your patience and understanding as we prioritise instances of the greatest risk," it said. ®

PWNED Welcome, once again, to PWNED, the weekly column where we highlight others’ security failures. Hopefully, there’s a lesson in all this, but it could just be “stop shooting yourself in the foot.” 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. Our story today comes courtesy of Siim Kostabi, co-founder of Pageloot, a company that provides QR codes businesses can use for marketing. Kostabi’s tale of tech terror reminds us that credentials, even for a staging server, have a lot of value in the wrong hands. He explains that his company brought in a contractor to help with some API integrations on the back end. That developer had the credentials for the staging environment and wanted to be able to view them across different devices they were using for the job. So what was the developer’s solution to the very common problem of keeping track of usernames and passwords? They could have chosen a password manager. They could have written the passwords down in a paper notebook and kept it hidden from prying eyes. They could have gotten a password tattoo. They could even have emailed the passwords to themselves and it would have been smarter than what they did. Instead, the outside developer decided to store their password in a Google Doc. And they set that Google Doc to be viewable by anyone on the internet who had the link. And then, one day, an employee at the company found the Google Doc with the staging credentials in it because Google Search had indexed it and offered it as a search suggestion. “A developer on our team was debugging something unrelated and typed our domain into Google Search,” Kostabi recalls. “The autocomplete surfaced one of our staging hostnames followed by what looked like a credential string. We checked, and there was a publicly accessible Docs URL.” Yikes! Just imagine that not only are your company’s credentials available to anyone online, but they are indexed in Google Search for the world to find! Once they discovered the problem, Kostabi’s company immediately cut access for that contractor and rotated all of its exposed credentials. They also set a new rule: no storing passwords on Google Docs, Slack, Notion, or other collaboration tools. In a separate incident, Kostabi heard from a Pageloot customer, a mid-size retailer, whose QR codes were suddenly directing users to a competitor’s site. After investigating, he found that a disgruntled ex-employee’s credentials had not been revoked and that the former employee had used that access to redirect all of the retailer’s URLs, costing it customers. The takeaway from both of these problems is that you need to carefully control access. Former employees should immediately lose access to everything and current contractors should be reasonably intelligent people you can trust. “Both situations were completely avoidable with basic hygiene,” Kostabi said. “Proper offboarding, access reviews, and not treating shared docs like private vaults.” ®

Researchers from Germany’s Helmholtz Center for Information Security have found processors made by China’s Loongson have leaky caches that attackers could use to seek specific data. Loongson has developed its own LoongArch instruction set architecture (ISA) that blends approaches used by MIPS and RISC-V. On a site called LoongLeakAttack.com, the researchers explain that they found the leaky cache using a fuzzer, then noticed that the LoongArch ISA manual mentions an instruction that leaves 32 bits of a memory register in an “uncertain” state. “Our analysis reveals that under certain circumstances, the ‘uncertain’ data originates from the L1 data cache,” the four researchers wrote. “Since this cache is not isolated between applications, LoongLeak can leak data from other applications and the operating system. Even worse, an attacker can prime the CPU’s internal state to target the leakage to a specific cache set.” In a paper [PDF] explaining their research, authors Lorenz Hetterich, Tristan Hornetz, Fabian Thomas, and Michael Schwarz share case studies that “include recovering full-disk AES keys from the kernel, partial root password hashes from user-space, and bypassing traditional software defenses such as ASLR and stack canaries, all within seconds.” In case that’s not scaring you enough, they also point out “LoongLeak can be exploited from unprivileged user space, containers, or virtual machines.” The flaw even means “LoongLeak can cross the virtual machine boundary and leak host data from inside a VM.” “As the leakage is architectural, it requires neither high-resolution timers nor traditional sidechannel amplification, and it grants the attacker precise control over cache set and line offset,” they add. And the cherry on top is that software mitigations aren’t possible. Users with chips that possess the flaw either need to replace them or make sure they don’t allow any private data to enter or remain in the L1 cache. Making that happen can require turning off one thread per core, effectively disabling hyperthreading. The news isn’t all bad, because Loongson fixed the flaw in an update to its model 3A6000 processor, and the mitigation of evicting cache data slows performance by just 1.4 percent in the worst case. The blast radius of this flaw is also likely to be limited, because Loongson chips are hardly used outside China. The company offers chips for PCs, servers, and appliances such as printers. China’s government promotes use of Loongson chips as part of its plan to reduce dependence on imported tech. Lenovo makes laptops that use Loongson chips but only sells them in China. The Register has discussed the company’s chips with other major PC-makers, who told us they would adopt Loongson product if users want them, or if doing so becomes necessary to participate in the Chinese hardware market. But we’ve not seen a non-Chinese company adopt the processors. China’s government, however, may be nervous about this research as it has instructed public sector buyers to buy local products. Perhaps some government agencies are running vulnerable devices? If that’s the case, Beijing has its work cut out spotting any attacks, because the researchers could find “no specific tools or methods to detect if LoongLeak is being exploited.” ®

Suspected Chinese cyber operatives used publicly available AI tools to compromise Taiwanese government systems before expanding the attack to its nuclear safety agency, supply-chain vendors, and at least seven energy companies in what security researchers called a "near-autonomous attack." Over the first four days of July, AI agents compromised 85 government user accounts and extracted more than 2,500 personnel records, according to Dream, an Israeli cybersecurity firm. Researchers uncovered evidence of the attack in a 160 MB online archive containing 1,395 files documenting the operation. Dream, in research published on Wednesday, detailed the intrusions and said that the suspected Chinese hackers hit “government entities in Asia” - but declined to say which government had been attacked. A person familiar with the attack confirmed to The Register that Taiwan was the target. The Financial Times first reported on Dream’s research and identified Taiwan. While the security firm doesn’t attribute the agentic attack to the Chinese government or a specific hacking group, the operational documentation “points to a Chinese-language operator,” the researchers said. According to Dream, the attack framework, built on open source Hermes and OpenClaw AI agents, deployed up to eight sub-agents, each assigned to its own targets and attack techniques, across 12 “attack waves” between July 1 and July 4. First, the agents mapped the entire government ecosystem, extracting embedded URLs, API endpoints, OAuth client IDs, and Keycloak configuration objects from a single government portal. This portal allowed the agents to identify 21 connected government systems and every supported authentication flow. “On one target alone, it discovered 36+ API endpoints spanning account management, user data retrieval, file upload, and administrative functions - many completely unauthenticated,” the Dream threat researchers wrote. “Critically, it found that one of the systems exposed its entire user database without any authentication - thousands of employee records including names, departments, and SSO account IDs.” Multiple entry points After mapping the government’s attack surface, the agents found multiple entry points including three hidden API endpoints that accepted any request body and returned a valid authenticated session without requiring user credentials. Using employee usernames harvested from an unauthenticated API, the agents broke into a government department’s office automation portal, solving its CAPTCHAs with 100 percent accuracy. The agents also tested predictable password patterns based on each employee’s ID, and cracked 85 accounts across multiple password-spray rounds. Eighty-four of the 85 cracked accounts successfully authenticated to the department's internal information system, giving the attackers access to internal dashboards, equipment management interfaces, and personnel statistics pages. In total, the illicit access allowed the agents to exfiltrate a ton of government information, including more than 2,564 personnel records, a full JSON export of all department system users, seven SSO client secrets, six internal database credentials across MSSQL, Oracle, and Sybase, and internal network IP ranges. But wait, there's more And then, the agents pivoted to the Taiwanese government’s supply chain. “It expanded the operation to government IT supply chain vendors, a nuclear safety agency, a government email system, and 7+ energy sector companies - scanning them all in parallel for misconfigurations, exposed admin interfaces, and exploitable vulnerabilities,” the researchers wrote. Notably, the attack framework implemented what the AI tools called “learning cycles.” These are autonomous sessions where the models search vulnerability databases, GitHub repositories, and other security research for specific techniques, CVEs, and common weaknesses to exploit in the targeted government's infrastructure. Additionally, when the AI framework made a mistake, it “self-corrected,” according to Dream, catching errors and fixing them through its own verification process. This near-autonomous attack comes as frontier model makers OpenAI, Anthropic, and Meta all admitted that their agents went rogue, escaped from their training environments, and autonomously hacked other organizations and people. OpenAI technical staffer Michael Dalton, in a Black Hat briefing last week about the Hugging Face attack, said “AI orchestrated, fully automated offensive attacks are real now.” “In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize, and use offensive agent collectives in the manner that you have just described here,” he added. It appears that the future is now. ®

If you thought that the famous Spectre security vulns were a relic of 2018, think again. Certain RISC-V chips are still very much subject to this hair-raising hole, researchers say. Spectre refers to a family of vulnerabilities related to speculative execution, a performance optimization technique based on predicting the flow of data before instructions have been executed. Incorrect predictions get rolled back without affecting running applications but nonetheless leave traces that can be recovered and exploited to violate memory protections and access secrets. Spectre flaws have dogged x86 and ARM chips for years, leading computer scientists to develop a series of defenses, including Indirect Branch Restricted Speculation (IBRS), Indirect Branch Prediction Barrier (IBPB), and Single Thread Indirect Branch Predictor (STIBP). Researchers affiliated with academic institutions in Belgium and Germany say that it's been popular to assume that the RISC-V chip architecture isn't affected by Spectre vulnerabilities because it's too simple. That assumption is incorrect, according to a paper accepted at the 35th Usenix Security Symposium, "Spectre on RISC-V Silicon: Attacks and Defenses on Commercial Out-of-Order Processors." It says that commercially available out-of-order RISC-V processors (SiFive P550 and T-Head Xuantie C910/C920) are vulnerable to all major Spectre variants. RISC-V processors that process instructions in-order (SiFive U74, Xuantie C906, C908) do not appear to be vulnerable. Prior research has shown that RISC-V processors used for academic research (e.g. BOOM, RiscyOO, RSD, Proteus, NaxRiscv, and NutShell) can be affected by one or more of the Spectre variants, but hasn't addressed commercial silicon. "We demonstrate proof-of-concept attacks on both processors using Spectre-PHT, Spectre-BTB, SpectreRSB, and Spectre-STL, achieving up to 100 percent recall with more than 97 percent precision," the paper states. Spectre-PHT involves mistraining the Pattern History Table; Spectre-BTB poisons the Branch Target Buffer; Spectre-RSB attacks the Return Stack Buffer; and Spectre-STL (Store To Load) exploits mispredicted store-to-load forwarding. To demonstrate the risk to RISC-V, they created a proof-of-concept Spectre exploit that leaks arbitrary Linux kernel memory on the Xuantie C910 at a rate of 338 B/s. Software-based defenses have been developed for these vulnerabilities on x86 and ARM hardware. Unfortunately, the researchers say, these don't necessarily transfer. They also call out RISC-V hardware for its lack of introspection interfaces, necessary to observe and reason about microarchitectural features. In addition, the authors argue, the diversity of the RISC-V hardware ecosystem means that no single mitigation strategy is likely to be effective across all systems. "RISC-V inherits the software and threat model of mature architectures without their accumulated hardening," the authors conclude. "Closing this gap is not a matter of porting individual mitigations, but of building the architectural primitives, hardware transparency, and ecosystemwide tooling that effective Spectre defense presupposes." The authors say they disclosed their findings responsibly last December. Three of their patches have been merged into mainline Linux and two others are under review. SiFive is said to have dealt with P550-specific findings and T-Head (Alibaba) is said to have committed to publishing ad-hoc speculation barriers for their processors at some point. The authors say they decided not to delay publication because Spectre has been around for eight years now. The paper was written by Lukas Gerlach (CISPA Helmholtz Center for Information Security), Marton Bognar, (DistriNet, KU Leuven), Daniel Weber and Michael Schwarz, (CISPA Helmholtz Center for Information Security), and Jo Van Bulck (DistriNet, KU Leuven). ®

Uber Freight says it is investigating a "data security incident" days after the Helix extortion group listed the company on its data leak site on August 6. Helix claims to have stolen nearly 1 million files from mailboxes, OneDrive accounts, the accounts receivable department, and other repositories. An Uber Freight spokesperson told The Register that the incident was under investigation but had not disrupted the company's daily operations. "We are investigating a data security incident involving unauthorized access to a portion of Uber Freight's systems and repositories. The incident was identified, contained, and remediated, and we promptly engaged federal law enforcement. "There has been no impact to Uber Freight's business operations, which continue in the normal course without disruption. Our systems are secure and fully operational." Uber Freight is the ubiquitous ride-sharing company's lesser-known logistics arm, which describes itself as "one of North America's largest managed transportation and multimodal capacity networks." Its website claims that it manages 18 million shipments carrying more than $17 billion worth of goods each year. The Register did not download the files Helix released in stages, and Uber Freight neither confirmed nor denied that the material was authentic. Helix is one of several recently established extortion brands linked by researchers to infrastructure associated with BlackFile, which retired its name in May. According to Google Threat Intelligence Group (GTIG), Helix shares infrastructure with the Pink, Redact, and Falcon brands. Google tracks the wider cluster of activity as UNC6671. Operators associated with UNC6671 often use vishing to gain an initial foothold, posing as IT helpdesk staff overseeing mandatory security migrations, Google said. They contact employees on their personal phones and use device code phishing to obtain credentials and authenticated sessions before siphoning data from cloud services such as Microsoft 365. They have also targeted Okta identity infrastructure. Researchers believe the UNC6671-linked brands have recently shifted toward organizations in higher-value sectors. Since June, they have favored technology, transportation, and hospitality targets after focusing on manufacturing, real estate, healthcare, and insurance during April and May. Why multiple brands emerged after BlackFile shut down is unclear. GTIG said the strategy could "compartmentalize operations, hide overall breach volumes, and isolate any negotiation fallout," although other plausible explanations exist. Internal disagreements over matters such as handling finances and operational security could have led to the fragmentation of UNC6671, GTIG speculated. The core members may also be looking to retain control over the intrusion and data theft aspects of the attack, while outsourcing negotiations and extortion. The different groups may also just be using the same commoditized phishing tools. ®