Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Data Breach. Show all posts

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.

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.

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.


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.



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.

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.

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.


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.

Hacking and Extortion Operation Targeting U.S. Official Ends in Conviction


A former U.S. Army soldier, Cameron John Wagenius, has been sentenced to 70 months in prison for participating in a hacking and extortion campaign which exposed sensitive information and targeted telecommunication companies. According to the U.S. Department of Justice, Wagenius has also been ordered to pay $294,978 in restitution. Wagenius was involved in the cybercrime operation while serving as an active duty military member. 

In April 2023 and December 2024, he and other conspirators obtained credentials allowing them to access protected networks belonging to at least ten organizations. The stolen information was then used to extort victims by threatening publication or sale of the data without their payment.

Investigators have stated Wagenius was an online hacker known as “kiberphant0m” and he contributed to the development of the hacking tool SSH Brute, which was used to obtain login credentials. To exchange stolen credentials and coordinate access to victim networks, the group communicated via Telegram. Additionally, public threats were made on cybercrime forums.

Stolen information was made available for sale on platforms including BreachForums and Wagenius published two posts in November 2024 that contained stolen non-content call detail records associated with a former US government official and relatives of another former official. As part of the threats, the Justice Department also stated that additional confidential records would be released if a ransom was paid.

One of the posts indicated that the activity may be partly motivated by retaliation for the arrest of another cybercriminal. There have been several attacks involving major telecommunications companies and other companies. According to cybersecurity researchers, Wagenius' possession of data was related to broader attacks targeting Snowflake customer environments. Several companies were affected by the campaign, including AT&T, Ticketmaster, Advance Auto Parts, and Santander. 

Wagenius pleaded guilty in separate proceedings filed in the Western District of Washington in support of the charges. A conviction for wire fraud, extortion using computers, and aggravated identity theft was obtained in July 2025. Prior to this, he had pleaded guilty to two counts of unlawfully transferring confidential phone records related to the same operation in March 2025. Additionally, Wagenius appears to be tied to the wave of attacks against organizations using Snowflake cloud environments that took place in 2024. 

According to AT&T, attackers accessed call and text records covering nearly all of its mobile customers in December 2022. The stolen information was later associated with extortion activity involving several cyber criminals. Moreover, court records and the investigation report indicate that Wagenius attempted to sell stolen information to an email address he believed was affiliated with a foreign military intelligence service. Moreover, the prosecution alleges that he searched the Internet for information about leaving the United States for Russia. 

The intelligence services involved have not yet been publicly identified by the government. Based on the findings of the investigation, the hacking operation was primarily a result of the use of stolen credentials, rather than an exploit of a specific software vulnerability. The credentials were used by Wagenius and his associates to gain access to company networks and cloud environments, using Telegram to communicate access details and coordinate further intrusions. 

After invading victim networks, the group aimed at obtaining data to be monetized. In some cases, information was provided to other criminals, whereas other records were used for fraud schemes, such as SIM swapping. Additionally, extortion demands were extorted through private communications as well as public postings on cybercrime forums. 

The FBI, Defense Criminal Investigative Service, and other law enforcement agencies investigated these activities. A warrant was issued for Wagenius' arrest in December 2024, bringing to a close the hacking activities he allegedly conducted for more than a year while remaining an active duty soldier.

Cloudflare Patches Cross-Tenant Container Flaw That Let Tenants Read Each Other's Leftover Disk Data

 




Cloudflare has patched a vulnerability in its Containers product that could have allowed a paying customer to pull residual data out of disk storage blocks previously used by a different tenant. The company disclosed the issue on September 24, three weeks after security researcher Oren Yomtov from the firm Accomplish filed a report through Cloudflare's HackerOne bug bounty program.

The flaw was rooted in how Cloudflare configured the Linux storage subsystem underpinning its container infrastructure. Cloudflare Containers run each workload inside a dedicated virtual machine powered by the Firecracker virtual machine monitor. Each VM gets a writable root disk backed by Linux device mapper thin provisioning, known as dm-thin, a storage technology that allocates physical disk space on demand rather than upfront. When a container's thin volume was deleted, the physical 64 KiB blocks it had occupied were handed back to a shared pool that served workloads from multiple customer accounts.

