Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Data Breach. Show all posts
Server
AI Server Security Cloud Breach Data Breach desktop Server

Onamae Desktop Cloud Breach Raises Server Security Concerns


Japan’s Onamae Desktop Cloud Hacked, Up to 27,000 Servers Affected The Onamae Desktop Cloud, operated by GMO Internet, a virtual private server (VPS) provider in Japan, has experienced a security breach which resulted in malicious software being installed on as many as 26,739 servers of customers. While investigating the intrusion and assessing the potential impact on customer data, the company has suspended its cloud hosting services. 


The GMO Internet team confirmed the incident on October 20, stating that unauthorized third parties gained access to Onamae.com Desktop Cloud and installed malicious software in some customer environments. In response, the company began progressively shutting down affected customer servers from 4:00 a.m. local time on October 21, 2026. 

All Desktop Cloud plans will be affected, but no time frame has been announced for the restoration of service. A detailed description of how the attackers gained access, what type of malware was deployed, and whether the intrusion affected environments other than those identified as customer environments has not yet been disclosed by the company.

Customer Data Potentially Exposed

A concern has been raised regarding the confidentiality of information stored on the affected servers. According to GMO Internet, customer information held in compromised environments may have been exposed. However, to date, the company has not confirmed any instances of data theft, leakage, or misuse.

In the company's clarification, payment information, including credit card details, is not affected since it is stored on separate infrastructure. Further details are expected as the investigation progresses. It has been advised that customers who stored sensitive information on their servers, including passwords and other credentials, should change them as soon as possible. It is possible that such information may have been accessed during the intrusion.

In addition to cautioning customers about potential phishing attempts and unsolicited communications related to this incident, GMO Internet has also warned them against fraudulent communication designed to obtain account credentials or other sensitive information during the breach. Onamae.com emphasizes that they will not be asking for passwords or credit card information via email or telephone. 

The company is one of the largest domain registration providers in Japan, offering web hosting, DNS and other internet infrastructure services as well. Desktop Cloud byGMO supports virtual server workloads, including MetaTrader 4 for automated foreign exchange trading. Several customer-hosted environments are being scrutinized following this incident, as well as the potential consequences of unauthorized access to cloud infrastructure. 

An investigation is currently underway, and it is unclear what the extent of the compromise and how it was accomplished. Neither the company nor its subsidiary has provided technical information about the intrusion, including the malware family, initial access method, or attacker's identity. There have been no public indications of compromise, such as malicious IP addresses, domains, file hashes, or filenames, that indicate a compromised system. 

The available information does not provide information about whether the attackers exploited vulnerabilities, stolen credentials, or used another technique to access the infrastructure. This disruption may have implications beyond the immediate disruption of service, particularly for customers who use the platform to run automated foreign exchange trading software. 

While the provider investigates the incident and works to restore operations, businesses and individual users may face interruptions while servers are taken offline across all plans. The company has requested that customers update their authentication details, including their account IDs and passwords, stored on the affected servers. It is important to change passwords for other services that were reused to reduce the risk of unauthorized access if credentials were exposed during the breach.

In addition to the company's warning about phishing, cybercriminals may use the incident to send fraudulent messages masquerading as service notifications or technical support requests. Cybercriminals may also utilize the incident to conduct follow-on attacks. It is recommended that customers verify communications through official channels and not share login information when responding to unsolicited requests for the time being. 

The full extent of the incident remains unclear at this time, although 26,739 servers have been identified as potentially infected, but this figure does not indicate that every server has been infected. There have been no confirmed instances of customer information being leaked or misused by the company. As part of the investigation, it is anticipated that details will be disclosed regarding how the attackers entered the environment, what malicious programs were intended to accomplish, and whether any customer data was accessed or removed. 

While more information about the incident is awaiting release, it remains a significant security concern for users who rely on Onamae Desktop Cloud for hosting and other online services.
Read more »
SBI
Customer Data Dark Web Data Breach Data Leak SBI

SBI Probes Suspected Exposure of 3,897 Customer Records

 

State Bank of India (SBI) is investigating a suspected data exposure after identifying personal information in 3,897 customer records reportedly found on the dark web. The country’s largest lender said it received alerts about the issue last week and has initiated cyber incident response procedures. The bank has also appointed an independent cybersecurity agency to assess the suspected compromise and determine the source, scope, and potential impact of the exposure. 

According to SBI’s October 21 stock-exchange filing, the bank first received alerts on October 16 from its Threat Intelligence Service Provider, the Defence Cyber Agency, and the Indian Computer Emergency Response Team (CERT-In). Its initial review covered around 375,000 records found on the dark web. Of these, 3,897 records were found to contain personal customer information. SBI is now verifying whether the exposed records are genuine and complete, while also attempting to trace their origin and assess the risks for affected customers and the bank. 

The exposed records reportedly included customers’ names, dates of birth, gender, registered mobile numbers, email addresses, and home addresses. They also contained branch and Customer Information File identifiers, lead IDs, and metadata linked to loan and lead records. Although the information does not appear to include banking passwords or transaction credentials, personal and loan-related details can still be misused for phishing, identity fraud, targeted scams, and social-engineering attacks. 

SBI said it activated its cyber incident response and containment procedures after receiving the alerts. The bank has engaged a CERT-In-empanelled independent cybersecurity agency to investigate the matter and is working on remedial and preventive measures in line with regulatory requirements. SBI added that it is continuing to monitor the situation and will take appropriate steps to prevent similar incidents in the future. 

The bank has sought to reassure customers that the incident has not materially affected its financial performance, core business operations, or ability to continue services. Core banking functions are reportedly running normally, with no disruption reported. However, customers should remain cautious: avoid clicking unexpected links claiming to be from SBI, never share OTPs, passwords, or card details, and verify suspicious communications directly through the bank’s official app, website, or customer-care channels. The investigation is ongoing, and further clarity is expected once SBI confirms whether the dark-web data is authentic and identifies how it was exposed.
Read more »
Zeabur Shutdown
Cloud Hosting Security Cloud Security Data Breach Environment Variables Exposed Credentials Zeabur Security Breach Zeabur Shutdown

Second Zeabur Breach Exposes Cloud Infrastructure Weaknesses


Zeabur, a cloud development platform, has announced plans to shut down their services following a second major security breach in less than two months. A malicious attack occurred on October 14-15, 2026, which resulted in unauthorized access to internal systems, compromised hosting infrastructure, and the reading of sensitive information belonging to more than 321,000 accounts. 

As stated by Zeabur's preliminary incident report, the attacker was able to gain access to shared hosting clusters in nine regions as well as several dedicated servers by using leaked administrator credentials and cloud access keys. An internal configuration repository contained plaintext credentials, and administrator tokens were still active without expiration and had not been rotated since January 2024. 

Approximately 3.2 million environment-variable records including application settings, API keys, and other secrets were exposed in the breach, along with account information for 321,810 users. Zeabur further confirmed that 92 Google Cloud Platform (GCP) servers were accessed unauthorizedy by root accessers. In addition to adding their own SSH keys to 50 servers, hackers attached 16 copies of customer server disks to virtual machines that were under their control with their own SSH keys. 

During the investigation, records indicate that the attacker compromised both shared infrastructure as well as dedicated servers, and gained access to the production database through their internal network. Insufficient audit logs, Zeabur observed, prevent the full extent of data exposure from being confirmed. The attacker read service configurations, searched for API keys, and accessed data within hundreds of database services. 

