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, 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.
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.
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.
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.
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.
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.
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.
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.