The problem was a single configuration option: `skip_block_zeroing`. With this flag set, dm-thin does not wipe a block before reassigning it. That is a performance trade-off operators sometimes make deliberately, but in a multi-tenant environment the consequences were significant. A freshly assigned block would carry the previous tenant's data intact unless the incoming workload happened to overwrite every byte of it.

Yomtov and his team worked out a way to exploit this behavior without needing any privileged access. A tenant with a standard Workers Paid account could open their container's raw root disk at `/dev/vdc` and identify regions that the guest ext4 filesystem had marked as free space. Writing a small 4 KiB block into a 64 KiB-aligned free region would force dm-thin to pull a physical block from the shared pool. Because zeroing was disabled, only the 4 KiB the attacker wrote got replaced. The remaining 60 KiB stayed exactly as the previous owner had left it. A subsequent raw-device read could then pull those bytes out.

What the researchers found across production runs was striking in scope. They tested the technique across 24 placements and found residual data on 18 of them, across 20 of 22 underlying nodes and spanning four continents. The recovered material included directory structures, database pages, and structurally complete SQLite databases. Using ext4's `metadata_csum` checksum feature, the team was able to confirm that recovered directory blocks did not originate from their own test filesystem. Across six placements they identified 2,700 distinct foreign directory inodes. All proof-of-concept materials submitted to Cloudflare were scrubbed of third-party identifiers and content values, and the researchers confirmed they securely deleted the recovered data after submission.

The vulnerability carried real limits. An attacker could not pick a target. Which blocks dm-thin reassigned to a new container depended entirely on Cloudflare's workload scheduler, so exploitation was opportunistic rather than directed. The technique also could not touch any actively mounted disk or modify another tenant's live data.

Cloudflare moved fast. Yomtov filed the report on September 4 at 15:26 UTC. The engineering team opened a security incident and confirmed the production setup behind the flaw within about three hours. A runtime fix was merged by 21:27 UTC the same day. Rolling out the change across the fleet began by 23:15 UTC. But removing `skip_block_zeroing` only stops future misallocation. Blocks already mapped into running containers or cached in pre-built snapshot layers were unaffected. To clean those up, Cloudflare drained hosts during off-peak hours, restarted their VMs, and wiped each host's image cache so every disk would be rebuilt using zeroed allocations. That final cleanup finished on September 19. The researchers confirmed their proof of concept stopped working on September 14.

Cloudflare said it reviewed all available historical disk I/O telemetry and found no activity consistent with the exploit technique other than what came from the researchers and from Cloudflare engineers during authorized validation. No customer-side action is needed.

The disclosure adds to a recent pattern in cloud infrastructure research. Yomtov's team at Accomplish has a track record of finding platform-level flaws; they also reported a sandbox escape in Anthropic's Cowork tool this year. In the wider cloud industry, Wiz researchers disclosed a separate cross-tenant issue in Microsoft Azure Cosmos DB this year, called CosmosEscape, which could have let attackers escalate from a crafted Gremlin query to retrieving primary account keys for other customers' databases. Microsoft said it found no evidence of customer impact in that case either.

Cloudflare co-authored its disclosure with Yomtov and the Accomplish research team, a relatively transparent move for a company of its size. The company's bug bounty sits on HackerOne and remains open for further researcher submissions.


Astrana Health Data Breach Exposes Private and Confidential Information


In a cybersecurity incident, Astrana Health disclosed, attackers gained access to company servers and obtained confidential and private information. A social engineering attack targeting employees was conducted by the healthcare technology company's subsidiary, Astrana Health Management, to accomplish the intrusion. 

Astrana Health employees were impersonated in the attack and the main corporate telephone number of the company was spoofed by the attackers, according to a filing with the Securities and Exchange Commission. Employees were contacted using the fraudulent number, and eventually the attacker obtained access to the company's servers through the fraudulent number. Because of the potentially sensitive nature of the information involved, the incident was later determined to be material. 