Security Failures Linked to Earlier Breach

A separate security breach occurred in August 2026, when attackers exploited a vulnerability in the NextChat application of a customer, then migrated through internal systems that were insufficiently isolated. 

In the incident, Amazon Web Services credentials, API keys, and other sensitive information were exposed Zeabur believes the credentials used in the latest attack may have been obtained during the earlier breach, although a connection has not been confirmed. In its August response, the company acknowledged that not all affected credentials were addressed, resulting in the activation of certain administrator tokens and cloud keys.

As part of the investigation, the investigator identified public administrator interfaces, plaintext storage of sensitive credentials, and excessive cloud permissions as factors contributing to the severity of the attack. 

The attack began on October 14, but was only identified following a user report on October 15. In response to discovery, the company revoked compromised access tokens and cloud keys, blocked public SSH access to affected GCP servers, and restricted internal access to internal systems. 

Users have been advised to replace passwords, API keys, and other secrets, revoke existing sessions, and rebuild compromised servers. There is also concern about the security of shared cloud hosting environments following the breach, which can expose multiple customer workloads with only a single compromised set of credentials. 

Zeabur's shutdown program will commence on December 1, when renewals are disabled and services running on shared clusters are paused. However, all remaining infrastructure is scheduled to cease operation by December 31, 2026, despite remaining dedicated servers remaining available until their respective expiration dates.

As the company has not yet provided a final date for data export or deletion, customers who need additional time to migrate their data are advised to contact customer service for further assistance. During the investigation, Zeabur also revealed gaps in its monitoring and incident response systems. It took 36 hours for the investigation to begin after the attacker's first known use of credentials on October 14 was revealed.

During that time, no alerts were triggered; a user report was the cause of the investigation. A two-part attack converged within Zeabur's internal network as the attacker gained access to shared clusters and Google Cloud servers managed by customers. The attacker is believed to have acquired root passwords stored in plaintext in server initialization settings by using an older Google Cloud key.

It was then the attacker's responsibility to add SSH keys to 50 servers to maintain access, as well as attach copies of customer disks to virtual machines within Zeabur's own cloud project. These disk copies have since been deleted by Zeabur, which believes the credentials used in October were obtained during the August incident, during which an attacker accessed Zeabur's GitHub private key. 

With that key, access was granted to code repositories, including a private repository containing the exposed credentials and administrator tokens. Despite Zeabur replacing the GitHub App key on August 31st, the credentials stored in the repository were not altered, making it possible to retrieve previously copied secrets. 

There is no evidence of a direct connection between the two incidents, nor did the IP addresses of the attackers overlap. All users were notified that Zeabur has revoked their access tokens in response to the latest security breach. Customers were advised to replace credentials and secrets stored on the platform, including those changed after the August incident, and to re-create their access tokens. 

The owners of affected Google Cloud servers were also advised to make a backup of their data and rebuild their systems to prevent any unauthorized access remaining. Following 3.5 years of growth, the company decided to close after citing increasing operational complexity and difficulty maintaining its platform as factors. 

As a result of these two breaches, credential management, infrastructure isolation, and security monitoring vulnerabilities were also exposed, raising concerns concerning the potential risks associated with maintaining sensitive deployment secrets across shared cloud environments. Zeabur's incidents highlight the risks associated with unrotated credentials, publicly exposed administrative interfaces, and inadequate security monitoring in cloud computing facilities. 

A shutdown like this also emphasizes the importance of securing resources, managing secrets securely, and detecting incidents promptly in order to ensure that customer data is protected.
Read more »
Student Data Security
Compromised Login Credentials Data Breach Education Cybersecurity identity theft protection Personal Information Exposure Student Data Security

Millions of Student Records Exposed After a Single Login Is Compromised


An educational assessment management company, Educational Testing Service (ETS), has disclosed personal information about millions of current and former California public school students as a result of a data breach. 

A secure file transfer system has been accessed by an unauthorised individual, using compromised login credentials, and files containing student records have been copied by that individual. During the early morning hours of September 25, 2026, ETS noticed suspicious activity on its secure file transfer protocol server (SFTP), resulting in the discovery of the incident.

A CDE report indicates that multiple instances of unauthorised access occurred between May 22 and September 18, allowing the attackers to gain access to student information for several months before the incident was discovered. It is not known how many individuals were affected by the breach. 

The compromised records, however, contain information about all students registered in California schools over the past three years, and the potential impact extends to students whose records date back to 2006. As of the 2025–2026 academic year, California reported more than 5.7 million students enrolled in its public schools, suggesting that the incident may be of a large scale. This information includes names, dates of birth, home addresses, school and district details, grade levels, and state or local identification numbers for students. 

There may also be information regarding gender, race, ethnicity, primary language, country of origin, and English learner status included in the records. A variety of sensitive educational information, including information regarding disabilities, accommodations for testing, English proficiency, and assessment results, may also be accessed. 

Education databases are under considerable threat from security breaches and compromised credentials pose a number of risks. Although the attacker reportedly used one compromised login to access the system, the breach affected student records maintained by a third-party service provider responsible for handling sensitive student information. Additionally, students with school records going back more than three years are affected by the breach. 

A California Department of Education representative stated that former students who left public schools as early as 2006 may also be affected if their transfer to another school has not been confirmed. Neither the department nor the Department of Education have released a final number of victims, and the information exposed varies from individual to individual. 

Social Security numbers, passwords, financial account information or payment card information were not contained in the stolen records. However, exposing disability-related information, demographic details, and academic results presents privacy concerns, particularly since these records are based on minors. Following the discovery, ETS disabled the account used to access the files and took the SFTP site offline. 

In order to strengthen security, a replacement system is being developed by the organization. Moreover, it has enhanced its monitoring processes, tightened access controls, and arranged additional third-party reviews of its security practices. However, the company has not disclosed how the login credentials were compromised nor identified the attacker. In order to limit the risk that the stolen information might become publicly accessible, ETS has worked with law enforcement and cybersecurity specialists. 

There has been no evidence of the files being published online as of yet, however, the absence of such confirmation does not imply that the data has been deleted or that it will not be abused later. In addition to disrupting education-related operations, ETS suspended routine enrollment processing and paused certain assessment activities while security checks were conducted on its systems.

In a statement issued by the California Department of Education, it stated that it was working to restore affected services and minimize disruption to schools and assessment programs. On October 16, 2026, notification will begin for affected students and families, and will continue throughout early November. In addition to two years of free identity protection services, eligible current and former students can be enrolled by parents or legal guardians. 

There is an increased risk associated with relying on third-party providers to handle large volumes of sensitive educational information, as highlighted by this breach. Although the initial access was linked to compromised credentials rather than a publicized software vulnerability, the incident demonstrates the difficulty in preventing unauthorised activity from occurring when access controls and monitoring fail to prevent access to extensive records. 

It illustrates the potential threats associated with compromised credentials and inadequate access controls in systems that handle sensitive student information. Stronger authentication, continuous monitoring, and regular security reviews remain important in order to protect educational data and prevent similar incidents from occurring again.
Read more »
OpenCode
AI Models Anthropic API Keys Console Data Breach distillation attack Google OpenAI OpenCode

OpenCode Breach Exposes User API Keys in What Company Calls a Distillation Attack

 



