Japanese telecommunications giant KDDI Corporation has disclosed a cybersecurity incident that may have compromised the email credentials of millions of users. According to the company, attackers gained unauthorized access to an email system that supports services for five internet service providers (ISPs) in Japan.
KDDI detected the security breach on June 17 and said it took immediate action to block the attackers while deploying additional security measures to contain the incident.
The company's investigation found that the intrusion occurred after threat actors exploited a vulnerability in third-party software used within KDDI's email infrastructure.
"Although technical defensive measures have already been implemented for the system, there remains a possibility that customers' email addresses and passwords were obtained by unauthorized third parties as a result of the incident," KDDI warns.
KDDI, one of Japan's largest internet service providers, employs around 45,000 people and generates annual revenue of approximately $32.4 billion. Established in 2000 through the merger of IDO, DDI, and KDD, the company serves millions of customers across the country.
The breach impacted email services operated by the following ISPs:
STNet, Inc.
JCOM Co., Ltd.
Chubu Telecommunications Co., Inc.
NIFTY Corporation
BIGLOBE Inc.
While the investigation remains ongoing, KDDI estimates that email addresses and passwords belonging to as many as 14.22 million current, former, and inactive customer accounts may have been exposed.
The company noted that a portion of the affected passwords had been stored in hashed and/or encrypted form, reducing the likelihood of immediate misuse if accessed by attackers. However, it did not disclose the encryption method used or clarify how many passwords, if any, were stored in plaintext.
Since identifying the breach, KDDI has informed the affected ISP operators and reported the incident to Japan's Personal Information Protection Commission as well as the Ministry of Internal Affairs and Communications.
The telecom operator is working closely with the impacted ISPs to strengthen security measures and reduce potential risks stemming from the incident.
Customers whose accounts may have been affected are advised to reset their email passwords immediately. KDDI also recommends enabling two-factor authentication (2FA), where available, to provide an additional layer of account security.
Romania's healthcare system faced one of its biggest cyber crises in February 2024 when a widespread ransomware attack targeted hospitals across the country, disrupting critical medical services and exposing the growing vulnerability of healthcare infrastructure to cybercriminals.
The attack began when hackers infiltrated the systems of Bucharest-based software company RSC, compromising its widely used hospital management platform, Hippocrates. As the malicious software rapidly spread to connected hospitals, officials at Romania's National Directorate for Cyber Security (DNSC) realized immediate action was necessary to prevent a nationwide catastrophe.
Faced with limited options, DNSC Director Dan Cimpean instructed more than 100 hospitals to disconnect from the internet immediately. The drastic measure successfully halted the spread of the ransomware but also left hospitals without internet access, email services, and connected medical systems.
Medical staff were forced to abandon digital records and return to manual processes, relying on handwritten documentation and paper-based workflows while cybersecurity experts investigated the breach and IT teams worked to restore operations.
The incident has since become an important case study for disaster response planners worldwide, demonstrating how healthcare systems can continue functioning during a major cyberattack.
Surgeon Oana Goidescu, who was working at Buzău Hospital when the attack unfolded, described the challenges medical staff faced.
"It was quite an unpleasant experience, because an IT record is not just a list of patients." She explained the extent of the disruption by adding: "For each patient, we request lab tests, radiology, medicines and supplies. All of that was gone."
The Hippocrates platform plays a central role in hospital operations, handling patient admissions, laboratory requests, pharmacy logistics, payroll, medical records, and diagnostic results. Once compromised, hospitals across Romania experienced widespread service failures.
The ransomware used in the attack, known as BackMyData, encrypted hospital files and demanded payment in Bitcoin to restore access.
The first warning signs appeared at Pitești Children's Hospital on the morning following the breach. By the next day, numerous hospitals reported that their Hippocrates systems had stopped functioning.
Cybersecurity specialists collaborated closely with the software provider to identify infected systems, isolate the malware, and begin recovery efforts.
Meanwhile, hospitals developed temporary offline systems to continue treating patients.
Vlad Paic from Carol Davila Hospital explained how his team adapted. When we saw the system would not be repaired quickly, we developed an offline method so we could register every patient. He added:"We asked the laboratory to give us results on paper. We used Excel and other offline tools to ensure care was not affected."
Romania's relatively recent transition to digital healthcare systems proved somewhat beneficial, as many staff members were still familiar with traditional paper-based procedures.
Investigators later confirmed that 26 hospitals had been directly infected with the BackMyData ransomware. Unaffected hospitals were gradually reconnected to the internet after additional cybersecurity protections were implemented.
Authorities also relied heavily on public communication throughout the crisis. Patients were advised to avoid hospitals unless absolutely necessary, helping reduce pressure on already strained facilities.
Despite these efforts, medical staff often faced frustration from worried patients.
Goidescu recalled: "We were asked, 'What if it were your mother?' They were right to be angry, but we tried to explain we were not at fault."
Romanian authorities also issued clear instructions that hospitals should neither negotiate with the attackers nor pay the ransom. The hackers had demanded €160,000 in Bitcoin, but the government refused payment and instead focused on restoring systems through secure backups.
Regular data backups proved invaluable, allowing most hospitals to recover their systems within five days. Although no deaths or serious patient harm were reported during the incident, healthcare workers spent weeks manually entering records created during the outage, while some information was permanently lost.
Investigators have not publicly identified those responsible for the attack. However, authorities previously dismantled a ransomware group linked to BackMyData in an international law enforcement operation that resulted in the arrest of four Russian nationals outside Russia.
Reflecting on the incident, Dan Cimpean warned that no country is immune from similar threats. "The more technology you have, the more digitised you are, the greater the risk."
The Romanian cyberattack reflects a broader global trend. In the United Kingdom, a cyberattack on an NHS blood-testing provider last year contributed to the first officially confirmed patient death linked to a cyber incident. In the United States, attacks on Change Healthcare and Ascension caused major disruptions, with Change Healthcare reportedly paying a $22 million ransom.
Cybersecurity experts say hospitals remain attractive targets because of their essential services.
Alina Bîzgă of cybersecurity company Bitdefender explained: "Hospitals handle critical services, and the criminals think that the more disruption that can be caused, the more likely they are to get paid a ransom."
The Romania incident highlights the urgent need for stronger cybersecurity measures, routine system backups, and well-prepared emergency response plans to safeguard healthcare services against increasingly sophisticated cyber threats.
![]() |
A publicly disclosed security flaw affecting the browser-based version of Visual Studio Code has drawn attention from developers after a researcher demonstrated how attackers could potentially obtain GitHub authentication tokens through a single user interaction.
The issue was disclosed by security researcher Ammar Askar, who published technical details alongside proof-of-concept code showing how the vulnerability could be abused. At the time of disclosure, no CVE identifier had been assigned and Microsoft had not released an official software patch.
According to Askar's analysis, the weakness exists within github.dev, GitHub's web-based development environment that allows users to work with repositories directly from a browser using technology derived from Visual Studio Code. The attack takes advantage of the way VS Code's webview components communicate with the main editor environment.
Webviews are embedded browser windows used by extensions and web applications to display interactive content. While these components are designed to operate within restricted environments, the researcher found a method to abuse the message-passing mechanism that connects a webview to the editor interface.
The published demonstration shows how malicious JavaScript running inside a webview can trigger actions within the main editor window. By simulating keyboard input and user activity, the code can install a malicious extension without requiring the victim to manually perform the installation process.
Once deployed, the extension is capable of extracting a GitHub OAuth token that is transmitted when users access github.dev. OAuth tokens act as authorization credentials that allow applications to interact with GitHub services on behalf of authenticated users.
According to the researcher, the security concern extends beyond access to a single repository. The token passed to github.dev can inherit the permissions associated with the user's GitHub account, potentially granting access to every repository available to that account, including private projects.
Using the proof-of-concept attack, a malicious extension can retrieve the token and communicate with GitHub's API. This allows an attacker to identify repositories accessible to the compromised account and gather information about private development resources.
Askar argued that the broad permissions associated with the token significantly increase the potential impact of exploitation because access is not limited to the repository that initially triggered the github.dev session.
To reduce exposure while no official fix was available, the researcher advised users to clear cookies and locally stored site data associated with github.dev. Removing this stored data forces additional authentication checks that can help expose suspicious sign-in attempts.
After clearing the stored information, users attempting to access github.dev through a malicious link would be more likely to encounter a warning indicating that the GitHub Repositories extension is requesting authorization through GitHub. Such prompts can serve as an indication that unexpected account access is being requested.
The disclosure also highlighted ongoing tensions surrounding vulnerability reporting processes. Askar stated that GitHub was notified approximately one hour before publication of the research. He described the disclosure as a deliberate decision to release the information publicly rather than pursue a lengthy coordinated disclosure process.
The researcher cited previous interactions involving another VS Code vulnerability that he reported through Microsoft's security channels. According to his account, the issue was later addressed without attribution and was classified as having no security impact despite his concerns regarding its implications.
Askar said that experience influenced his decision to publicly disclose future VS Code security findings rather than continue working through Microsoft's reporting process.
The incident follows several other public disclosures involving Microsoft products by an independent researcher operating under the online alias "Nightmare Eclipse." Over recent months, that researcher has released details regarding multiple unpatched vulnerabilities affecting Windows and related Microsoft technologies, including flaws known as BlueHammer, RedSun, GreenPlasma, MiniPlasma, YellowKey, and UnDefend.
Some of those vulnerabilities were later reported as being actively exploited, further intensifying discussions within the security community about vulnerability handling, disclosure timelines, and communication between vendors and independent researchers.
Microsoft previously responded to some of those disclosures by warning that legal action could be considered when individuals engage in activities that cause harm to customers. The company also stated that it may cooperate with law enforcement agencies when necessary.
In comments provided following the publication of the VS Code findings, Microsoft emphasized the role independent researchers play in improving product security. The company stated that it remains committed to evaluating reported issues, coordinating engineering responses, and delivering mitigations intended to protect customers.
A subsequent statement from Microsoft indicated that the issue had been mitigated within its services and that users were not required to take additional action.
The developer-focused platforms remain attractive targets because authentication tokens can provide access to source code repositories, development environments, and organizational assets. Security teams generally recommend reviewing unexpected links carefully, limiting unnecessary permissions, monitoring account activity, and using strong authentication controls to reduce the likelihood of unauthorized access.
The incident caused the stoppage of milling activities at two of the firm’s facilities while authorities and experts tried to assess the disruption of the attack.
In a recent statement, Mackay Sugar acknowledged the cyberattacks and disruption impacting few of its operations.
The immediate priorities are ensuring staff safety, continuing business operations safely, and safeguarding operational systems. “Our immediate focus is the safety of our people, protecting operational systems, and maintaining business continuity,” it said.
Mackey Sugar is also working with authorities to inspect the incident and recover impacted systems safety.
The incident directly impacted production operations. Local media reports have hinted that the company was compelled to close down its Racecourse and Farleigh sugar mills, two key facilities based in Queensland’s Mackay area. This caused the growers to stop harvesting sugarcane until notified.
The group also verified that the Farleigh and Racecourse mills' cane hauling and sugar milling operations had been halted. Shortly after both facilities started their yearly sugarcane crushing season, there was an interruption.
Although many growers in the area have been impacted by the closure, producers in the Marian district have not been immediately impacted. The district's third mill for Mackay Sugar is not expected to start up until next week, according to a report from Australia's ABC News.
While recovery efforts continue, the sugar producer said it has put in place temporary measures and interim procedures to support critical business operations and minimize operational impact.
According to the company, "interim procedures are in place to support critical business functions and minimize disruption where possible."
Additionally, the company stressed that throughout the event, it is staying in touch with growers, staff, and business partners.
"We will continue to provide updates as more information becomes available and are in direct communication with our employees, growers, and key partners," Mackay Sugar stated.
Mackay Sugar acknowledged the anxiety brought on by the disruption and reaffirmed that company takes cybersecurity duties seriously.
"We take extremely seriously our obligation to safeguard our information, operations, and systems. We will give timely updates as we complete our inquiry, and we apologize for any inconvenience or uncertainty this incident may have caused," the business stated.
Security researchers have disclosed a now-remediated flaw that could have allowed specially crafted notifications from common messaging and social networking applications to influence the behavior of Google Gemini on Android devices.
The research was conducted by SafeBreach researcher Or Yair, who found that Gemini's ability to access and process notifications could be abused to deliver hidden instructions through otherwise legitimate messages. According to the findings, the technique did not rely on malware or a rogue application being installed on a target device. Instead, any service capable of sending a notification, including WhatsApp, Slack, Signal, Instagram, Messenger, or SMS, could potentially be used to deliver malicious content.
The study builds on SafeBreach's earlier "Invitation Is All You Need" research, which demonstrated how malicious Google Calendar invitations could manipulate Gemini through indirect prompt injection. Following that disclosure, Google introduced new safeguards designed to prevent external content from influencing sensitive actions. Yair's latest work examined whether similar manipulation could still occur through a different source of user data.
At the center of the issue was Gemini's Utilities feature on Android. The functionality allows the assistant to read, manage, and respond to notifications from connected applications. Researchers found that under certain circumstances, notification text could be interpreted not only as information but also as instructions that influenced the assistant's responses and actions.
Because the feature is available on Android devices and not through Gemini's web version or iOS implementation, the attack scenario was limited to Android users who had granted Gemini access to notifications.
According to SafeBreach, the number of potential entry points was unusually large because notifications can originate from countless applications and online services. This meant attackers would not necessarily need direct access to a device. Delivering a crafted notification could be sufficient to introduce malicious instructions into Gemini's processing workflow.
One of the simpler demonstrations involved altering the information Gemini presented to users. Researchers showed that manipulated notifications could cause the assistant to relay fabricated messages while making them appear to originate from legitimate contacts. In some scenarios, Gemini could process real notifications first and then attribute attacker-controlled content to an actual sender already present in the notification queue.
The researchers noted that this type of deception could be particularly effective when users interact with Gemini through voice. For example, someone driving a vehicle may hear a message that appears to come from a manager, colleague, or trusted contact and have little opportunity to verify the information displayed on the screen.
The research also examined Google's post-Calendar security protections. According to Yair, Gemini included mechanisms intended to prevent sensitive actions from being triggered without proper authorization. These checks evaluated both the user's response and the assistant's preceding output to determine whether a requested action was consistent with the conversation.
During testing, direct attempts to inject hidden commands were repeatedly blocked. To overcome these restrictions, Yair developed a technique called "Fake Context Alignment," which sought to make a user's approval appear valid to Gemini's authorization system while obscuring the true request from the user.
One variation involved displaying a sensitive authorization prompt in a language unfamiliar to the victim. Researchers used an example where a request such as "Do you want to open the window?" appeared in Chinese while a harmless English-language question followed. If the user responded with "Yes," Gemini could potentially associate that response with the hidden authorization request rather than the visible conversation.
A second technique relied on differences between information displayed on-screen and information spoken aloud by Gemini's text-to-speech system. Researchers found that certain hidden content embedded within hyperlinks might not be read aloud. In a demonstration, the visible interface contained a sensitive authorization request while the spoken response presented a routine message, increasing the likelihood that a user would unknowingly approve an action.
SafeBreach reported that combining these techniques increased the chances of bypassing the authorization safeguards that Google had introduced after the earlier Calendar-based attack research.
Once authorization was obtained, the researchers demonstrated several potential outcomes. Through integrations with Google Home, Gemini could interact with connected smart-home devices, including windows, lighting systems, and boilers. Additional demonstrations involved opening websites that could expose a user's approximate location through IP address information or trigger file downloads.
The research also explored interactions with third-party applications. In one proof-of-concept scenario, Gemini followed a trusted web address that later redirected to a Zoom link, resulting in the device joining an online meeting. SafeBreach emphasized that this occurred within a controlled testing environment and stated that its own public domain was not configured to redirect users to Zoom. Instead, the redirect was performed through a local test server used during the demonstration.
Researchers additionally identified a persistence mechanism involving Gemini's memory capabilities. Unlike the earlier Calendar-based research, the notification technique enabled the assistant to store attacker-controlled information as long-term memory. In one demonstration, Gemini was persuaded to remember an incorrect name for the user. Because memory is associated with a Google account rather than a single device, inaccurate information could potentially appear wherever that account later accessed Gemini.
The study also demonstrated the creation of recurring automated tasks. Researchers showed that instructions could potentially be scheduled to execute repeatedly, including examples involving regular access to recent messages at specific times.
SafeBreach disclosed the findings to Google's Vulnerability Reward Program on August 17, 2025. Google classified the report as a high-priority issue and later confirmed that changes to its content-classification systems mitigated both the notification-based prompt injection technique and the related authorization bypass method. The company confirmed the remediation on November 14, 2025.
No CVE identifier was assigned to the issue, and SafeBreach stated that it found no evidence indicating the technique had been exploited in real-world attacks before the fixes were implemented.
Because Google's mitigation was deployed through server-side updates, users did not need to install a software update to receive protection. However, individuals seeking additional safeguards can restrict Gemini's access to notifications by disabling the Utilities feature through Connected Apps settings or by revoking the Google app's notification-reading permissions on Android.
The findings provide another example of the security challenges that emerge as AI assistants gain access to messages, notifications, calendars, and connected services. As these systems become increasingly capable of performing actions on behalf of users, researchers continue to examine how external content can influence AI-driven decision-making and whether existing safeguards are sufficient to prevent misuse.