In its investigation, Astrana Health discovered that some private and confidential information stored on its servers had been accessed or acquired without authorization. As of this writing, the company is still investigating the incident in order to determine whether patient, employee, credentialed provider, business, financial, and intellectual property information was affected. There has been no disclosure of the specific information compromised or the number of individuals affected. 

After detecting the intrusion, Astrana Health consulted with a third-party cybersecurity firm, notified law enforcement and regulatory authorities, and informed partners and customers of the incident. As part of the mitigation, credentials have been rotated, remote access tools have been restricted, certain systems were restored from backups, and monitoring, logging, and detection measures have been strengthened. The extent of the exposure has not yet been identified. 

Currently, Astrana Health is investigating whether patient data, employee data, credentialed provider data, confidential business or financial records, and intellectual property were involved. There has been no disclosure of the number of individuals affected or a specific list of the data accessed and taken by the company. As a result of the potentially sensitive nature of the information involved, this incident has been classified as material. In the meantime, Astrana Health does not anticipate the attack will significantly affect its financial position or operations. 

During the investigation, the company has also notified law enforcement, regulators, and relevant customers. There has been no public attribution for the attack. There are no known ransomware or extortion groups that claim responsibility for the attacks at the time of the reports. In addition, Astrana Health has not confirmed the presence of ransomware. 

Due to the wide range of information stored within Astrana Health's systems, the incident is of particular significance as it affects healthcare providers that provide technology and administrative services. As of the last quarter, the company reported revenue of approximately $972.5 million and provides its operations technology platform to approximately 20,000 medical practitioners. 

A preliminary investigation by Astrana Health is ongoing, with the company seeking to determine the full extent of the information accessed as a result of the cyberattack. Further findings may clarify the type of data involved and the number of individuals affected by the cyberattack.

BigCommerce Merchants Hit in Supply Chain Breach After Ribon App Credentials Were Stolen

 



BigCommerce has started alerting merchants that customer data was stolen from their stores after attackers got hold of API credentials belonging to Ribon, a third-party storefront optimization app used by retailers across the platform.

The stolen credentials gave attackers access to customer records inside merchant accounts on BigCommerce between September 13 and September 17. For those four days, they pulled data page by page until the compromised key was revoked. Names, email addresses, phone numbers, and shipping addresses were taken. Passwords and payment card details were not, because BigCommerce stores that information in a separate system.

The breach did not originate inside BigCommerce. It traced back to a system compromise at Fastr, the parent company of Be A Part Of, the firm that develops and operates Ribon and its updated version, Ribon 1.5. Fastr's internal compromise exposed the API credentials those apps held, and attackers used them to walk directly into merchant environments without triggering any alarm at BigCommerce's own infrastructure level.

"On September 17, 2026, Commerce confirmed that API credentials belonging to third-party applications Ribon and Ribon 1.5, owned and operated by 'Be A Part Of,' a Fastr company, had been compromised due to a Fastr system compromise," BigCommerce told SecurityWeek. "This was not a breach of Commerce systems or the BigCommerce platform."

Ribon's own developers noticed the key was being misused on September 16. The access was cut on September 17, and BigCommerce uninstalled the app from all affected stores the same day. Merchants started receiving notifications from BigCommerce on September 18. In some stores, attackers also injected malicious scripts, though BigCommerce has only said this affected a small number of storefronts and has not specified what those scripts were designed to execute.

UK spirits retailer Master of Malt confirmed publicly it was among the merchants notified. In a statement on its website, the company said the attacker accessed its customer database and described what happened in plain terms. "It looks like hackers were able to compromise a BigCommerce Application key held by Ribon, which they were able to use to gain access to customer data held on their system." Master of Malt has reported the incident to the UK Information Commissioner's Office and said the impact may extend to hundreds of other retailers that had Ribon installed on their stores.