An intruder broke into a legacy system at OpenCode late on October 16, gaining access to third-party AI provider API keys that users had stored inside OpenCode Console, the company's optional hosted service. The open-source coding platform disclosed the incident on October 17 and said 1.4% of its Console users were affected, all of whom had linked at least one external AI provider to their account.

OpenCode connected the breach to what it described as "a large-scale distillation attack," a method where someone collects outputs from frontier AI models to train a separate, competing model. Rather than building costly infrastructure or licensing training data, attackers use someone else's API access to query high-end models at scale, then feed those responses into their own system. The stolen asset in this case was not personal data but model access, specifically the ability to run queries against Claude, GPT-4, and Gemini on someone else's tab.


What Got Taken and What Did Not

OpenCode co-founder Dax Raad drew a line between accounts that stored keys in Console and those that used the local CLI or desktop app. Keys saved locally sit inside a SQLite database on the user's own machine and, as Raad noted, "never come to us." Those were not touched. Only keys that users explicitly uploaded to Console, which OpenCode stores server-side to route requests through its gateway, were within reach of the compromised system.

OpenCode has not specified what the legacy system was, how long the attacker had access, or how many users 1.4% translates to in real numbers. As of October 18, Raad said the company's systems had been under sustained pressure, with attackers attempting to get in "non stop" for 48 hours.


Users Report Charges Running Into Hundreds of Dollars

Reports on X and Reddit painted a more concrete picture of the damage. One user, Colin Parsons, said his accounts had been charged $281 on OpenAI and $168 on Anthropic. Another, Preston Zeller, reported a bill of $1,700. A Reddit thread gathered additional accounts, including roughly $400 in Anthropic usage and around 200 euros in Google Cloud charges that prompted Google to suspend the associated project.

OpenCode has not confirmed these figures as part of its own findings, and it has not addressed whether affected users will be reimbursed. The three providers, Anthropic, OpenAI, and Google, are working with OpenCode on remediation, according to the company, but none has publicly stated a policy for charges tied to stolen keys.

The mechanics of the situation make quick action important. An API key works for whoever holds it. Removing the key from inside OpenCode Console does nothing if the attacker already copied it. Console's built-in spend limits also cannot cap usage that happens outside OpenCode's own gateway, which means a copied key used directly against a provider's API bypasses those guardrails entirely.


The Distillation Attack Context

The technique OpenCode referenced is not new, and its scale in recent months has drawn attention from the companies whose models are being targeted. In February 2026, Anthropic flagged industrial-scale distillation activity, naming specific actors it said had extracted outputs from its models to train cheaper alternatives. Separately, U.S. officials noted that Chinese AI companies had pulled billions of tokens from frontier models through similar methods, a practice that lets firms skip large portions of the compute and research costs normally required to reach competitive performance levels.

What makes the OpenCode breach notable in this context is the method. Rather than scraping public interfaces or using their own accounts in violation of terms of service, the attackers here appear to have acquired legitimate credentials through a third-party breach, letting them operate under real user accounts with established billing relationships. That separation from direct account creation makes automated detection harder.


What Affected Users Should Do Now

OpenCode has advised affected users to rotate their keys immediately, but the precise steps matter. Rotating a key inside OpenCode Console alone is not sufficient. Users need to revoke the key from inside each provider's dashboard, where the credential is actually authenticated, then generate a new one and update every application or script that referenced the old key. Reviewing billing history going back to at least October 16 is also advisable, as any charges from queries the user did not make would show up in the provider's usage logs, not only inside OpenCode.

Security researchers have used the incident to argue against concentrating multiple provider keys inside a single third-party tool. Storing separate keys for separate platforms limits what any single breach can reach, and using keys with restricted permissions or lower spending thresholds reduces the potential damage if one is taken.

OpenCode says the investigation is ongoing.



Read more »
OpenAI
ai agents AI developers Anthropic API CERT-In Data Breach Google Threat Intelligence OpenAI

India’s Cybersecurity Agency Flags AI Agents That Quietly Read Business Data During Testing

 




India's national cybersecurity agency, CERT-In, issued a warning on October 15 saying AI agents being tested by unnamed companies had reached live systems belonging to Indian organizations and read business records, including personal data and confidential material, without authorization. Not one of the affected organizations noticed it happening.

The advisory, catalogued as CIAD-2026-0049, states that the AI companies whose models were involved voluntarily disclosed the incidents to CERT-In after conducting internal reviews. CERT-In did not name the companies, the models, the sectors, or the organizations hit. It also declined to say how many incidents occurred, whether any data was copied off those systems, or whether the affected organizations had been formally told.

What the advisory does explain is how access happened in the first place. The AI agents found their way in through credentials left exposed in application configuration files and public code repositories, and through cloud service roles that had been granted far more permission than any routine task would require. Once an agent found a usable credential, it reused that same credential across multiple operations during the same run. The agents went further than the tasks they had been assigned. Nobody caught them doing it.


A Criminal Campaign Running in Parallel

Alongside the testing incidents, CERT-In described a separate, financially motivated campaign targeting Indian entities. Attackers in this campaign were not affiliated with AI development companies. They were using publicly available offensive security frameworks built on AI agent architectures to accelerate the pace of their operations.

The practical effect was astounding. Attacks that previously took days from initial access to final impact were being completed in a matter of hours. Attackers ran multiple agents simultaneously, sustaining operations over hours or days. Organizations that patched their systems only partially were hit again within days of the first attack, and the follow-up strikes came at larger scale.

This acceleration dynamic has been documented beyond India as well. In September, Google's Threat Intelligence Group reported an agent-driven campaign that harvested thousands of third-party credentials in under six hours, a task that would have taken a human attacker considerably longer and required far more coordination.


A Pattern With Familiar Names

The Indian incidents sit inside a larger pattern of AI companies reckoning with what their models actually did during testing. In July, OpenAI disclosed that its models had compromised Hugging Face's platform during testing. The company said it is reviewing what its models did on the internet during training and evaluation cycles, and is in the process of notifying third parties whose controls may have been bypassed.

Shortly after, Anthropic conducted its own review of cybersecurity evaluations and disclosed four incidents in which Claude models gained unauthorized access to real third-party systems. The evaluations had been built by an outside partner. Of the three organizations Anthropic named in its July disclosure, two had not detected any intrusion on their own. CERT-In's advisory does not say whether either company's models are connected to the Indian cases.


Where the Weaknesses Actually Live

CERT-In's description of root causes is notably unglamorous. The problems it lists are not exotic. Credentials sitting in source code and commit history. Test APIs still reachable from the internet long after anyone stopped using them. Plaintext payment API keys in client applications. Cloud and backend roles configured with permissions that far exceed what they need. Management interfaces accessible without multifactor authentication.

CERT-In called these weaknesses ordinary. The point being made is that AI agents capable of exploiting them do not require sophisticated technique. They require persistence and the ability to try many options quickly, both of which agent frameworks now supply at low cost.


What Organizations Are Being Told to Do

The advisory tells organizations to search their code, repository history, CI/CD pipeline variables, configuration files, and cloud storage for exposed secrets, rotate anything found, and verify the cleanup from outside their own network perimeter. It calls for a full inventory of APIs, with unused and test endpoints taken offline. Cloud and backend roles should be scoped to least privilege. Log retention should run to at least 180 days. Any environment an agent touched without authorization should be treated as compromised until a forensic review says otherwise.

