This week, the attack surface wasn’t your firewall or your endpoints. It was the systems you taught your users to trust: the AI chatbot handling your password resets, the official package registry your developers pull from every morning, the legitimate websites your staff visits daily. Meta delegated account recovery to an AI support agent, and attackers used that delegation to seize government and military Instagram accounts without cracking a single password. Attackers compromised one Red Hat engineer’s GitHub account and used GitHub Actions OIDC tokens — valid, signed, provenance-attested tokens — to inject a self-replicating credential-stealing worm into 32 packages downloaded over 116,000 times a week. A threat actor called DriveSurge has been quietly hijacking thousands of reputable websites since at least September 2025, building an industrialized pay-per-install pipeline that profiles visitors and serves them either a fake browser update or a ClickFix social engineering prompt, depending on what the traffic distribution system decides will land better.
And while all of that was happening, ShinyHunters continued running its 2026 playbook: Carnival Corporation confirmed nearly six million customer records were exfiltrated via a single employee social engineering call in April, adding another entry to what is now a sustained, methodical campaign against every major consumer-facing brand with a Salesforce instance and a customer loyalty database.
This week: AI support agents as an account takeover primitive, why a signed package with valid SLSA provenance still ran a credential-stealing worm, and how DriveSurge has been profiting off your users’ browsing habits for nearly a year without anyone noticing.
Meta AI Instagram Account Takeover — Chatbot as Account Recovery Bypass
What happened:
Over the weekend of May 31 to June 1, 2026, attackers exploited Meta’s AI-powered customer support chatbot to seize control of dozens of Instagram accounts, including the dormant Obama-era White House account, the Instagram profile of U.S. Space Force Chief Master Sergeant John Bentivegna, the Sephora corporate page, and security researcher Jane Manchun Wong’s personal account. The method required no malware and no stolen password. Attackers tricked Meta’s AI support chatbot into granting access to targeted accounts, and at its core, the attack involved attaching third-party emails to accounts, which then allowed attackers to change passwords. Meta confirmed the issue and began securing impacted accounts on June 1.
Technical details that matter:
- Initial Access: Bad actors, using a VPN connection with an IP address in or near the target’s usual hometown, asked the chatbot to link the account to a new email address. Meta AI then sent a one-time code to that address, authenticating it and enabling a password reset. The geolocation check — designed to flag logins from unfamiliar regions — was bypassed by routing through a VPN geolocated near the victim’s city.
- No traditional attack primitives: No credential stuffing, no phishing link, no malware. The attacker used the AI support workflow exactly as designed, with one modified input: the destination email address.
- Defense bypass: According to Krebs on Security, the attack method would likely not succeed against accounts using any form of multi-factor authentication, even basic SMS codes. Accounts without MFA, or where the AI support option was active and MFA was bypassed by the recovery flow itself, were fully exposed.
- Incomplete patch: Reports emerged that Meta’s fix failed to secure the backend, with hackers claiming Meta only removed a UI button rather than closing the underlying authorization logic. Account takeovers were reportedly continuing after Meta’s public statement that the issue was resolved.
- Secondary use: A Telegram account that posted a video demonstrating the technique linked to screenshots of pro-Iran images and messages defacing the hacked Instagram accounts, and claimed hackers used the exploit to hijack valuable short Instagram usernames with resale value exceeding half a million dollars. The same vulnerability served both ideologically motivated actors and financially motivated account traders simultaneously.
Why critical institutions should care:
The security hole was discovered roughly three months after Meta turned over control of some customer service issues, such as resetting forgotten passwords, to AI. This incident is the first confirmed mass exploitation of an AI support agent as an account recovery bypass primitive — and it will not be the last. Any organization that has delegated identity verification, password reset, or account recovery workflows to an AI agent, whether that is a Meta chatbot, an internal helpdesk AI, or a third-party SaaS support tool, has introduced a new attack surface that traditional access controls do not cover. The AI agent’s authorization logic is now part of your identity perimeter. If that logic can be manipulated through a natural language prompt — as it was here — then every account behind it is one convincing request away from compromise. Government agencies, healthcare organizations, and financial institutions whose staff use Meta business accounts for communications, advertising, or brand presence should audit which account recovery workflows are AI-delegated and what identity verification those workflows actually perform.
Key sources:
- https://krebsonsecurity.com/2026/06/hackers-used-metas-ai-support-bot-to-seize-instagram-accounts/
- https://techcrunch.com/2026/06/01/hackers-hijacked-instagram-accounts-by-tricking-meta-ai-support-chatbot-into-granting-access/
- https://www.fastcompany.com/91552371/hackers-found-a-way-to-make-metas-ai-hand-over-instagram-accounts
- https://www.androidauthority.com/meta-ai-instagram-hack-continues-3673846/
Miasma: Red Hat npm Supply Chain Compromise via CI/CD Pipeline
What happened:
On June 1, 2026, security researchers at Wiz, Aikido, Snyk, and Socket independently identified a supply chain compromise affecting the @redhat-cloud-services npm namespace. The attack compromised 32 official npm packages under the @redhat-cloud-services scope after a Red Hat employee’s GitHub account was compromised, with the attacker injecting malicious GitHub Actions workflows into three RedHatInsights repositories. In total, 96 versions across 32 packages were compromised, cumulatively downloaded 116,991 times per week. The malicious payload, which researchers named Miasma, is a new variant of the Mini Shai-Hulud credential-stealing worm previously associated with threat actor group TeamPCP. Red Hat confirmed that no official Red Hat products shipped with the compromised versions, and most malicious package versions were revoked within hours of disclosure.
Technical details that matter:
- Initial Access: The attack was carried out after a Red Hat employee’s GitHub account was compromised, with the attacker injecting malicious GitHub Actions workflows rather than targeting individual developer npm tokens. This is significant: the packages were published using GitHub Actions OIDC tokens — the modern, credential-free authentication mechanism designed to replace static secrets — meaning the packages carried valid SLSA provenance attestations despite containing malicious code.
- Execution: The compromised releases carry a preinstall script that runs an obfuscated payload the moment a package is installed, harvesting developer and cloud credentials and attempting to spread itself to other packages the victim can publish. npm runs preinstall scripts automatically during
npm install, before any user code executes, so simply resolving the dependency triggers the payload. - Credential harvesting scope: The Miasma variant introduced new collectors for Google Cloud Platform and Microsoft Azure identities, enabling enumeration of all cloud identities accessible from the infected host. Prior Shai-Hulud variants primarily targeted static secrets; Miasma dynamically enumerates and exfiltrates live cloud identity credentials from AWS, GCP, and Azure configurations, SSH keys, npm tokens, and GitHub tokens.
- Self-propagation: The worm also queried the npm registry for other packages the compromised identity could publish, republishing itself to those packages and thereby enabling rapid propagation across the supply chain.
- Attribution complexity: Exactly who is behind the attack is presently unknown given that TeamPCP has open-sourced the Shai-Hulud attack tools, opening the door for other threat actors to run similar attacks and making definitive attribution harder.
- Obfuscation: The payload used eval() and ROT-based string decoding to obscure its logic, consistent with prior Mini Shai-Hulud tradecraft. A second wave of malicious commits was pushed later on June 1 and additional compromised packages continued to surface through June 4.
Why critical institutions should care:
The Shai-Hulud incident proved that the npm registry could be used as a force multiplier for malware distribution, and Miasma confirms that the playbook has been industrialized. The @redhat-cloud-services namespace is not a random third-party package; it is official infrastructure used by the Red Hat Hybrid Cloud Console and consumed by enterprise development teams building on OpenShift and related products. The attack bypassed SLSA provenance — the supply chain security framework specifically designed to prevent exactly this scenario — by compromising the CI/CD pipeline rather than a developer’s local machine. Any organization whose developers use @redhat-cloud-services packages and installed an affected version between May 29 and June 2, 2026 should treat their developer workstations as compromised: rotate all cloud credentials, GitHub tokens, npm tokens, and SSH keys that were accessible on those machines. The self-propagating worm means downstream packages in the same developer’s publishing scope may also have been compromised.
Key sources:
- https://www.wiz.io/blog/miasma-supply-chain-attack-targeting-redhat-npm-packages
- https://snyk.io/blog/miasma-supply-chain-attack-malicious-code-redhat-cloud-services-npm-packages/
- https://www.aikido.dev/blog/red-hat-npm-packages-compromised-credential-stealing-worm
- https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
DriveSurge: Industrialized ClickFix/FakeUpdates Initial Access Brokerage
What happened:
On June 2, 2026, Silent Push published research identifying a previously untracked threat actor called DriveSurge as the operator behind a large-scale, sustained malware delivery campaign that has compromised thousands of legitimate websites to redirect their visitors toward malware. Threat actors have compromised thousands of websites for the purpose of engineering industrialized ClickFix and FakeUpdate attacks in an organized malware delivery operation aimed at selling initial access to systems, with the campaign targeting not only Windows users but also macOS systems, and appearing to be a mature cybercriminal ecosystem that avoided detection for nearly a year. The operation functions as an initial access broker (IAB) selling access to downstream ransomware operators, credential thieves, and espionage actors.
Technical details that matter:
- Infrastructure: DriveSurge operates using a Traffic Distribution System known as zTDS, which profiles visitors and determines whether a FakeUpdates or ClickFix lure is more appropriate. zTDS is an open-source TDS that has been in active use by this actor since at least September 2025. Bots and researchers are served the legitimate webpage to avoid detection.
- Delivery mechanism (ClickFix): Victims on compromised sites see a fake browser or application error. A fake error message instructs the victim to copy and paste a command into their terminal or PowerShell window, which then silently installs malware. For macOS, clipboard hijacking is used to intercept legitimate terminal commands and substitute malicious ones.
- Delivery mechanism (FakeUpdates): Sites display browser update prompts that deliver malicious executables masquerading as Chrome, Firefox, or Edge installers.
- Infrastructure fingerprinting: Researchers identified eight technical fingerprints linked to the campaign that helped identify DriveSurge infrastructure and compromised websites, including a JavaScript injection following a specific URL pattern. The underlying obfuscation uses Base64 encoding and string manipulation to hide redirect code inside normal-looking page elements, with a failover mechanism cycling through backup delivery domains if the primary goes down.
- Business model: DriveSurge operates as an initial access broker, utilizing a pay-per-install model to facilitate subsequent attacks. This means DriveSurge does not deploy the final payload itself — it sells verified access to victim machines to whoever is willing to pay, making attribution of downstream attacks to this infrastructure difficult.
- Evasion duration: The campaign operated undetected for approximately nine months before this disclosure, indicating mature operational security and a deliberate preference for volume over visibility.
Why critical institutions should care:
DriveSurge is not a targeted attack operation. It is infrastructure. The compromised sites include legitimate, high-reputation domains — the kinds of websites that appear in enterprise proxy allowlists and that employees visit without suspicion. The fact that the campaign has been active since at least September 2025 and sells access to downstream operators means organizations that experienced unexplained initial access incidents in that window — particularly involving PowerShell execution on developer or IT workstations — should revisit those incidents with DriveSurge’s IoCs against their logs. The macOS delivery capability is particularly notable for organizations in professional services, legal, and financial sectors where Mac endpoints are common and EDR coverage is often lighter than on Windows. The ClickFix technique specifically targets users who are comfortable in a terminal, which means your IT and developer staff are the most likely victims.
Key sources:
- https://www.silentpush.com/blog/drivesurge/
- https://www.bleepingcomputer.com/news/security/hackers-hijack-thousands-of-sites-for-clickfix-and-fakeupdate-attacks/
- https://www.darkreading.com/cyberattacks-data-breaches/drivesurge-hijacks-thousands-sites-clickfix-fakeupdate-attacks
- https://www.scworld.com/brief/drivesurge-actor-uses-clickfix-and-fakeupdates-to-distribute-malware-via-compromised-websites
Update: ShinyHunters — Carnival Corporation, 6 Million Records Confirmed
The ShinyHunters campaign we covered last week — which produced the Charter/Spectrum 4.9 million record disclosure — added a confirmed victim that disclosed notifications in the days just before that edition closed. Carnival Corporation, the world’s largest cruise operator, confirmed a digital heist a month after ShinyHunters claimed to have stolen millions of customer records, with Carnival acknowledging a phishing incident involving a single employee account and stating that it was investigating the scope of the unauthorized activity.
What’s new this week:
Carnival detected unauthorized activity on an employee account on April 14, 2026, after which further investigations determined that the threat actor had tricked the employee into granting access to limited portions of the company’s IT infrastructure through social engineering. On April 22, the probe determined that the threat actor had illegally copied the personal information of 5,995,277 customers.
According to HaveIBeenPwned, which analyzed the leaked dataset, roughly 7.5 million accounts related to the Mariner Society loyalty program run by Carnival’s Holland America brand were likely affected. The leaked information included names, email addresses, dates of birth, gender, geographic locations, and loyalty program details.
ShinyHunters claimed it lifted terabytes’ worth of Carnival records and, following a breakdown in negotiations, released data on around 40 different organizations simultaneously, including Mytheresa, Zara, 7-Eleven, Pitney Bowes, and Carnival. This simultaneous mass-publishing across 40+ organizations is the ShinyHunters pressure model in its fully operational form: if one victim doesn’t pay, releasing the data from 39 others simultaneously maximizes reputational damage and creates leverage for ongoing negotiations with any holdouts.
The pattern here is identical to Charter: one social engineering call, one employee account, SaaS data exfiltration, extortion demand, non-payment, publication. For travel, hospitality, and healthcare organizations — sectors with large customer PII databases and high consumer trust requirements — this is now a documented template being executed at scale.
Key sources:
- https://www.malwarebytes.com/blog/data-breaches/2026/05/carnival-confirms-data-breach-impacting-nearly-6-million
- https://www.theregister.com/cyber-crime/2026/05/28/carnival-shinyhunters-cruised-off-with-6m-customer-records/5247808
- https://www.helpnetsecurity.com/2026/05/28/carnival-corporation-data-breach/
- https://www.securityweek.com/carnival-data-breach-exposed-6-million-people/
The Pattern This Week
Three separate incidents. Three separate attack primitives. One common thread: adversaries are targeting the mechanisms of delegation.
Meta delegated account recovery to an AI agent, and attackers used the agent’s authorization logic as a bypass. Red Hat delegated package publishing to GitHub Actions OIDC, and attackers compromised the GitHub account upstream of that delegation to publish malicious packages with valid provenance. DriveSurge compromises legitimate website owners and delegates the malicious redirect to a traffic distribution system that operates on their infrastructure without their knowledge. ShinyHunters delegates the work of gaining initial access to a single social engineering call against a single employee and then leverages whatever that employee was authorized to access.
The defender’s problem with all four of these is the same: the trust signal is real. The Meta AI chatbot was functioning as designed. The Red Hat packages had valid SLSA provenance. The compromised websites were legitimate. The Carnival employee account was authorized to access what ShinyHunters accessed. Detection requires moving one layer upstream — not “is this token valid” but “is this token being used the way a human would use it at 3 AM” — and that layer is where most organizations do not yet have visibility.
See you next week.
What Your Business Can Do This Week
These four incidents point to a single architectural problem — systems that grant access based on trust signals that can be impersonated or abused — but each has a specific, actionable defensive implication.
1. Audit every AI-powered workflow that can change account credentials or recovery information.
The Meta AI incident is the first confirmed mass exploitation of an AI support agent as an account takeover primitive, but it will not be the last. If you use any AI-powered helpdesk tool, IT support chatbot, or customer-facing support agent that has the ability to modify account email addresses, reset passwords, or add authentication methods — whether that is a Meta product, a third-party SaaS support tool, or an internal AI agent built on an LLM API — you need to map what identity verification that agent performs before making account changes. The specific failure at Meta was that geolocation check (easily bypassed with a VPN) was the primary barrier between a natural language request and a complete account takeover. Effective verification requires something the user possesses or knows that is not inferrable from public information and is not bypassable with a $10 VPN subscription.
2. Treat any developer machine that ran npm install with @redhat-cloud-services packages between May 29 and June 4 as fully compromised and rotate all credentials on it.
If your organization uses Red Hat OpenShift, the Hybrid Cloud Console, or any frontend components from the @redhat-cloud-services namespace, verify whether any affected package versions were installed during the Miasma window. The full list of affected packages and versions is published by Wiz, Aikido, and Snyk. For affected machines, Miasma’s harvest scope was comprehensive: AWS, GCP, and Azure cloud credentials, GitHub tokens, npm tokens, SSH keys, and environment variables. Rotating only cloud credentials while leaving GitHub tokens in place is insufficient — the worm targeted all of these simultaneously. If you cannot confirm which machines installed affected versions, treat your entire developer fleet as potentially exposed and rotate credentials across the board.
3. Pull your proxy and endpoint logs for DriveSurge indicators of compromise going back to September 2025.
Silent Push published eight technical fingerprints for DriveSurge infrastructure in their report, including the JavaScript injection pattern (t.js?site=) that identifies compromised websites serving as delivery vectors. If your organization has an endpoint detection product that logs PowerShell execution or clipboard-based command execution, search for events in that window that originated from unexpected processes or that involved execution of commands the user appears to have pasted rather than typed. The ClickFix technique specifically produces a behavioral signature: a user opens a browser, visits a legitimate site, and shortly afterward manually executes a PowerShell or terminal command. That sequence is worth investigating if it appears in your logs unexpectedly.
4. Run ShinyHunters’ documented playbook against your own environment as a tabletop scenario before they do it for real.
The ShinyHunters methodology is now fully documented across Charter, Carnival, and dozens of other confirmed victims: a single vishing call to an employee, a compromised SSO or SaaS account, bulk data export from a CRM or similar platform, an extortion demand, and publication if the demand is refused. The tabletop question is not “could an attacker get into our network” — it is “if an attacker has valid credentials for one of our Salesforce, Workday, or ServiceNow accounts right now, what data could they export, how long would it take, and would any alert fire?” If the answer to that last question is “no” or “I don’t know,” your data loss prevention configuration needs attention before your breach notification letter does.