TL;DR for CISOs: Microsoft detailed an attack in which automated operators used a service principal secret exposed in a public GitHub issue to delete Azure storage accounts and other resources in minutes, while independent backup locks held. Google and Mandiant warned that ShinyHunters is again exploiting Oracle PeopleSoft with a WAF bypass. UpGuard found more than 16,000 Supabase databases readable by outsiders. And Times Car confirmed that about 6.6 million accounts, including driver's license images, were exposed.
- Machine identities are now the shortest route to destruction. A secret pasted into a public issue stayed usable after it was edited out, and automated operators used it faster than most alerting can be worked. Rotation, not deletion of the post, is the fix.
- Controls that do not depend on the compromised identity are the ones that held. Backup and recovery protections configured separately from routine administration stopped deletions that the attacker's credentials could otherwise have performed.
- A WAF rule is not a patch, and a default-open data layer is not a vendor flaw you can wait out. The PeopleSoft bypass and the Supabase exposures both come down to what you believed was closed versus what an outsider could actually reach.
Lead story: AI-orchestrated attackers wiped Azure storage in minutes using a secret left in a public GitHub issue
CRITICAL · CLOUD DESTRUCTIONActor: Microsoft tracks the activity as Storm-3168, linked to the JADEPUFFER operation that Sysdig previously documented as LLM-driven
Entry point: Azure service principal credentials that an employee posted in plaintext in a public GitHub issue; the secret was later edited out, but stayed readable in the issue's public edit history
Scale (Microsoft): Two compromised service principals; one enumerated resources for roughly 15 hours or more, the second ran 150+ destructive or credential-collection operations in 35 minutes
Impact: Most targeted Azure Storage accounts were deleted, along with one Key Vault, one Function App and one App Service plan; BleepingComputer reports 100+ storage account deletion attempts
What held: Azure SQL deletions failed because of an unsupported API version, and Site Recovery and Azure Backup protection locks blocked removal of recovery resources
Timing: Activity occurred in early June 2026; Microsoft published its analysis on September 25, 2026
What happened
Microsoft Security Research published its analysis of Storm-3168 on September 25, 2026, and BleepingComputer and The Hacker News covered it on September 28. According to Microsoft, the attackers held two compromised Azure service principals. The first was used to map resources across subscriptions over many hours. The second then carried out the destructive phase, a burst of more than 150 delete and credential-collection operations in 35 minutes, aimed mainly at storage accounts, SQL databases, Key Vaults and backup and recovery resources.
The way in was ordinary. Microsoft says an employee pasted a service principal's client ID, secret and tenant ID into a public GitHub issue. The secret was removed in a later edit, but the earlier version remained visible through the issue's edit history, so the credential stayed usable until someone rotated it. Microsoft's point is that deleting the disclosure does not remediate the exposure.
The tempo is what stands out. Microsoft describes parallel token streams and segmented operations across identities, which it reads as scripted or automated execution, and it characterizes the behavior as consistent with ransomware-extortion tactics against backups and recovery locks. Microsoft names Yossi Weizman and Tushar Mudi as the authors of the analysis. Some deletions did not succeed: SQL database removals failed on an unsupported API version, and independent protection locks on backup and recovery resources stopped those deletions even though the attacker held administrative-level access.
Evidence
Verified against independently fetched sources:
1. Microsoft Security Blog, Storm-3168: Agentic-driven cloud attacks using compromised service principals, September 25, 2026
2. BleepingComputer, JadePuffer agentic AI attacks target Azure, destroy cloud resources, September 28, 2026
3. The Hacker News, JADEPUFFER-linked attackers used compromised service principals to delete Azure resources, September 28, 2026
What this means for your team
Read this as an identity incident first and an AI incident second. Nothing about the entry point required a new technique: a machine credential was exposed in a place engineers use every day, and it stayed valid. What automation changed is the time available to respond. When 150 operations fit inside 35 minutes, a detection that pages someone in an hour is a post-mortem trigger, not a control.
The most useful line in Microsoft's write-up for a CISO is what failed for the attacker. Locks and protections configured independently of the compromised identity kept working while the identity itself did not. That is an argument for treating backup and recovery protection as a separate control plane with its own access path, not as a setting the same administrators can flip.
Also ask a plain question of your engineering leads: how many service principals, API keys and tokens exist that no human currently owns? Those are the credentials that get pasted into issues, tickets and chat, and they are the ones nobody notices are still live.
- Search your public and internal repositories, issue trackers and their edit histories for client secrets, tenant IDs and keys, and rotate anything found. Editing a post does not revoke a credential.
- Enumerate every service principal in your Azure tenants, assign an owner to each, cut permissions to the minimum resources required, and set expiry on secrets.
- Apply resource locks and deletion protection to storage accounts, Key Vaults and backup vaults, and gate lock removal behind a separate approval path from routine administration.
- Add detections for bursts of Resource Manager read and delete operations from a single principal, and test whether your team can revoke a principal inside minutes rather than hours.
ShinyHunters returns to Oracle PeopleSoft with a WAF bypass that changes one character
HIGH · ACTIVELY EXPLOITEDVulnerability: CVE-2026-35273, an unauthenticated remote code execution flaw in Oracle PeopleSoft, rated CVSS 9.8 in The Hacker News reporting
Actor: ShinyHunters, tracked by Google as UNC6240, per Google Threat Intelligence Group and Mandiant
Bypass: Requests to /%50SEMHUB/ instead of /PSEMHUB/ slip past WAF rules that match the literal path before decoding it
Post-exploitation: JSP web shells, the SIDEEYE backdoor, the Neo-reGeorg tunneling toolkit and the MeshAgent remote management tool for persistence
Reach: Web shells on dozens of systems; sectors now include higher education, technology, IT services, healthcare, agriculture, transportation and government
Earlier wave: Google reported the June campaign reached more than 100 PeopleSoft customers, with education the initial focus
What happened
Google's threat intelligence teams warned on September 28 of a fresh ShinyHunters campaign against Oracle PeopleSoft, following Mandiant reporting covered by BleepingComputer and The Hacker News on September 26. The group is again exploiting CVE-2026-35273, the flaw it used as a zero-day in June, this time against organizations that may believe they are covered.
The technique is simple. Mandiant found the attackers URL-encode one character in the request path, sending /%50SEMHUB/ in place of /PSEMHUB/. Many WAFs and reverse proxies compare the literal path before decoding it, so a rule written to block the original path misses the encoded one, while WebLogic decodes the request and routes it to the vulnerable Environment Management Hub endpoint.
Once in, the attackers deploy JSP web shells, the SIDEEYE backdoor and tunneling and remote management tools. The Hacker News reports that roughly a quarter of the commands they ran executed with root or system privileges. Google says the activity follows a data-theft extortion pattern, and its reporting names the University of Nottingham, the NAIC and Nissan among victims of the earlier wave.
Evidence
Verified against independently fetched sources:
1. SecurityWeek, Google warns of ShinyHunters' fresh Oracle PeopleSoft campaign, September 28, 2026
2. BleepingComputer, ShinyHunters uses WAF bypass trick in Oracle PeopleSoft attacks, September 26, 2026
3. The Hacker News, Attackers bypass WAFs to exploit Oracle PeopleSoft flaw and deploy web shells, September 26, 2026
What this means for your team
A WAF rule is a mitigation for a period of time, not a fix, and this campaign shows how short that period can be. If your exposure decision for PeopleSoft rested on a virtual patch, you have a gap between what you believe is closed and what is reachable.
PeopleSoft typically holds student, employee, finance and HR records, which is why a data-theft extortion crew targets it. Google's guidance to prepare for extortion contact is a reminder to decide in advance who talks to whom if a ransom email lands, before it lands.
The service accounts on these systems are the durable prize. Attackers who reach WebLogic and PeopleSoft service accounts can persist and move well after the web shell is removed.
- Confirm the CVE-2026-35273 update is installed on every PeopleSoft environment, including test and staging systems that share network paths with production.
- Disable the Environment Management Hub or remove the PSEMHUB application where it is not required, and search WebLogic access logs for both /PSEMHUB/ and encoded variants such as /%50SEMHUB/.
- Inspect for unexpected JSP files and MeshAgent installations, then rotate PeopleSoft and WebLogic service account credentials.
- Review WAF rules that match on decoded versus raw paths, and pre-brief legal and communications on a possible extortion approach.
UpGuard finds more than 16,000 Supabase databases readable by outsiders
HIGH · DATA EXPOSUREFinding: Over 16,000 Supabase databases with readable tables (16,326 in RuntimeWire's account of the research)
Method: UpGuard analyzed about 300,000 domains that use Supabase
Data: More than half showed indicators of personal information; smaller subsets showed passwords or authentication tokens, and limited cases suggested card data
Root cause: Missing or ineffective Row Level Security policies, misused public keys and weak application configuration; tables created programmatically, the usual route for coding agents, do not enable RLS automatically
Examples cited: A US valet service with more than 100,000 customer records, and a Canadian immigration service with about 5,000 user records including 884 plaintext passwords
What happened
Security firm UpGuard published research on September 28 showing that thousands of applications built on Supabase, a managed Postgres platform, expose their data to anyone who knows where to look. Across roughly 300,000 domains it examined, it found more than 16,000 databases with tables readable without proper authorization, and more than half of those held indicators of personal information.
UpGuard attributes the exposure to configuration rather than a platform flaw: Row Level Security policies missing or wrong, public keys used where they should not be, and general application security gaps. It also points to AI coding agents that create database tables without a human reviewing the access settings. Supabase has begun changing defaults for new projects and tables, according to RuntimeWire, but existing deployments need manual review.
Among the examples UpGuard cites are a US valet service exposing more than 100,000 customer records, including contact details, license plates and visit history, and a Canadian immigration service whose exposed records included 884 plaintext passwords. UpGuard's recommended starting point is Supabase's own security advisors and API security guidance.
Evidence
Verified against independently fetched sources:
1. BleepingComputer, Misconfigured Supabase apps expose data in over 16,000 databases, September 28, 2026
2. RuntimeWire, UpGuard finds 16,326 Supabase databases with readable tables, September 2026
What this means for your team
This is a shadow-IT and third-party risk story in one. The applications in UpGuard's sample were built quickly, often by small teams or by AI tooling, and many were never on a security review calendar. If your business units, contractors or acquired companies ship internal tools on managed backends, some of them almost certainly hold real data.
It is also a question about your own developers' use of coding agents. The failure here was not that an agent wrote bad code but that nobody owned the access policy for what it created. Generated schema needs the same review gate as hand-written schema.
The plaintext passwords in one exposed table are a separate lesson: the breach of a small vendor becomes your credential-stuffing problem when your users reuse passwords.
- Inventory which applications across the company, including vendor and business-unit projects, run on Supabase or similar backend-as-a-service platforms, and identify an owner for each.
- For each project, confirm Row Level Security is enabled on every table exposed through the API and test policies with an unauthenticated client before release.
- Add a review step for database objects created by AI coding tools, and scan repositories and front-end bundles for keys that should not be public.
- If a project holds personal data and was open, treat it as a potential incident: check access logs, then assess notification duties.
Times Car confirms 6.6 million accounts exposed, including driver's license images
HIGH · CONFIRMED BREACHOrganization: Times Car, the car-sharing service run by Times Mobility, part of Japan's Park24 Group
Scale: About 6.6 million current and former member accounts, including corporate accounts, per BleepingComputer
Data: Names, addresses, dates of birth, phone numbers, email addresses, passwords, linked service IDs and identity verification documents including driver's license images; credit card data was not affected
Timeline (as reported): Unauthorized access detected September 25; access route blocked September 26; public confirmation September 28
Status: External forensic experts engaged; company reports no evidence yet of the data being distributed online; Japan's Personal Information Protection Commission notified, per MLex
What happened
Park24 said the unauthorized access reached the web system behind Times Car, exposing account records for roughly 6.6 million current members, former members and incomplete applicants. BleepingComputer reports the exposed data includes contact details, passwords and images of identity verification documents, and that the company says credit card details were not affected.
Reporting on the timeline indicates the company detected the intrusion on September 25 and cut the access route about a day later, on September 26, before confirming the data theft publicly on September 28. BleepingComputer states passwords were stored in a form that cannot be restored and that no evidence of distribution online had surfaced at the time of publication. The company advises members to be cautious of phishing by email, SMS and phone.
No threat actor has been named in the reports reviewed, and the root cause has not been disclosed; external forensic specialists are investigating.
Evidence
Verified against independently fetched sources:
1. BleepingComputer, Times Car confirms data breach affecting 6.6 million user accounts, September 28, 2026
2. BigGo Finance, Park24's Times Car suffers data breach affecting 6.6 million records, September 2026
3. MLex, Japan's Park24 reports data breach affecting 6.6m accounts, September 2026
What this means for your team
Identity document images change the risk calculation. A leaked password can be reset; a leaked driver's license image supports account opening fraud and convincing impersonation for years. If your own service collects ID images for verification, ask what you retain them for and how long.
Fast containment, about a day in this case, is a good outcome, and it is worth noting that the company still faces a multi-million-record disclosure. Time to contain and scope of what was reachable are separate measures, and the second is set long before an incident.
- If your organization collects government ID images, review retention: keep them only as long as verification requires, store them separately from account data and restrict who can read them.
- Check whether any staff or customers of yours are Times Car members and prepare phishing awareness guidance for them.
- Confirm you can cut a compromised web system's data access route inside a day, and rehearse it.
Also notable
- Bitget revises its exchange-hack loss to about $388 million. CEO Gracy Chen said the attacker exploited a zero-day in a third-party security product to reach an internal management system, per The Hacker News; BleepingComputer, which reports $387.5 million and staged withdrawal resumption, did not name a third-party product, so root-cause detail differs by source. Bitget suspects North Korean actors but has not formally attributed the attack. Source: The Hacker News
- Keio Corporation confirms ransomware disrupted business systems. The Japanese railway and hospitality group said the September 26 failure was ransomware affecting hospitality-division and payment systems; train operations were not affected and no group had claimed the attack at the time of reporting. Source: BleepingComputer
- DC Department of Health Care Finance reports exposure of 399,086 beneficiaries. Two web reports built to show summary statistics contained underlying data, including Medicaid IDs and dates of birth, that may have been reachable between 2023 and July 2026; the agency found the issue in July and says it has no reason to believe the data was misused. Source: SecurityWeek
- CISA sets a September 30 federal deadline for the exploited Citrix NetScaler flaws. BleepingComputer, citing Shadowserver data, reports more than 23,000 internet-exposed NetScaler instances; this follows the September 27 edition of Breach Watch. Source: BleepingComputer
- Apple patches CVE-2026-86950, an out-of-bounds write in CoreGraphics. Apple says the flaw may have been exploited in an extremely sophisticated attack against specific targeted individuals; fixes ship in iOS and iPadOS 26.7.1, macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1, and Meta Product Security is credited. Source: The Hacker News
Frequently asked questions
What did Microsoft report about Storm-3168 and the Azure attacks?
Microsoft reported that Storm-3168, linked to JADEPUFFER, used two compromised Azure service principals. One mapped resources for many hours; the second ran more than 150 destructive or credential-collection operations in 35 minutes. Most targeted storage accounts were deleted, while SQL deletions and backup protection locks did not fall.
How were the Azure credentials exposed?
According to Microsoft, an employee posted a service principal's client ID, secret and tenant ID in a public GitHub issue. The secret was later edited out, but it stayed visible in the issue's public edit history, so the credential remained usable until rotated.
Why did a WAF not stop the Oracle PeopleSoft attacks?
Mandiant found ShinyHunters URL-encodes one character in the request path, requesting /%50SEMHUB/ instead of /PSEMHUB/. Many WAFs compare the literal path before decoding it, so the rule misses the request, while WebLogic decodes it and routes it to the vulnerable endpoint. Patching CVE-2026-35273 is the fix.
What did UpGuard find in Supabase databases?
UpGuard found more than 16,000 Supabase databases with readable tables across about 300,000 domains examined. More than half showed indicators of personal information. UpGuard attributes the exposure mainly to missing or ineffective Row Level Security policies and configuration errors, not a platform flaw.
Which data was exposed in the Times Car breach?
Reports say about 6.6 million accounts were affected, with names, addresses, dates of birth, phone numbers, email addresses, passwords, linked service IDs and identity verification documents including driver's license images. Credit card information was reported as not affected.
Related reading from the community: past editions in the Breach Intelligence briefing archive, practitioner material on cloud security for security leaders, guidance on third-party and vendor-risk frameworks, and the wider library of frameworks and checklists on CISO Platform.
Comments