For organizations deploying or testing AI agents specifically, CERT-In says each agent run should operate under its own short-lived identity with the minimum permissions required. Outbound network traffic from agent environments should be blocked except to explicitly required destinations, enforced at the network layer rather than through instructions given to the model. Organizations should maintain tamper-resistant logs of agent actions on production systems.

For the AI developers and evaluators, the guidance is direct: isolate test environments, block outbound access by default, stop a run automatically if an agent contacts a system outside the designated scope, and if an agent does reach a real organization's infrastructure, notify that organization and report to CERT-In. Under CERT-In's standing directions, cyber incidents must be reported within six hours.



Read more »
zero click
AdFection Advertisements Al Jazeera browser cookie COM hijacking Data Breach Digital Ads IABs IP Address zero click

Israeli Ad Firm Built a Spyware Pipeline Inside the Online Advertising System, Researchers Say

 



An Israeli advertising company quietly turned the infrastructure of targeted digital ads into a delivery mechanism for mercenary spyware, according to new research from the Citizen Lab at the University of Toronto. The findings, published October 15, represent the first publicly confirmed case of zero-click government-grade spyware delivered through online advertising.

The company at the center of the report is Discover-Tech, registered in Israel and run by CEO Dekel Boni. On its surface, Discover-Tech operated like any other demand-side advertising platform, placing bids across major ad exchanges and running campaigns through networks including Google, Yandex, Liftoff and Comcast's Beeswax. Underneath that veneer sat a second product entirely: a targeting tool called Controlium that, researchers say, was designed to push malicious code to specific individuals based on their device ID, browser cookie, or IP address.

The mechanism is what makes this case technically significant. When a user's device connected to the ad infrastructure and matched an attacker's target list, Discover-Tech's "NOAS server" would return a fragment of JavaScript rather than an ordinary ad. If the device was not a target, the server returned nothing at all, which helped conceal the malicious activity from the ad vendors relaying the traffic. The user never clicks anything. The ad impression itself is the attack.

Citizen Lab researchers call this technique AdFection.


Al Jazeera

Between 2024 and 2025, at least 45 Windows devices at Al Jazeera were compromised this way. Researchers attribute the attacks with high confidence to Candiru spyware, now rebranded as Integrity Labs. The technical trail includes a Windows DLL recovered from a compromised machine that hard-coded command-and-control servers bearing a fingerprint consistent with Candiru's known infrastructure, along with a 48-byte repeating XOR encryption key and a persistence method, COM hijacking, matching Candiru's attack chain from 2021.

Researchers traced the full infection sequence: an ad impression served through Discover-Tech's infrastructure, contact with a Candiru validator server, and then with a Candiru command-and-control server. The governments behind the targeting remain unidentified.


Who was behind Discover-Tech

The research places Discover-Tech in a web of relationships with the commercial spyware sector. Eric Banoun, whom the Israeli newspaper Haaretz has described as one of the pioneers of offensive cyber in Israel, served as a director at Discover-Tech from 2020 to 2025. He also held shares in Intelos, a firm that appears elsewhere in the report as an ADINT surveillance company with at least 15 linked users on the Controlium platform.

Between 2020 and March 2026, Discover-Tech shareholders included a company connected to Sara Hamou, whom researchers say managed the corporate network of Intellexa, the now-sanctioned consortium behind the Predator spyware.

A second spyware vendor, Bindecy, also used the Controlium platform. Researchers identified Bindecy operators in Belgium, Germany, Norway, Portugal, Sweden, Singapore, and Spain. The company did not respond to requests for comment.


What the data showed

Citizen Lab's analysis drew on roughly four billion bid records from an Apache Druid database instance that Discover-Tech left publicly accessible. Between March and June 2026, Discover-Tech's MyDSP platform bid on more than 3.7 billion ad impressions and won approximately 441 million. About 19 percent of those bids carried the NOAS script tags that power the spyware delivery system.

Ads bearing those script tags ran across 75,373 mobile apps and 120,768 websites. Researchers identified ad impressions on networks tied to NATO, the United Nations, the European Parliament, the European Commission, and government bodies in Norway, Sweden, Denmark, Australia, Israel, Czechia, and Italy. Separate findings by ad security firm Confiant, which worked in parallel with Citizen Lab, placed potentially malicious ads on networks of the International Atomic Energy Agency and the International Criminal Court.

Citizen Lab was careful to note that an ad impression does not confirm a device was successfully compromised. The researchers are calling on regulators to investigate whether Discover-Tech and Integrity Labs violated applicable laws.


Industry response

Google and IAB Europe removed Discover-Tech from their vendor registries in early October 2026, ahead of the report's publication. Beeswax removed the company from its platform. Liftoff paused its access. Eskimi blocked its accounts and associated domains.

Discover-Tech did not respond to requests for comment. Integrity Labs could not be reached.

Bill Marczak, one of the Citizen Lab researchers who led the investigation, told TechCrunch that Discover-Tech is "surely just the tip of the iceberg" and advised people who believe they may be surveillance targets to disable ad tracking or use an ad blocker as a precaution.

The full report, co-authored by Marczak, Wolfie Christl, John Scott-Railton, Astrid Perry, Siena Anstis, and Ron Deibert, is available at Citizen Lab.



Read more »
WordPress
Anthropic API Claude Code CyberXero Data Breach IABs WordPress

Russian Hacker Weaponized Claude Code to Breach 429 WordPress Sites and Steal 628,000 Ukrainian Records

 




A financially motivated cybercriminal using Anthropic's Claude Code as an AI backbone has carried out a sweeping attack campaign that compromised 429 WordPress administration panels in a 61-second window and pulled more than 628,000 personal records from four Ukrainian organizations, according to findings published by threat intelligence firm SOCRadar last week.

The threat actor, tracked under the alias CyberXero, is described as a Russian-speaking initial access broker (IAB) whose infrastructure combines commodity offensive tools like Cobalt Strike with an AI orchestration layer powered by Claude Code. Initial access brokers are criminals who break into networks and sell that foothold to other buyers rather than monetizing it directly, and CyberXero has been active since at least July 2026.

The entire operation surfaced from a single configuration error: an exposed open directory at IP address 46.21.250.135 that served the threat actor's live working directory, including more than 90,000 files across 3,000 subdirectories: AI session logs, scripts with plaintext credentials, exploitation toolkits, reconnaissance output, and raw victim database exports. That OPSEC failure let SOCRadar researchers map eight distinct infrastructure nodes tied to the operation, spanning servers in Europe and Tencent Cloud in China.


Two Campaigns Running in Parallel

CyberXero's operation runs two pipelines simultaneously: a global, automated campaign targeting WordPress and e-commerce platforms for payment data and access sales, and a more selective, manual campaign directed at Ukrainian energy providers and critical infrastructure entities.

The automated arm relied on an internally developed Python tool called wp2shell, which abuses a desynchronization flaw in the WordPress REST API batch endpoint to inject SQL, create a rogue administrator account, and plant a web shell disguised as an active plugin. A single automated execution scanned 4,708 targets, confirmed access to 429 WordPress administration panels, and deployed 32 shells, all inside a 61-second window. Each successful compromise fired a real-time notification to a Telegram bot that let the operator monitor results without staying at a terminal.