That point matters. This was not a breach contained to one retailer or to one retailer's mistakes. Every merchant that had Ribon connected to its BigCommerce store shared the same exposure risk, because every one of them relied on the same third-party credentials that Fastr failed to protect. The total number of affected merchants has not been disclosed. Fastr and Be A Part Of have not issued any public statement. Neither company had responded to media requests for comment as of the time of reporting.

BigCommerce hosts over 1,200 third-party apps and integrations. It told BleepingComputer it is providing log data to support Fastr's investigation. Seattle-based law firm Emery Reddy is already seeking potential claimants, noting that several retailers have begun sending breach notifications to their customers. The firm confirmed the exposed information matches what Master of Malt reported: names, email addresses, phone numbers, and physical addresses.

This incident is not the first time BigCommerce has had to yank a third-party app after attackers used it to reach merchant customers. In late 2024, electronics accessories maker ZAGG disclosed that unknown actors had breached FreshClick, another third-party BigCommerce integration, and injected payment-skimming code into its checkout. That attack ran from October 26 through November 7, 2024, and resulted in the theft of names, addresses, and live payment card data from customers completing transactions on ZAGG's site.

The two incidents differ in method. The FreshClick attack used malicious JavaScript to capture card details at the point of entry, in real time, as customers typed. The Ribon attack used a compromised backend key to query stored customer records directly, without any customer interaction required. No payment data changed hands this time, but the attacker had persistent, authenticated access to customer databases for four consecutive days before anyone pulled the key.

For shoppers at any retailer that used Ribon, names, email addresses, phone numbers, and home addresses are now in someone else's hands. That combination is more than enough to build convincing phishing messages or to attempt account takeover on other services where those same details appear. Affected customers should treat any unsolicited emails referencing their account details or recent orders with skepticism until the full scope of the incident is established.


Chinese Hackers Exploit ZyXEL Switch Flaw to Steal Data From Nearly 1,000 Devices

 

A Chinese threat actor has been using the recently discovered vulnerability in ZyXEL GS1900 switches to steal crucial information from the devices around the world, according to GreyNoise, a threat intelligence company.

The vulnerability, tracked as CVE-2026-7273, has a CVSS score of 8.8 and is a stack-based buffer overflow, enabling a remote unauthenticated attacker to execute OS commands via a specially crafted HTTP request. 

ZyXEL has issued security updates for ten GS1900 switch models in June. However, according to GreyNoise, the flaw was actively exploited in August, targeting the devices in 48 countries. The threat actors used a Python script, which was significantly obfuscated to hide its purpose, to extract the hashes of the root credentials, configuration, and network information from 996 affected switches. 

While the script targeted the GS1900-24 switches with firmware versions 2.10 to 2.90, some of the command-line options in the script contained values related to libc base addresses and global offsets. Therefore, it might be possible that the threat actors could use the same vulnerability to target other firmware versions. The information stolen from the switches also showed that 564 devices were using default credentials. This lets the attackers effortlessly compromise these devices. 

On Monday, the US Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities catalog. Also, per the Binding Operational Directive 26-04, all federal agencies must remediate this issue within 3 days of its publication. GreyNoise also reported that the same threat actor conducted Ubiquiti attacks, which involved exploiting the zero-day flaws to gain remote access and execute arbitrary code in the devices. 

In addition, the attackers used exploits targeting WordPress flaws to launch attacks against small businesses and government entities in July. The attacks entailed a threat actor compromising a Western government organization, stealing over 18000 sensitive documents from the agency’s backend database, and publishing the results on a Matrix communication service. 

However, the cybersecurity firm is yet to confirm if any of these attacks were conducted by the same threat actor. Acronis, another cybersecurity firm, previously identified threat actors using the Red Heron hacking group, which primarily used Gitea’s zero-day flaw to target more than 100 organizations worldwide.

Gyazo Server Vulnerability Targeted to Steal Millions of User Records


Gyazo, an image-sharing platform, has confirmed a breach after attackers exploited a vulnerability in its upload server, gaining unauthorized access to the company's systems and approximately 23.62 million user records. 

Gyazo was developed by Japanese software company Helpfeel and allows users to upload images, GIFs, short videos and generate links for sharing. There are over 23 million users on the platform from 242 countries and regions, and billions of uploads have been processed. According to Helpfeel, the intrusion occurred on September 11, when a third party exploited a vulnerability in Gyazo's image upload server and became able to execute commands on the system as a result. 

On the same day, the company was notified of suspicious activity and began to investigate the incident. In the early hours of September 12, Helpfeel had blocked the access routes used for the attack and terminated any unauthorized connections. As part of the initial response, the exploited vulnerability was also fixed. However, an investigation revealed that the attacker was already able to access Gyazo's database and obtain user-related information. There are approximately 23.62 million records in the affected dataset. 

Depending on the account, information that will be exposed may include name or nickname, email address, password hashes, user and device IDs, login session IDs, profile information, subscription details, billing status and usage statistics. Additional information may be exposed if an account is linked to an external service. 

According to Helpfeel, integration tokens for accounts connected to X may be included, while Google SSO email addresses may also be included for users who signed in through Google. In a statement issued by the company, it clarified that payment information, including credit card numbers, was not exposed. 

The affected records also include anonymous accounts without registered email addresses, therefore it is not yet known how many people will be affected. The incident involved not only account information, but also a much larger collection of image-related metadata. According to Helpfeel, approximately 490 million metadata records were disclosed, primarily those associated with images uploaded before January 2019. It is possible for an image ID to be exposed, as well as IP addresses and User Agent details, EXIF location information, OCR-extracted text, image titles, and source URLs. 

A separate privacy concern arises from the image metadata, as Gyazo uses image IDs to generate URLs for uploaded captures. According to Helpfeel, the stolen IDs may allow access to some images, so the company temporarily disabled access to affected files while investigating. As a result, approximately 490 million images have been compromised, most of which were uploaded in January 2019 or earlier. 

Information may include image IDs, IP addresses, User-Agent strings, EXIF location information, OCR-extracted text, title of the image, and URL of the source. Besides the data exposed, Helpfeel also identified a separate set of approximately 2.4 million image records which were retrieved according to specific filtering criteria, including hacked passphrases associated with private images. This company has not provided information on the criteria used or clarified whether the records overlap with the larger metadata set. Also exposed in the incident was a list of private images. 

Helpfeel did not exclude the possibility that private pictures were viewed by the attacker. The number of private images accessed has not been determined by the company. Because Gyazo handles image privacy in a very sensitive manner, the disclosure of image IDs is particularly significant. The URL of each capture includes a 32-character ID, and older captures can still be accessed through their original URLs even after they are not prominently displayed within a user's account. 

The leaked identifiers therefore could be used to gain access to content that was not intended to be viewed by the general public. By the early hours of September 12, Helpfeel detected suspicious activity and blocked the identified access routes, terminating the attacker's connections. The exploited server vulnerability was immediately addressed. 

In September 14, the company confirmed the data exposure and reported the incident to the Japanese Personal Information Protection Commission. During the course of the investigation, Gyazo temporarily suspended image delivery. A forensic investigation is currently underway by Helpfeel, and affected users will be contacted directly. 

Anonymous accounts will be handled by Gyazo through notifications posted on the website. Despite finding no evidence of the deletion of image data during the incident, the company has not identified a data leak involving its separate Helpfeel and Cosense services. Users have been advised to change their Gyazo passwords and avoid reusing the same credentials on other services in light of the exposed authentication data. 

Helpfeel has also taken action to invalidate or restrict the affected credentials and authentication information. Furthermore, the company has cautioned against the possibility of exploitation of information disclosed in the breach through suspicious emails and messages.

Spanish Data Watchdog Publicises First AI Agent-Linked Data Breach Report

Spain's data protection watchdog said it has received the first reported notification of a personal data breach allegedly carried out by an artificial intelligence agent, a case suggesting autonomous systems are beginning to play a direct role in cyberattacks. The Spanish Data Protection Agency (AEPD) said in a blog post Monday that the incident involved an AI agent using a widely known large language model to identify vulnerabilities, gain access to a system, and subsequently modify personal data and access invoices. 