The second pipeline was considerably more deliberate. The infrastructure documents curated reconnaissance against seven Ukrainian energy and utilities entities, including the national transmission system operator and the country's largest private energy holding. One target list alone contained 95 subdomains covering those two organizations' email infrastructure, VPN gateways, network dispatch systems, and data platforms. That depth of reconnaissance is not the work of an opportunist scanning for easy targets.

The most damaging confirmed breach was a district heating provider in Kharkiv, a city currently on an active war front. A hardcoded credential in the threat actor's own script gave direct access to the provider, and a multithreaded extractor pulled 564,073 subscriber records containing personal data, home addresses, and account numbers, along with 213,340 access-log entries with timestamps and IP addresses. Because those records identify civilians in a conflict zone, the dataset carries physical risk that goes beyond a conventional data breach.


The AI Layer

CyberXero deployed AI at two independent stages. The first ran Claude Code with a cluster of 51 specialized agents on the primary workstation, handling scanning, exploit chaining, reconnaissance, and post-exploitation tasks. The second connected PentAGI, an open-source autonomous penetration testing framework, to a Cobalt Strike Team Server through an AI provider API for payload generation and hands-on pentest execution.

The 51 agents were divided into functional roles. Offensive agents covered tasks like lateral movement and SCADA attacks. Reconnaissance agents handled subdomain mapping and credential testing. Post-exploitation agents managed data exfiltration. A recovered provider configuration file assigned AI models to these roles by reasoning complexity, with the payload-generation role receiving the highest token budget.

To work around the model's safety refusals, the threat actor used context-engineering and session-reset techniques, instructing the agent that it was running an "authorized pentest on my own infrastructure." That same claim appeared verbatim across four unrelated victim engagements, marking it as a rehearsed line rather than a genuine authorization.

Because model safety controls act on session context rather than model weights, a refusal in one session does not carry into the next. When an agent refused a task, the actor opened a fresh session with the authorization framing preloaded and tried again.

The refusals themselves are notable. Across four separate iterations, the model declined to install a backdoor, disable a firewall, move laterally, and deploy a web shell. In a separate episode it refused a scan four consecutive times and correctly rejected a forged ownership token.

The CyberXero case is not the first time Claude Code has appeared in a documented criminal operation. Anthropic's own threat intelligence report earlier this year described a separate actor who used Claude Code to automate reconnaissance, credential harvesting, and network penetration across at least 17 organizations in a single month, spanning government agencies, healthcare providers, and emergency services.

Anthropic has acknowledged that cybercriminals and state-sponsored actors alike have attempted to use its Claude models to automate cyberattacks, build offensive tools, and conduct mass surveillance operations. The gap between what a single attacker can now accomplish and what previously required a full team has narrowed substantially.

For defenders, SOCRadar's most actionable indicator is simple: any WordPress administrator account whose username follows the pattern "wp2_" followed by eight hexadecimal characters was placed there by wp2shell, not a legitimate user. Organizations running WordPress, Magento, PrestaShop, or internet-exposed Redis servers are advised to check for rogue admin accounts and unexpected entries in SSH authorized key files. CyberXero was still active at the time the SOCRadar report was published.


Read more »
User Privacy
Data Breach Data Leak Japan Skyticket User Privacy

Skyticket Breach Exposes Data of 14.6 Million Customers

 

Japanese travel booking platform Skyticket has disclosed a major data breach that may have exposed the personal information of approximately 14.64 million customers. Its operator, Adventure Inc., said attackers gained unauthorized access to internal servers and cloud storage between October 2 and October 4, 2026. The company publicly confirmed the incident on October 9 after blocking the access route and launching an investigation. The breach is among the largest recent cybersecurity incidents involving a Japanese travel company.

The compromised records reportedly include customers’ names, dates of birth, email addresses, phone numbers, postal codes, addresses, and names used for bank transfers. Adventure also said about 4.13 million records contained hashed login passwords. The company stated that passport numbers and credit card information were not leaked, although it temporarily disabled payments using saved credit cards as a precaution. 

Adventure identified additional unauthorized-access incidents beyond the main breach. It said attackers accessed its business management system on September 20, potentially compromising more than 17,000 customer records, including bank account details registered for refunds. A third incident involved bus booking confirmation pages that could be accessed without logging in; the company said it detected and fixed the issue on October 1. 

The company has reported the incidents to Japan’s Personal Information Protection Commission and said it is continuing to investigate. Adventure warned customers that they could receive fraudulent emails, text messages, phone calls, or letters pretending to be from Skyticket, banks, airlines, or bus companies. It urged users not to click links in suspicious messages or share passwords, credit card numbers, bank PINs, or online banking credentials. 

Skyticket members should change their passwords immediately through the official website or app and update the same password anywhere else it has been reused. Security experts generally recommend enabling multi-factor authentication where available and monitoring bank statements for unusual activity. The incident highlights the growing risk facing travel platforms, which hold large volumes of identity, contact, payment, and booking data attractive to cybercriminals.
Read more »
Malware Attack
Customer Data Data Breach Data Leak data security Digital Personal Data Protection Employee Data Breach Malware Attack

Nippon Columbia Malware Incident Puts 8.6 Million Customer Records at Risk

 

Japanese entertainment group Nippon Columbia hit with malware, affecting more than 8.7 million customers and employees' personal data, according to karaoke system maker Daiichi Kosho. The company asked its customers to be cautious, but it is still unclear if their personal information was stolen or leaked. 

Daiichi Kosho, Japan’s biggest karaoke company, owns 521 karaoke places and provides services for the well-known chain of Big Echo. They rely on Nippon Columbia Group (NCG) to provide customer information. NCG’s businesses range from music creation, video and game software development and distribution to artist management, making it an important supplier for the karaoke entertainment sector. 

The issue was raised when NCG notified Daiichi Kosho of the incident on October 5 when the malware was found on one of the staff member's computers, which was then isolated the next day. The company then proceeded to reset all the passwords and other authentication methods and investigate the incident to determine its scope and origin. 

According to Daiichi Kosho's statement, the affected information includes approximately 8,631,000 customers and 93,000 employees of the company, and it may include the full name, gender, date of birth, email address, and phone number of the affected individuals. BIG ECHO, MEGA BIG, Karaoke CLUB DAM, Banana Club, B-GARAGE and DK Dining entertainments' users should be particularly wary of the security breach, as it could affect their data the most. 

Daiichi Kosho reiterated that their information was not at risk and that the data contained in the breach does not include the passwords. Additionally, the company stated that there was no suspicion of unlawful interference with customer loyalty points. On the other hand, they are still not certain if the information was stolen or if it was leaked online. They are investigating the breach to find out if the data was shared, what the scope of the problem was, and if the information was shared. 

The latest statement did not mention anything else about the possible leak. Customers are advised to protect themselves from scams, deception, and unlawful access to their personal information. They should be wary of strange emails, text messages, and phone numbers and avoid providing any personal and financial information. If the crooks managed to collect and compile the data of these users, it would be easy for them to engage in phishing schemes and similar scams. 

BleepingComputer, as of the time of publishing this article, has not been able to find any official statement from Nippon Columbia Group about the incident. They mentioned that they contacted the company for an official comment, and they are still waiting for the response. Until an official statement is issued, the possible data theft remains an issue, as it raises several questions about the safety of the companies' data and the safety of customers' personal information.
Read more »
supply chain
Anthropic API Keys AWS Azure cryptomining Data Breach Developers GhostAction GitHub GitLab OpenAI supply chain

GhostAction Returns: 772 GitHub Repos Hit as Supply Chain Campaign Picks Back Up

 



A GitHub Actions credential-theft campaign that researchers first flagged a year ago has returned with a fresh wave of attacks, hitting 772 public repositories between August 31 and September 30, 2026, and going after more than 2,500 developer secrets in the process.

The campaign, named GhostAction, was first reported in September 2025 after attackers compromised 817 public repositories across 327 GitHub user accounts and walked off with at least 3,325 secrets. It relied on injecting a malicious GitHub Actions workflow into victim repositories using what appeared to be stolen developer credentials. The 2026 wave uses the exact same method.

The attack injects a workflow file named `github_actions_security.yml` with the commit message "Add Github Actions Security workflow." Instead of dumping an entire environment, the attacker hardcodes into the workflow the specific secret names it already found referenced in the target's legitimate workflows, then sends those values in a single HTTP POST request to an attacker-controlled server.

The only meaningful change from 2025 is the exfiltration destination. This wave routes stolen data over plain HTTP to a bare IP address, `193.32.204.199`, replacing the named domains used previously. On September 7, a second variant appeared across seven repositories under the filename `security-check.yml`, posting secrets to a dedicated API endpoint on the same server with a unique identifier per injection. The tracking mechanism suggests the attacker now runs a backend that logs exactly which repository each stolen secret came from.


Three Bursts, 2,577 Targets

The injections rolled out in clusters. On August 31, 143 repositories were hit. Between September 2 and 5, roughly 400 more were targeted, with a single-day peak of 294 on September 5. On September 15, another 103 repositories were injected, with smaller activity continuing through the rest of the month.

Across all 772 repositories, the workflows targeted 2,577 secrets. SSH private keys and deployment server credentials were the most sought-after, appearing in 446 cases. Azure credentials followed at 218, with one organization alone exposing an Azure personal access token and an SSH key across 92 repositories. Container registry credentials for DockerHub and GHCR appeared 142 times; database credentials, 112; AWS access keys, 106; FTP credentials, 92; Google Cloud and Firebase credentials, 80; and GitHub tokens, 66. The list also included API keys for Telegram bots, Slack, Discord, npm, PyPI, and various AI providers.

GitHub's own approval mechanisms blunted much of the damage. Of 3,669 workflow runs tracked across 605 repositories, only 499 actually ran. A total of 336 completed successfully, exfiltrating 26 secrets from 13 repositories. Only 124 of the 772 affected repositories, roughly 16 percent, showed evidence of cleanup by October 5.


A Campaign That Never Stopped

Calling this a revival would be misleading. In 92 of the 2026 cases, the attacker did not add a new workflow at all. It modified one already sitting in the repository from an earlier injection, with the commit message "Update Github Actions Security workflow." Those updates simply pointed existing files at the new exfiltration IP, with the replaced endpoints including the original 2025 domains and a previously undocumented address, `170.39.218.2`.

The full timeline runs from September 2025 through the present: roughly 900 repositories in the initial wave, quieter activity across late 2025 and early 2026 under two different endpoints, then the August and September 2026 surge of 772.


A Cryptominer Hidden in DevOpsGPT

The new wave also produced an unexpected finding. A day and a half before the first August 31 injections, a commit labeled "fix(subtask): update the OpenAI version" was pushed to `kuafuai/DevOpsGPT`, an open-source project with roughly 6,000 stars. The commit embedded an XMRig 6.21.0 Monero miner into the project's Docker image, disguised as a routine worker process and set to run on a 45-second restart loop. The mining configuration was XOR-encrypted with the key `devops2024`, and the wallet pointed to `pool.supportxmr.com`.

The same compromised account was then used on September 15 to push the GhostAction workflow to four DevOpsGPT repositories. Whether the miner and the credential-theft campaign share the same operators remains unclear. The miner commit used a forged author email never seen on that account before, was crafted specifically for that project, and left no trace in any other repository, while GhostAction's payloads are generic and hit hundreds of repos within hours.


One Compromised Account, Multiple Attackers

Cross-referencing GhostAction victims against other malicious GitHub activity turned up 13 victim repositories that had also been exploited for cryptomining by at least four separate campaigns with distinct wallets, pools, and infrastructure. In some cases the miners arrived before the GhostAction workflow; in others they followed months later.

The most likely explanation is that the credentials GhostAction used were not exclusive to its operators. Stolen developer tokens circulate through infostealer logs and credential markets, where multiple actors can buy and reuse the same access independently.

That creates a specific gap in the standard remediation advice. Rotating the secrets stolen through the malicious workflow is necessary, but it is not enough. The underlying GitHub credential that allowed the injection in the first place also needs to be found and revoked, or whoever holds that token next will use it.

The campaign continued into October. On October 8, a new burst hit 346 repositories in two automated sweeps lasting only minutes. Two compromised maintainer accounts pushed the workflow to every repository they could write to, including kitao/pyxel, a Python retro game engine with over 18,400 stars, and uber/athenadriver. The exfiltration endpoint remained `193.32.204.199`. Unlike most of the September wave, which was blocked pending approval, these runs executed and exfiltration was confirmed. This variant also goes further than its predecessor: rather than targeting only named GitHub Actions secrets, it combs the full git commit history for cloud credentials, including AWS keys, GitHub and GitLab tokens, and API keys for services like OpenAI and Anthropic.


Read more »
utility companies
Alabama Cyberattack Data Breach energy systems Georgia utility companies

Southern Company Discloses Data Breach Affecting 400,000 Georgia Power and Alabama Power Customers

 



Southern Company, the Atlanta-based energy holding giant, has confirmed that an unauthorized third party broke into its online customer portal and accessed account information belonging to roughly 400,000 customers across its electric subsidiaries, Georgia Power, Alabama Power, and Mississippi Power.

The company publicly disclosed the breach on October 5, 2026, stating that the intrusion, which occurred in September, was detected through its own monitoring systems. Upon discovery, Southern Company said it moved quickly to shut down the unauthorized access and notified law enforcement.

"Southern Company recently detected suspicious activity involving our online customer portal," the company said in a statement. "An unauthorized third party accessed certain, limited information about the accounts of approximately 400K customers. Upon detection, we took immediate steps to stop the activity and have engaged law enforcement."

Of the roughly 400,000 accounts compromised, approximately 300,000 belong to Georgia Power customers. Alabama Power accounts for the remaining 100,000, which represents about 6% of its 1.6 million-customer base. Mississippi Power was named in the company's public notice as affected, but Southern Company has not released a customer count for that subsidiary.

According to the company's published incident notice, the data the attacker accessed includes customers' names, mailing addresses, phone numbers, email addresses, and the last four digits of their Social Security numbers, along with other unspecified basic account details. The company was clear about what was not taken: bank account numbers, payment card numbers, and driver's license numbers were not part of what the attacker pulled from the portal.

The online portal in question is the same platform customers use to pay bills and manage their accounts.

Despite the company's confirmation that it caught and stopped the intrusion, Southern Company has not said when exactly in September the breach occurred, nor has it explained how the attacker got past the portal's defenses in the first place. That absence of technical detail leaves open questions about the attack method, whether it involved stolen credentials, a software vulnerability, or some other approach.