The agency said the alleged breach was reported by the affected organization and remains under review. It clarified that the use of a particular AI model does not imply the model itself or its provider's infrastructure was compromised, nor that the technology was built for malicious purposes. AEPD did not immediately respond to a request for comment and did not identify the large language model or the targeted organization. 

According to AEPD, the case is significant because a third party allegedly used an AI agent to carry out multiple stages of an attack with limited human intervention, underscoring the growing role autonomous systems are playing in cybersecurity incidents. The notification submitted by the affected organization indicated that the agent successfully logged into the system, autonomously searched for application weaknesses, and after identifying a vulnerability, altered personal information and viewed billing records. 

The incident emerges as regulators and cybersecurity authorities across the United States and Europe intensify scrutiny of risks posed by increasingly capable AI systems, even as businesses continue adopting the technology at a rapid pace. Spain has positioned itself as one of Europe's most vocal advocates for a "trustworthy AI" model — one that prioritizes protecting privacy, democracy, minors, and public safety over speed or industry profit. 

While AEPD acknowledged that a single case is insufficient to establish a broader trend, it said the notification suggests AI-assisted attacks are moving beyond the theoretical stage and beginning to affect real-world processing of personal data. The watchdog did not indicate when it would complete its review of the reported breach. 

AEPD noted that AI does not create fundamentally new threats but increases the speed, scale, and adaptability of existing malicious techniques, thereby reducing the time available to detect and contain them. The agency added that data controllers, processors, and data protection officers must prepare for a scenario in which the speed of attacks will continue to accelerate.

Japan Digital Agency Data Breach Linked to VPN Vulnerability


Government Solution Service (GSS) of Japan's Digital Agency was compromised by a vulnerability in a VPN device, resulting in unauthorized access to the shared government platform through an exploit of a vulnerability in the VPN device. In this incident, 246,000 records containing information regarding employees, public officials, contractors, and other individuals connected to organizations using the service may have been exposed. 

Upon discovering unusually large-scale access to files on a server through an account belonging to a maintenance and operations staff member on June 25, the agency first detected the breach. Following an investigation, the agency determined that the account activity was linked to an unauthorized access to a network-connected VPN device. 

By July 9, the agency determined that an external party had accessed the system by exploiting a vulnerability in the VPN equipment. Immediately after the incident, the maintenance account was suspended, and communication between the equipment and external networks was restricted to prevent further access. 

The investigation, conducted with the assistance of an external security company, revealed that some files that contained personal information could have been transferred outside the system. The VPN product used and the specific vulnerability that was exploited have not been disclosed by the agency. Through shared IT infrastructure, 23 Japanese ministries and government agencies are served by the affected GSS environment, which can have a greater impact on the incident. 

The exposed information consists of approximately 236,000 names, 231,000 e-mail addresses, 94,000 telephone numbers, and 1,000 physical addresses. The records relate to personnel and officials who work with GSS user organizations, as well as businesses and individuals who support those organizations. 

Data containing information belonging to the general public was not included in the affected data, according to the agency. Additionally, the compromised dataset is lacking My Number identification numbers, bank account information, or pension number information. Despite the fact that no confirmed cases of misuse have been identified, the exposed contact information could still be used for impersonation, phishing, or other forms of social engineering. 

VPN exposures were categorized as medium severity and were not zero-day vulnerabilities; however, the agency has failed to provide details regarding when the vulnerability was fixed or why the device was still exposed at the time of the intrusion. 

Known VPN Flaw Left Unpatched

Due to the fact that the Digital Agency was already aware of a VPN flaw when the breach occurred, but had not applied the required patch, the incident raises concerns about vulnerability management. According to the agency, the vulnerability has a medium severity and has been confirmed as not a zero-day, indicating that attackers exploited a known vulnerability rather than a newly discovered vulnerability. 

The information accessed is approximately 246,000 records. Over 189,000 of these people are government employees, public officials, or other personnel working for GSS-related organizations, while approximately 57,000 are private companies and individuals involved in government-related activities. 