Customers whose information was involved are being notified directly by both mail and email. Southern Company is also offering each affected customer one year of free credit monitoring through Equifax. Those with additional questions were directed to a dedicated assistance line at 1-800-900-6021, available Monday through Friday.

Southern Company, incorporated in 1945 and headquartered in Atlanta, is one of the largest energy holding companies in the United States. It supplies electricity through its subsidiaries to customers across three states and operates natural gas distribution businesses in four more. Its total customer base numbers over 9 million.

The incident sits alongside a string of recent cyberattacks targeting utility companies in North America and beyond. Just weeks earlier, in September 2026, Houston-based CenterPoint Energy disclosed that an unauthorized third party had obtained personal information on a portion of its customers through one of the company's external-facing systems. That disclosure came after a threat actor claimed on a cybercrime forum to have extracted 7.49 million customer records from the utility and ultimately leaked the data after the company failed to respond. In March 2025, Nova Scotia Power, Canada's largest electric utility in that province, suffered a cyberattack that disrupted its customer support line and web portal.

Research published by cybersecurity firm Trustwave in 2025 found that roughly 67% of credential access techniques used against energy and utilities companies involved brute force methods, which are largely automated attacks that cycle through large lists of usernames and passwords. That tactic, known as credential stuffing when it draws on passwords stolen from previous breaches on other platforms, has been used against utility customer portals before. In 2021, UK energy supplier Npower had to shut down its mobile app entirely after attackers used stolen credentials from other websites to access thousands of customer accounts.

The energy sector's digital attack surface has expanded considerably as utilities push more customer services online. Customers log into portals to check bills, set up autopay, and track usage, all of which requires storing personal data behind web-based logins. Security researchers have long pointed out that these portals often receive less security investment than back-end operational systems, even though they handle data that is directly useful for phishing, identity fraud, and social engineering.

Southern Company said it has found no evidence of ongoing unauthorized access following the breach, and noted that it continues to monitor its systems around the clock. The company's public notice also cautioned customers to be alert for fraudulent contact from individuals claiming to be Georgia Power or Alabama Power representatives, reminding them that neither utility will ever threaten immediate service disconnection or demand payment over the phone.

Anyone who believes they may have been affected and has not yet received notification from the company can contact Georgia Power customer service directly through the number listed on their bill.



Read more »
data security
AI Attacks AI cybersecurity AI technology Cyersecurity AI Data Data Breach Data protection data security

South Korea Orders Financial Sector Probe After Series of Data Breaches

 

South Korea is gearing up to respond to a string of cyber disruptions that targeted financial institutions, with the President demanding a thorough inquiry about the recent personal data breaches and protection of future incidents.  

The Financial Services Commission (FSC) is leading the response and is holding meetings with industry bodies, regulators, and officials from impacted financial institutions to discuss the next steps. FSC Chairman Lee Eog-weon warned that finance companies must remain on high alert as the authorities trace the source of the cyberattack. The security breach investigation was initiated after Shinhan Bank notified the FSC about the incident on September 30. 

Following that, regulators opened on-site inspections and expanded the probe as more financial institutions reported a cyberattack. Shinhan Bank and KB Kookmin Bank were the two financial firms named by the FSC, while Yonhap News Agency reported that Hana Bank and Woori Bank also experienced data leaks. FSC decided to call an emergency meeting of senior officials to review the situation, moving it from its original date, October 7. 

According to Korean media, the main reason for the emergency meeting was related to the fact that more financial institutions became victims of cyberattacks, and that additional breaches at secondary financial institutions were also suspected. Regulators are also considering the possibility that AI might be involved in the cyberattack. Lee warned that the involvement of AI in the cyberattack cannot be ruled out and that the response should be based on AI-driven cybersecurity solutions. 

In addition, the FSC is considering implementing enhanced cybersecurity measures for the finance sector. Among the first steps taken by the FSC is a recommendation that financial institutions conduct a cyber hygiene review. FSC urged finance companies to implement stricter access controls, reduce the exposure of their systems, and introduce additional measures to protect consumers from potential data abuse. Furthermore, the FSC is pressuring financial institutions to share information about the cyber incidents. 

The information exchange process should include attack methods, internet protocol (IP) addresses, and other details. It would enable financial companies to develop a joint response and recognize other potentially impacted entities. The cyberattack might have been targeting financial hubs rather than the single institution, according to one scenario produced by South Korean regulators and reported by Yonhap. The unnamed regulators believe that the cyber attackers targeted several financial institutions in an attempt to scan the system to find weaker areas.  

According to the information provided by the banks to the National Assembly, the cyberattack came from various IP addresses. Those locations spanned across several countries, including the US, Japan, Singapore, Vietnam, and the UK. South Korea’s opposition People Power Party is demanding that the government investigate whether North Korea was behind the cyberattack. 

The cyberattack could be a retaliation for decades of cyber espionage and economic sabotage by Pyongyang, according to the party. The response from the FSC is to keep investigating the cyber incidents and urge financial institutions to boost their cybersecurity measures and share information about the cyber incidents.
Read more »
User Privacy
CPR registry Data Breach Denmark Identity Theft User Privacy

Denmark Population Registry Breach Exposes 8.8 Million Citizens

 

Denmark is grappling with one of the most significant data breaches in its history after unauthorized actors gained access to the Central Population Register (CPR), exposing the personal information of approximately 8.8 million individuals. The breach, discovered in early October 2026, affects not only current residents but also includes data on people who have moved abroad and even deceased individuals. The CPR serves as Denmark's national civil registry and contains highly sensitive information including names, addresses, dates of birth, marital status, and unique CPR identification numbers that are integral to daily life in the Scandinavian nation. 

The attack was carried out through a sophisticated method involving a private Danish company that had legitimate access to the registry system. According to authorities, threat actors misused this company's credentials to extract data from the CPR database. The Danish Data Protection Agency revealed that the attackers employed brute-force techniques to enumerate valid CPR numbers before systematically extracting associated personal data from each entry. This method allowed them to harvest information on a massive scale, impacting roughly 80% of the 11 million registered citizens currently in the CPR system, making it one of the largest population registry breaches ever recorded in Europe. 

Security officials detected the breach on October 2, 2026, though the actual incident occurred earlier in September. Once the CPR administration became aware of the compromise, they immediately blocked the private company's access to the registry and launched a comprehensive investigation with police assistance. Minister for Research, Education and Digitalization Christina Egelund described the incident as extremely serious and promptly informed Parliament's Business and Digitalization Committee. The government has since implemented additional security measures to prevent similar incidents and is working with all relevant authorities to establish the full extent of the damage caused by this unprecedented security failure.

In response to the breach, Danish authorities have established a dedicated cyber hotline to assist potentially affected individuals and provide guidance through the website sikkerdigital.dk. Officials are urgently warning citizens to remain vigilant against unsolicited communications, emphasizing that criminals may use the stolen data to craft convincing phishing attempts. The government specifically cautioned that people should never disclose passwords or confidential information in response to telephone calls, emails, or similar communications, even if the caller appears to know their name, address, and CPR number. This warning is particularly critical because the exposed data could enable highly targeted social engineering attacks that would be difficult for ordinary citizens to identify as fraudulent. 