A total of 236,000 names, 231,000 emails, 94,000 telephone numbers, and 1,000 physical addresses were included in the data. In addition, duplicate entries may be present in the data. More sensitive identifiers are not included in the dataset, such as My Number information, bank account details, and pension information.

Investigation Finds No Confirmed Misuse

The Digital Agency has not received any confirmations of misuse of the exposed information, however, the combination of names and contact information could facilitate targeted phishing or impersonation attempts against affected employees. Messages or phone calls from individuals pretending to represent the government have been warned by the agency, and official personnel will not contact affected parties via email or telephone for passwords or payment information. 

Japan's Personal Information Protection Commission was made aware of this incident on July 15. During the investigation, the agency determined that potentially affected information was likely to be identified and the individuals and organizations involved required a considerable amount of time, which contributed to the delay in public disclosure. 

Digital Agency officials indicated the impact was limited to the affected GSS environment with no evidence of other government systems being compromised or disrupted. As part of its effort to strengthen vulnerability management and review how external connections to the system are handled, the agency is also expected to provide direct notifications to the affected individuals. 

To prevent unauthorized access to sensitive government information and limit unauthorized access, VPN patches should be implemented on time, strict access controls should be implemented, continuous monitoring should occur, and rapid isolation should be instituted.

South Korean Startup Suffers Breach Due to Encryption Management Failure


Modu-ui, a South Korean government backed startup support platform, suffered a data breach in July. The breach later disclosed a critical encoding key management compromise, showing how encoded information can still become vulnerable when enterprises can’t protect encoding keys properly. 

About Modu-ui

Modu-ui stores participants’ personal details such as email addresses, names, and startup ideas, and the platform also supports a nationwide startup audition overseen by SMEs and Startups (MSS) of the South Korean Ministry.

Suspicions were already raised a month prior to the reported data breach that applicants’ personal data could be structured and exposed via API responses inside the platform. The government said it had taken prompt action but did not reveal if it had upgraded Modu-ui’s security infrastructure.

Startup details leaked

In June, the Ministry of SMEs and Startups disclosed that summaries of startup ideas and personal details had been exposed. Later, it started a detailed enquiry along with National Police Agency, National Intelligence Service, and the Cyber Security Center.

In July, the agencies confirmed that the leak of encoding keys via an API was the reason for the startup idea and personal data leak.

About the breach

The exposed data had already been encoded but the encoded data needs an encoding key decoding.

In this case, the encoding key was leaked along with the API data, causing in the leak of evaluation comments, startup idea summaries and email addresses related to 5000 successful applicants. 

According to the Ministry, the encoding key had been included inside the API and a third party retrieved API data via methods like web crawling, causing the exposure of the key.

Private email addresses were not shown on the public-facing interface but officials believed they could be retrieved via AI-based web crawling. 

Impact on organizations

The incidents also demonstrate the dangers of hard-coding encoding keys as fixed values inside databases, application code, similar environments, or databases.

When businesses follow this method, the keys can become vulnerable in addition to the data or systems they are meant to protect. The main reason for this incident can be viewed as security infrastructure failure in incorporating  robust encoding key management.

Officials found 39 IP addresses related to the access of the exposed data coming from South Korea. Authorities also said that investigations led to more details such as potential connections to AI solution providers.

Florida Says Motor Vehicle Data Breach Tied to Credentials Stolen From Officer's Personal Device

 

Officials in Florida confirmed Thursday that the state Department of Motor Vehicles suffered a data breach after credentials were stolen from a police officer who had stored login information on a personal device. The ShinyHunters cybercriminal organization claimed on Monday that it had obtained access to data from the Florida Department of Highway Safety and Motor Vehicles (FLHSMV). 

The department did not respond to repeated requests for comment throughout the week but publicly confirmed the breach's legitimacy on Thursday night. Officials said they first learned of the breach on September 4 and initially attributed it to an unnamed "international cybercriminal organization." 

According to the department, an investigation determined that a criminal actor exploited a single Plant City Police Department user's credentials, which had been improperly stored on the employee's personal electronic device. Plant City is a small suburb outside Tampa. FLHSMV has since notified other Florida government offices and is partnering with the Florida Digital Service to investigate the incident. 

As proof of access, ShinyHunters shared alleged photos of a DMV record tied to American financier and convicted child sex offender Jeffrey Epstein. When claims of the breach first surfaced, some cybersecurity experts speculated it might be connected to the recently confirmed breach involving 153 million driver's licenses leaked by identity verification firm IDScan. ShinyHunters had previously attempted to purchase the ID database from the hackers behind the IDScan breach.

The group has recently claimed responsibility for attacks on bank IT provider Jack Henry, as well as pharmaceutical and healthcare technology company McKesson, which told regulators that data from its oncology and surgical business units had been stolen. ShinyHunters also caused widespread disruption across the U.S. in May with an attack on a widely used educational software suite and stole the information of more than four million people after targeting the world's largest medical device company in April. 

Other victims linked to the group include Carnival Cruises, Ticketmaster, AT&T, McGraw Hill, ADT, and gaming company Rockstar. In a related development, artificial intelligence company Anthropic released a report Thursday stating that suspected affiliates of ShinyHunters used AI to scan for credentials, map unfamiliar systems, and steal data from victims for extortion purposes. 

The report noted that in one case, an operator escalated from a stolen developer token to full administrative access over a victim's cloud environment in approximately three hours. Incident responders at Google also confirmed last week that members of the group are using Anthropic's AI tools at various stages of their attacks. 

The Florida breach adds to a growing list of incidents tied to ShinyHunters, underscoring the group's persistent targeting of both government systems and major corporations, as well as its evolving use of AI tools to accelerate and scale its intrusions.

Turner Discloses Data Breach Exposing Salary Info, Bank Accounts, and SSNs

 

Turner Construction has notified at least 6,098 people of a data breach that uncovered social security numbers, salaries, dates of birth and bank account information used for direct deposit, a filing with the California Office of Attorney General showed. The New York City-based firm found unauthorized access to its systems occurred between July 2 and July 15, the filing with the California Office of Attorney General said. 

Turner confirmed on July 27 that files that contained personal information had been accessed without authorization, and some of the files that were accessed may have also included individuals' passport numbers. Ransomware group Payouts King claimed responsibility for the attack, alleging that the data that had been breached extended far beyond personal data to include engineering documents, military project files, contracts and non-disclosure agreements, a post on ClaimDEPOT, a class-action lawsuit tracking website, said. 

Turner issued a statement that after discovering that unauthorized access to certain files had occurred, the company engaged third-party cybersecurity and forensic experts and that those experts continue to review the files that were accessed. The company said it would notify impacted individuals and other parties as necessary and provide complimentary identity protection services. Turner added it would not comment on claims made by criminal organizations. 

According to ClaimDEPOT, Payouts King first posted information relating to an unidentified victim on July 24 and publicly naming Turner on August 11. The group posted the claims on a Tor network site, which hides the users' locations and identifies, claiming it had obtained 27.2 terabytes of data. Apart from the file types stated in the California attorney general filing, Payouts King claimed it had also accessed documents that were protected under International Traffic in Arms Regulations, which are US government rules regulating the export and import of military items, technology and services. Turner is offering five years of identity protection services through IDShield and IDX, the notices filed with the California AG's office said. 

One of the two notices set a November 18 deadline for affected individuals to enroll. The incident comes amid a wave of attacks targeting construction-related domains, an August 6 post on Google's Threat Intelligence blog identifying potentially compromised sites said. Turner is the largest contractor in the industry by revenue and focuses on data centers and advanced technology construction. The booming data center sector drove the firm to build a $44.3 billion backlog by the end of 2025.  

Several law firms have since posted notices of investigations into the Turner incident, seeking plaintiffs for potential class-action lawsuits. Turner also reported that at least 38 Vermont residents were affected by the breach, according to the Office of the Vermont Attorney General.