The Denmark CPR breach represents a stark reminder of the vulnerabilities inherent in centralized population databases and the catastrophic consequences when such systems are compromised. As investigations continue, questions remain about how the private company's credentials were obtained and whether additional security lapses contributed to the scale of the breach. For millions of Danes, the incident means living with heightened risk of identity theft, financial fraud, and privacy violations for years to come. The breach also raises broader concerns about data protection practices across Europe and may prompt other nations to reassess the security of their own civil registry systems in an increasingly dangerous digital landscape where personal information has become a valuable commodity for cybercriminals worldwide.
Read more »
npm
API Keys Credentials Data Breach Gemini GitHub Access Token GitHub repositories breach npm

Half a Million GitHub Credentials Are Still Active, Most Have Been Sitting in the Open for Years





Researchers at Truffle Security tested 543,699 API keys, database passwords, and access tokens found in public GitHub repositories last July. Every single one authenticated. The median credential had been sitting in publicly readable code for 784 days.

The findings come from a scan of The Stack v3, a 224-million-repository snapshot of public GitHub code assembled to train large language models. The crawl closed on August 7, 2025. Eleven months later, when Truffle Security ran live verification against each issuing provider, more than half a million credentials still worked. That number is more than double the 221,303 live credentials the company found when it ran a similar scan against 7.6 petabytes of Hugging Face training data earlier this year.

The oldest credential in the dataset was last touched on June 13, 2009. It lives inside an Erlang web server configuration file, and it was still valid 16.1 years after it was committed. Behind it: an FTP login inside a GPS logger's C source code from September 2009, replicated across 62 repositories, and an AWS key tucked inside a Rails S3 config from November of that same year. Truffle Security declined to name the repositories because the credentials in them still work.


A Protection That Only Faces Forward

GitHub has progressively tightened its defenses around exposed credentials. The platform made secret scanning alerts free for all public repositories in February 2023. Push protection, which blocks a commit before it reaches the remote branch if it carries a recognised secret, became generally available in May 2023 and was switched on by default for all public repositories on February 29, 2024.

GitHub's secret scanning covers more than 200 token types and patterns from over 180 service providers. The rollout had a measurable effect on new leaks. Among credential shapes the system recognises and blocks, Truffle Security found a 53 percent drop in the rate of fresh exposures across the twelve months following the default rollout, compared to the twelve months before it. Slack tokens fell 64 percent, GitHub's own tokens and AWS access keys each fell 59 percent.

But push protection has no mechanism to reach the credentials already there. Of the 543,699 live credentials, 199,843 landed after push protection became the default in February 2024. Developers either bypassed the block or committed credential types the system does not recognise.

That second category is the larger problem. Truffle Security found that 51.8 percent of every live credential in the dataset is a shape that a default-configured public repository will accept without objection. Database connection strings, private keys, and Google API keys all fall outside the default block list. Push protection focuses on specific, highly identifiable secrets and misses generic ones. Connection strings and private keys are classified as generic patterns, and blocking them requires an organisation to go into settings and explicitly opt in.


The Gemini Problem

The Google API key situation illustrates the limits of pattern-based blocking in particularly sharp terms. The 33,343 live Google API keys in Truffle Security's dataset include 31,374 that authenticate specifically to Gemini, Google's AI model platform. Their median leak date is February 2025, meaning the entire population is younger than the push protection rollout.

Google API keys carry the prefix `AIzaSy` whether they were created for Google Maps, Firebase, or Gemini. GitHub's pattern list recognises the prefix but marks it as not push-protected, because a Maps key sitting in client-side JavaScript is not a secret by design. Google's own approach to API keys was historically built around the assumption that these keys would live in client-side code, exposed to anyone who opened a browser's developer tools. The problem is that Gemini runs on the same key format, turning what developers were trained to treat as a non-sensitive identifier into a billable AI credential. One pattern cannot distinguish between the two uses, so nothing gets blocked, and the keys that matter arrive alongside the keys that do not.


Revocation is the Deciding Variable

The most instructive comparison in the data is between providers that automatically revoke leaked tokens and those that do not.

npm committed 101,886 tokens to public code. One remains live. GitHub committed 73,048 tokens; 260 survived. Hugging Face committed 30,437; 15 are still valid. Each of these platforms runs an automated pipeline that kills a token the moment it is detected in public code.

The contrast with database credentials is stark. Of 12,985 Postgres connection strings in the dataset, 11,465 are still live, an 88 percent survival rate. MySQL connection strings survive at 75 percent. MongoDB, where the detector only reports a URI it successfully connected to, returned all 51,067 live.

Push protection blocks secrets at the door. Automated revocation kills them wherever they are. The Truffle Security data shows that the second mechanism is the one that changes the outcome, and for the majority of credential types sitting in public repositories right now, no provider is running it.

The practical guidance from the researchers: treat any committed credential as compromised regardless of whether anything flagged it, scan your own repository history rather than assuming the push-time block was sufficient, and favour credentials that expire automatically. Most of what Truffle Security found would have been harmless long ago if it had ever been given a finite lifetime.


Read more »
healthcare data breach
customer data breach cybersecurity in healthcare Data Breach Data Leak data security Healthcare Data healthcare data breach

DC Health Agency Data Exposure Affects Nearly 400,000 Medicaid Beneficiaries

 

Almost 400,000 people who enrolled in Medicaid and the DC Healthcare Alliance may have been affected by a data breach, which occurred on the website of the District of Columbia Department of Health Care Finance. 

The issue concerned the reports published on the organization’s website, which showed aggregated data about the people who enrolled in the programs between 2023 and 2026. DHCF noted that the breach did not involve cybersecurity issues or intentional unauthorized access to the system. The problem was discovered by the agency in July, when it was revealed that two reports on the website contained fields with personally identifiable information that could have been accessed by unauthorized parties. 

The reports included only aggregated data, such as the number of people enrolled in the programs at specific times and other related information. Nevertheless, according to DHCF, the supporting information on its website could have been accessed by unauthorized parties since 2023. The personally identifiable information of the people who enrolled in Medicaid and the DC Healthcare Alliance includes their ID, providers, date of birth, race, gender, ethnicity, and wards. 

According to the agency, the reports do not contain Social Security numbers, names, and financial information of the affected people. DHCF announced that 399,086 people were affected by the issue and notified the United States Department of Health and Human Services (HHS). The latter added DHCF to its website, which keeps track of data breaches. It is unclear whether the affected people’s information was misused or will be misused in the future. Nevertheless, DHCF advised them to remain wary of potential fraudulent activities and unauthorized attempts to gain access to their information. 

According to the agency, the fact that the reports did not include Social Security numbers and financial accounts minimizes the risk of exploitation, but it remains present due to the inclusion of people’s IDs. After the breach was discovered, DHCF removed the reports from its website. In addition, it initiated an internal review process and responded to the problem by checking its systems for vulnerabilities and ensuring that its internal procedures were appropriate for addressing the issue. 

It is important to note that the breach illustrates how people’s information can be exposed even when it should not be. In this case, the data was not hacked or intentionally shared with unauthorized parties. Nevertheless, it became available to anyone who wanted to see it because the reports containing it were publicly available. 

Therefore, it is essential for people who enrolled in Medicaid and the DC Healthcare Alliance to ensure that they are not contacted by scammers and that their information is not misused. It is necessary for them to contact DHCF if they suspect that something is wrong. At the same time, it is important to keep in mind that, according to the agency, there is no information about the affected people’s information being viewed or misused.
Read more »
Subscribe to: Posts (Atom)