Citrix Bleed 2 (CVE-2025-5777) is a critical NetScaler flaw that leaks session tokens from memory. The Anubis ransomware group has used it to bypass MFA and hit 91 victims. Patching alone does not close the door. You must kill active sessions too.

What Is Citrix Bleed 2 Ransomware?

Citrix Bleed 2 ransomware refers to ransomware attacks that use CVE-2025-5777 as the entry point. CVE-2025-5777 is a pre-authentication memory disclosure vulnerability in Citrix NetScaler ADC and Gateway appliances. The name comes from its close resemblance to the original Citrix Bleed (CVE-2023-4966) from 2023.

The flaw itself is not ransomware. It is the crowbar. Attackers pry open the door with it, walk in, and deploy ransomware once inside. Security researcher Kevin Beaumont coined the “Citrix Bleed 2” label because the two bugs behave so similarly.

Here is the mechanism in plain terms. The backend parser hands back an uninitialized local variable that was supposed to hold the username from the login parameter. When the input is partially formed or missing, the server responds with whatever residual data sat in that memory space. That leaked data can include live session tokens.

Why It Matters More Than a Typical CVE

Most vulnerabilities require a password, a click, or a trick. This one does not. The exploitation mechanism does not require guessing a password, bypassing a CAPTCHA, or fooling a user.

That changes the math for defenders. There is no phishing email to spot and no weak credential to blame. An attacker just sends a malformed login request and reads the memory that leaks back.

The scale confirms the risk. Internet scanning firm Censys documented 69,237 exposed instances at the time of disclosure in June 2025. Threat intelligence firm Imperva recorded more than 11.5 million attack attempts targeting the flaw, with 39.1% aimed at the financial services industry.

This pattern of stolen credentials and access-broker activity echoes what I covered in the insider-driven Coinbase incident earlier this year, where the entry point mattered less than what happened after.

Which NetScaler Devices Are Affected?

The flaw only triggers under specific configurations. It is present only when the appliance is configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, or RDP Proxy) or as an AAA virtual server. Default configurations are unaffected, so the subset of exposed appliances is narrower than the full NetScaler population.

Still, that narrower subset is a large target. And older gear has no way out. Organizations running versions 12.1 and 13.0, both End-of-Life as of 2025, have no patch available and remain permanently vulnerable.

The issue impacts devices in versions prior to 14.1-43.56, 13.1-58.32, 13.1-37.235-FIPS/NDcPP, and 12.1-55.328-FIPS. If you run an EOL build, patching is not an option. Replacement is.

How the Timeline Unfolded

The path from disclosure to mass exploitation moved fast. Here is the sequence.

Citrix disclosed the vulnerability on June 17, 2025, and expanded the scope with patches by June 23. The first warning of active exploitation came from ReliaQuest on June 27. On July 7, researchers at watchTowr and Horizon3 published proof-of-concept exploits demonstrating how the flaw steals session tokens.

Then federal action landed. CISA added CVE-2025-5777 to its Known Exploited Vulnerabilities catalog on July 10, 2025, officially confirming active exploitation. The urgency was unusual. CISA gave federal agencies just one day to apply fixes, an unprecedented deadline since the KEV catalog launched.

Worse, the attacks predated the public warnings. GreyNoise reports that exploitation occurred as early as two weeks before proof-of-concept exploit code was publicly available.

Who Is Behind the Citrix Bleed 2 Ransomware Attacks?

The group tied most directly to Citrix Bleed 2 ransomware is Anubis. Anubis is a ransomware-as-a-service (RaaS) group that first emerged in late 2024 as a rebrand of Sphinx ransomware. It was formally announced on the RAMP underground forum in February 2025.

The toll is significant. Arctic Wolf Labs published its full investigation on July 1, 2026, and Anubis has claimed 91 victims, 11 of them in June 2026 alone. More than half of the 91 confirmed victims are US-based, with the remainder concentrated in the United Kingdom, Australia, France, and Canada.

Anubis is not the only actor circling this flaw. One of the IP addresses executing attacks in mid-June was previously linked to the RansomHub ransomware group by CISA. RansomHub’s fingerprints on early activity show how quickly multiple crews adopt a working exploit.

How the Attack Chain Works

Anubis affiliates follow a repeatable playbook. The Citrix Bleed 2 ransomware chain has clear, observable stages, and each one is a chance to catch it.

Initial access. Since the start of 2026, Arctic Wolf has investigated Anubis intrusions involving both valid VPN credential use and exploitation of CitrixBleed 2. Valid Cisco AnyConnect VPN logins were also observed from hosting ASNs, including AS20473 (The Constant Company) and AS55286 (ServerMania).

Lateral movement. Malicious VPN authentication was followed by RDP and SMB activity, leading to credential access, PsExec service creation, and RMM deployment. Attackers targeted high-value infrastructure such as domain controllers, hypervisors, backup-adjacent systems, and NAS devices.

Persistence via legitimate tools. This is the part that makes detection hard. Anubis affiliates repeatedly abused legitimate remote management tools, including ScreenConnect, Zoho Assist, MeshAgent, Remotely, UltraVNC, and Total Software Deployment, to blend in with normal IT activity.

Exfiltration and evasion. Tools like S3 Browser, rclone, s5cmd, WinSCP, and PuTTY were installed for data transfer before ransomware deployment. Defense evasion included Windows Defender real-time protection disablement, SophosUninstall activity, PCHunter-related artifacts, and log clearing across multiple systems.

The reliance on trusted software is the real lesson here. The finding that demands structural attention is the systematic weaponization of legitimate commercial RMM software to create persistence that is nearly indistinguishable from routine IT activity. This living-off-the-land pattern is exactly the kind of threat I flagged when covering broader software supply chain risks and their fixes.

Real Victims and Real Damage

The victims are not abstract. Singing River Health System in Mississippi confirmed in February 2026 that a December 2025 breach affected approximately 53,888 patients, exposing Social Security numbers, dates of birth, treatment records, medication lists, and bank account information. It was the network’s second ransomware breach in two years.

Another case shows the negotiation pattern. In April 2026, Anubis claimed to have stolen two terabytes of patient data from Massachusetts-based Signature Healthcare, then removed the victim from its leak site, a pattern that typically indicates ransom negotiation.

Arctic Wolf documented intrusions across healthcare, financial services, manufacturing, and technology sectors throughout 2026.

Why Patching Alone Does Not Fix Citrix Bleed 2 Ransomware Risk

Patching the appliance is necessary. It is not sufficient. This is the single most misunderstood point about Citrix Bleed 2 ransomware defense.

Tokens extracted before the patch was applied remain valid until explicitly revoked, and no antivirus signature flags a legitimate ScreenConnect installer. An attacker who grabbed a token last week can still walk in today, even on a fully patched box.

Citrix’s guidance is explicit. After applying the fix, administrators must run kill icaconnection -all, kill pcoipConnection -all, and clear aaa session -all on the NetScaler CLI. Skip these and you leave attacker-established sessions alive in memory.

Even those three commands may not be enough. According to Kevin Beaumont, the original commands to clear ICA and PCoIP connections are insufficient to fully mitigate the vulnerability. RDP, AAA, and Load Balancing persistent sessions should also be terminated, since the original commands do not account for all leaked session cookies.

What to Do Right Now

Here is the direct action list. Do these in order.

First, confirm your patch status. Verify patch status against the specific vulnerable builds documented in Citrix advisory CTX693420. If you run EOL versions 12.1 or 13.0, plan an upgrade immediately, because no patch exists for those.

Second, kill every session after patching. Run the three CLI commands, then terminate RDP, AAA, and Load Balancing sessions too. Do not treat the patch as the finish line.

Third, audit your RMM footprint. Maintain a list of approved RMM tools and monitor for installation of unauthorized alternatives, since deployment of multiple RMM tools within a short timeframe is a potential indicator of adversary persistence.

Fourth, block known bad infrastructure. Arctic Wolf recommends blocking known malicious infrastructure such as azuremicrosoft[.]us and promotds[.]us.

Fifth, watch for the login fingerprint. Attackers exploiting CVE-2025-5777 consistently operated from IP addresses associated with virtual private server hosting providers, a distinctive fingerprint, since legitimate employee logins almost always originate from residential or business broadband addresses.

Network defenders also have a signature option. A Snort rule (SID: 65120) detects exploitation attempts by looking for malformed HTTP POST requests targeting the /p/u/doAuthentication.do endpoint.

The timing of these steps matters as much as the steps themselves, a point worth repeating from any Patch Tuesday triage cycle where speed decides whether a fix lands before an attacker does.

The Detection Window You Still Have

Encryption is the last step, not the first. That gap is your opportunity. Arctic Wolf’s recommendations focus on detection before encryption, which remains the point at which defenders still have meaningful options.

The best opportunities for detection lie before encryption, when authentication anomalies, RMM deployment, and exfiltration tools begin to cluster around the same hosts. If you see three RMM tools appear on one server alongside a new PsExec service and odd VPN logins, treat it as an active intrusion, not an IT quirk.

Where This Leaves Us

Citrix Bleed 2 ransomware is a solved problem on paper and an open wound in practice. The patch exists, the CISA mandate is clear, and the mitigation steps are published. Yet 91 victims and counting show how many organizations patched the box and stopped there.

Watch three numbers going forward: the count of exposed NetScaler instances still online, the pace of new Anubis victims on its leak site, and how many breached firms skipped session termination. The exploit is not going away. The teams that survive it will be the ones who treat “patched” as the start of the response, not the end of it.

The post Citrix Bleed 2 Ransomware: The Full 2026 Breakdown appeared first on Tomaro Group.

The name fits. TeamPCP has publicly stated that causing chaos is the goal. And it has been delivering on that promise since late 2025.

What Is the TeamPCP Chaos Crusade?

The TeamPCP Chaos Crusade started quietly in late 2025. The group first targeted cloud infrastructure, focusing on exposed Docker APIs and Kubernetes clusters. Most of that early activity flew under the radar.

That changed in early 2026.

The TeamPCP Chaos Crusade escalated dramatically in March 2026, operating across five software ecosystems including GitHub Actions, Docker Hub, npm, PyPI, and OpenVSX. What followed shook the entire developer community.

Google attributes the bulk of the TeamPCP Chaos Crusade activity to one core operator. The company traced IP address connections to South Africa, indicating the primary operator was located there during at least some of its attacks. Palo Alto Networks tracks three known handles for the campaign: “ResoluteXBF” as the core operator, “diencracked,” and “Shinigami.”

If the TeamPCP Chaos Crusade is truly run by one primary individual, a focused law enforcement action could shut the whole thing down with a single arrest.

How the TeamPCP Chaos Crusade Worked

The methods behind the TeamPCP Chaos Crusade are not technically new. The crux of these attacks hinges on defensive vulnerabilities the entire software industry has known about for years. The speed and scale of these attacks is what makes it most notable, not necessarily the methodology behind it, because at the core it is really about exploiting third-party trusts, said Kimberly Goody, senior manager at Google Threat Intelligence Group.

Here is how the Trivy attack worked on March 19, 2026. Aqua Security’s service account had been compromised weeks prior. TeamPCP used that access to force-push malicious code to 76 of 77 trivy-action version tags on GitHub. Most developers do not pin their GitHub Actions to a specific cryptographic commit hash. They rely on mutable tags like @v1 or @latest. When their pipelines ran routine vulnerability scans, they automatically pulled the poisoned scanner.

The stealer, a 204-line entrypoint.sh script that self-identified as “TeamPCP Cloud Stealer,” ran a three-stage attack. It read memory from Runner.Worker processes, searched for patterns matching secrets, and extracted GitHub PATs, cloud credentials, and API keys from runner memory.

Using stolen GitHub Personal Access Tokens, the attackers created pull requests containing malicious workflows that executed in the context of targeted repositories, giving access to runtime secrets and environment variables. In AWS, ECS Exec was abused to run Bash commands and Python scripts directly on live containers.

Each stolen credential wave unlocked the next target. The chain expanded through Checkmarx, LiteLLM, Telnyx, and more than 66 npm packages.

Credential theft on this scale is part of a broader 2026 trend. The Coinbase insider attack that led to a $400 million loss this year shows just how much damage stolen access can do once it lands in the wrong hands.

Victims of the TeamPCP Chaos Crusade

The confirmed victim list from the TeamPCP Chaos Crusade is staggering. It includes Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat, and Nx Console.

Over 1,000 SaaS environments were impacted, with roughly 500,000 credentials stolen and more than 300 GB of data exfiltrated.

The full collection of packages compromised during the TeamPCP Chaos Crusade accounts for roughly 500 million weekly downloads combined. That number puts into perspective how many organizations were potentially exposed without knowing it.

The GitHub Breach

One of the most alarming moments in the TeamPCP Chaos Crusade came in mid-May 2026.

A malicious build of the Nx Console VS Code extension (v18.95.0, publisher nrwl.angular-console) was published to the Visual Studio Marketplace and was live for approximately 18 minutes before it was pulled. On a GitHub employee endpoint, the extension auto-updated during that window, exfiltrated developer secrets, and was then used to move laterally through GitHub’s internal CI/CD.

The intrusion exfiltrated approximately 3,800 GitHub-internal repositories before containment. OpenAI, Grafana Labs, and Mistral AI were named as downstream victims whose developers had auto-update enabled.

What makes this particularly troubling is that the poisoned extension carried a verified-publisher badge. That badge gave users false confidence that the extension was legitimate.

Read the complete breakdown of how 3,800 internal GitHub repositories were pulled through a single compromised VS Code extension.

The Motivation Behind the TeamPCP Chaos Crusade

The TeamPCP Chaos Crusade is not primarily about financial gain. TeamPCP listed about 4,000 private code repositories on a dark web forum with an asking price of $95,000. That is a small figure for the damage it caused.

Researchers say the group wants notoriety more than ransoms. Goody from Google Threat Intelligence Group put it plainly: “They seem to like to make chaos.”

Nathaniel Quist, manager of cloud threat intelligence at Palo Alto Networks, said: “These actors are more interested in the underground street cred they are gaining and causing as much damage and mayhem as possible.”

Researchers have linked TeamPCP to extortion crews and dark web forums including Lapsus$, ShinyHunters, Vect, DragonForce, and BreachForums. Most partnerships were short-lived and ended in a public feud or otherwise failed to get off the ground.

Stay current with the latest threat actor profiles and incidents through our ongoing cybersecurity coverage at Tomarogroup.

The Shai-Hulud Worm: Open-Sourced to the Public

In May 2026, a new escalation arrived. TeamPCP published the complete source code for its Shai-Hulud worm on two public GitHub repositories.

Security outfit OX spotted a pair of repos on GitHub containing the following text: “Shai-Hulud: Open Sourcing The Carnage. Is it vibe coded? Yes. Does it work? Let results speak. Change keys and C2 as needed. Love – TeamPCP.” TeamPCP chose the MIT License, which allows just about any reuse of the code.

OX’s analysts confirmed the code displayed the same patterns from previous Shai-Hulud attacks. Independent threat actors had already begun modifying it and expanding its reach. Dozens of forks appeared within hours. One added FreeBSD support within a day.

Detection patterns built around TeamPCP-specific code strings will now fire on copycat attacks too. Attribution for future incidents using this code becomes much harder.

For a broader look at the software supply chain threats organizations are actively managing in 2026, this open-sourcing moment is a key inflection point. Anyone with the skills to fork a GitHub repository can now deploy a variant of this attack framework.

AI Widened the Attack Window

AI coding tools played a role in making the damage worse. TeamPCP is capitalizing on new security gaps created by developers’ increasing reliance on AI. “Developers didn’t do a great job of analyzing the security of their open-source dependencies before, but now with AI, there’s in some cases virtually no human in the loop or any kind of sanity check on what these tools are doing,” said Feross Aboukhadijeh, founder and CEO at Socket. “You have agents installing packages that haven’t been vetted. When an attacker gets in, the impact is even broader because there’s less checks and balances to stop it from affecting everybody.”

A representative associated with TeamPCP claimed publicly that AI was used to generate malware components and automate intrusion stages. This claim has not been independently verified and warrants cautious interpretation. However, it is consistent with the observed campaign sophistication and rapid operational tempo.

As AI tools push deeper into modern software development workflows, the reduced human review in automated build pipelines creates an expanding window for exactly this kind of supply chain poisoning.

What Security Teams Should Do Right Now

If your CI/CD pipelines pulled updates between March and late May 2026, treat your environment as potentially compromised until you complete an audit. The CyberScoop investigation published June 18, 2026 provides the most complete public timeline for the campaign.

Here are the specific steps security researchers recommend:

• Pin GitHub Actions to specific commit SHA hashes, not mutable version tags
• Rotate all cloud credentials from CI environments that used Trivy, LiteLLM, or Checkmarx KICS between March and May 2026
• Remove confirmed malicious images: aquasec/trivy:0.69.4, 0.69.5, and 0.69.6
• Audit and re-verify all VS Code extensions that auto-updated during May 2026
• Review AWS Secrets Manager and IAM roles accessible from affected CI environments

Amitai Cohen, head of the attack vector intel team at Wiz, who has been tracking this campaign from the start, said: “You can’t keep existing in a world where you wake up every morning and some super prevalent package is compromised and everybody’s just going to be using it like nothing. We need to start taking this a bit more seriously.”

The core problem is not just technical. The software industry has known for years that the open-source trust model has serious gaps. The TeamPCP Chaos Crusade ran through those gaps faster than anyone was prepared to handle.

For further technical indicators of compromise and a full attribution breakdown of the Shai-Hulud framework, The Register’s reporting on the open-sourcing of the worm is worth reading directly.

The post TeamPCP Chaos Crusade: 1,000+ Open-Source Packages Hit appeared first on Tomaro Group.

What the Databricks Panther Labs Deal Actually Is

Databricks Panther Labs is a combination built to solve one urgent problem. Attackers today use AI tools to find and exploit software vulnerabilities faster than any human security team can respond. The acquisition comes as cybersecurity teams face a growing challenge: attackers are using AI to identify and exploit software vulnerabilities at unprecedented speed.

Panther Labs is an AI SOC platform. It pulls security-relevant data from across an organization into a single place. Then AI agents scan that data, detect threats, and trigger responses with minimal human input. Panther Labs was last valued at $1.4 billion after a $120 million Series B round in 2021, with backers including Snowflake Ventures and Coatue.

If you’ve been following the latest developments in enterprise cybersecurity threats, this kind of AI-driven SOC platform is exactly what security teams have been asking for.

Who Built Panther Labs and What It Does

Panther Labs was founded by the leader of the open source StreamAlert project originally created at Airbnb, and has grown into a cloud-native SIEM and AI SOC platform built on detection-as-code and security data lakes. The founder and CEO is Jack Naglieri.

The platform works differently from traditional SIEMs. Instead of manually writing alert rules, security engineers write detection logic in Python. An AI module can also generate that code from a simple plain-language prompt. If a false positive happens, a separate AI module traces the root cause and suggests a code fix automatically.

Panther uses filters that remove unnecessary parts from system log data, cutting data collection costs while helping organizations secure more of the data needed for intrusion analysis. It organizes collected data into an easy-to-analyze format and applies customers’ pre-built detection code to identify signs of threats within the data.

Databricks Panther Labs combined will offer over 100 pre-built data integrations out of the box. These cover cloud infrastructure, identity providers, SaaS applications, network systems, and endpoints.

The AI startup funding wave in 2026 has been pouring into exactly this kind of agentic security infrastructure. Panther Labs was built at the center of that wave.

Why Databricks CEO Said Legacy SIEM Is “Dead”

Databricks CEO Ali Ghodsi did not hold back at the Summit. Speaking to Reuters during the company’s Data + AI Summit, Ghodsi said: “If they’re going to attack you with agents, you have to defend with agents. You have to fight fire with fire.”

He has a point. SIEMs are held back by high costs, limited data, and manual, labor-intensive workflows. As a result, most organizations analyze only a fraction of their security data, leaving them blind to many of the new agent-driven attacks in their environments.

The Databricks Panther Labs approach replaces that. Instead of manually triaging every alert, the platform automates investigation from the moment a threat surfaces. Ghodsi called the old model dead and said Databricks Panther Labs would replace it with an agentic, always-on defense layer.

The scale of damage possible when threat detection lags is well documented. Events like the GitHub breach that exposed 3,800 repositories through a compromised coding tool show exactly what happens when attackers move faster than defenders.

Lakewatch and Panther Labs: How They Work Together

In March 2026, Databricks launched Lakewatch, its own agentic SIEM product. Lakewatch collects and analyzes security logs from multiple sources within a governed data lakehouse environment.

The planned integration of Panther into Lakewatch includes embedding AI agents directly into core SOC workflows to automate triage and suggest contextual next steps when handling security alerts.

That is the core of what Databricks Panther Labs delivers together. No more hand-managing data ingestion. No more writing detection rules by hand. No more investigating every alert manually. The AI agents do that work continuously, at scale.

Panther Labs also has its own query language called PantherFlow, which lets analysts move through large data sets faster. The Databricks Panther Labs combination gives security teams 100+ pre-built, deeply parsed integrations across critical cloud infrastructure, identity providers, endpoints, networks, and SaaS applications, delivering immediate, out-of-the-box ingestion without the complex mapping required by legacy SIEMs.

Anthropic is among Panther’s customers, with Tim Nguyen, Head of Defense at Anthropic, saying: “Building frontier AI requires security operations that are programmable and deeply integrated with the way modern engineering teams work. Panther has helped us bring a software engineering approach to detection and response.”

Anthropic, which recently released Claude Opus 4 with major coding advances, is exactly the kind of AI-native organization that needs this level of security infrastructure. The fact that they trusted Panther Labs before the Databricks Panther Labs deal was announced speaks clearly.

For Databricks Panther Labs, the Lakewatch connection means customers already using Databricks for data and analytics can now layer enterprise-grade SOC automation on top of the same platform. No separate vendor. No additional SIEM licensing. Just one security lakehouse.

Databricks’ Three Cybersecurity Acquisitions in 2026

The Databricks Panther Labs acquisition does not stand alone. It is the third cybersecurity deal the company has made in a short stretch.

In March 2025, Databricks acquired Antimatter, a security startup that specializes in data protection, authorization, and secure governance for AI agents. That deal was kept confidential until March 2026, when Databricks launched Lakewatch. The same month, Databricks also bought SiftD.ai, an early-stage security startup focused on agentic AI-human collaboration tools and deep expertise in large-scale detection engineering.

Now with Databricks Panther Labs, the stack is more complete. Antimatter handles data governance and protection. SiftD handles automated incident response. Panther Labs handles detection, investigation, and agentic SOC workflows. Lakewatch ties it all together as the unified platform underneath.

This kind of aggressive M&A strategy in cybersecurity mirrors what we saw earlier this year with large-scale AI infrastructure investments like the Google and Blackstone $5 billion partnership. Major tech players are not waiting for the market to come to them.

Databricks is reportedly considering a new funding round that could begin within the next month, potentially boosting its valuation to between $165 billion and $175 billion.

What Enterprise Security Teams Should Know

For security professionals, the Databricks Panther Labs deal has real practical implications.

First, it signals that the SIEM market is under serious pressure. The deal marks Databricks’ push to challenge industry incumbents like CrowdStrike and Cisco Systems’ Splunk as it moves to offer AI agents that detect and mitigate digital threats with minimal human intervention.

Second, Databricks Panther Labs addresses a real coverage problem. Most enterprise security teams today are not analyzing all of their data. The cost and manual effort required by older platforms means threats can hide in the logs that never get reviewed.

Panther’s platform includes natural-language detection authoring, automated false-positive root-cause analysis, and supports customer-provided detections implemented in Python. That makes it accessible to security engineers who work the way modern software teams do, with code, automation, and version control rather than static point-and-click dashboards.

The damage from gaps in security coverage can be severe. As seen in the Coinbase insider attack that resulted in roughly $400 million in losses, the cost of not having full visibility into your security data is enormous. The Databricks Panther Labs platform is designed to close exactly those kinds of blind spots.

Jack Naglieri, CEO of Panther Labs, put it clearly in his statement: “The SOC is at an inflection point. AI is changing how attacks are launched and defenders can now finally keep pace with them. Together with Databricks, we can arm defenders with sophisticated agents that scale detection, investigation, and response.”

Final Thoughts

The Databricks Panther Labs acquisition is one of the most significant cybersecurity moves of 2026 so far. Databricks is no longer a data analytics company that dabbles in security. With Lakewatch, Antimatter, SiftD, and now Databricks Panther Labs, it is building a full-stack security platform designed for the AI era.

The legacy SIEM model was not built to handle the speed of AI-driven attacks. Databricks Panther Labs is betting that the security lakehouse can replace it. Given the company’s reach across 70% of Fortune 500 data teams, that bet has real weight behind it.

The post Databricks Panther Labs to Replace Legacy SIEM appeared first on Tomaro Group.

This is what happened, what the government ordered, and what Anthropic is saying about it.

What Is Claude Fable 5?

Anthropic launched Claude Fable 5 on June 9, 2026. It was the first publicly available model in the company’s new “Mythos-class” tier, one level above the previous Opus-class lineup. Anthropic described it as the most capable model it had ever released to the public.

Fable 5 was built to excel at software engineering, code analysis, and identifying flaws inside existing codebases. That specific capability is exactly where the Fable AI security concerns would later take root.

The model came with a layered safety design. When a query touched high-risk areas like cybersecurity, biology, chemistry, or AI model distillation, Fable 5 would silently pass the request to a weaker model, Claude Opus 4.8, instead of answering directly. Anthropic reported that more than 95% of all Fable 5 sessions never triggered this fallback.

Alongside the public model, Anthropic operated Mythos 5. That version ran with fewer guardrails and was limited to vetted cybersecurity researchers and government partners only. It was never open to general users.

Those earlier Anthropic model milestones that built up to this launch are covered in our report on Anthropic’s Claude Opus 4 and Sonnet 4 release and its coding advances.

How the Fable AI Security Concerns Began

The Fable AI security concerns surfaced within 24 hours of launch. A researcher going by “Pliny the Liberator” posted on social media claiming to have bypassed Fable 5’s safety classifiers the day after the model went live.

The method reportedly did not involve a traditional software bug. Based on cybersecurity reports, the approach used Unicode character substitutions, look-alike Cyrillic letters, multi-agent task decomposition, and narrative framing to trick Fable 5’s keyword classifiers into ignoring flagged requests.

Screenshots that circulated publicly appeared to show step-by-step instructions for stack buffer overflow exploits on x86 Linux systems. The researcher also claimed to have extracted Fable 5’s 120,000-character system prompt during the attempt.

These Fable AI security concerns spread quickly through the security research community. Debate started immediately over whether this counted as a real jailbreak or a demonstration of weaknesses that already existed in every major model.

The timing of the Fable AI security concerns made things worse. Anthropic had acknowledged at launch that Fable 5’s capabilities in identifying software vulnerabilities “exceed those of any model we’ve ever made generally available.” Security professionals had already warned before release that a model this capable in vulnerability identification could be weaponized if its safeguards were bypassed.

The pattern fits into what our team has been watching across AI-adjacent security incidents, including the supply chain security threats that hit organizations throughout 2026.

What Anthropic Said About the Jailbreak

Anthropic disputed the claim that a real jailbreak had occurred and conducted a wider review of recent usage, finding no evidence that its safeguards had been successfully bypassed to generate genuinely dangerous content.

After reviewing the reported technique, Anthropic found only a small number of previously known, minor vulnerabilities. Critically, the company said those same vulnerabilities were already discoverable using other publicly available models without any bypass at all.

Anthropic validated that the level of capability displayed in the underlying report was widely available from other models, including OpenAI’s GPT-5.5 cybersecurity evaluations.

This was Anthropic’s core argument: the Fable AI security concerns raised by this jailbreak did not represent any unique risk that did not already exist elsewhere in the market.

External red teams working before launch found no universal jailbreaks on long-form agentic tasks, though Anthropic conceded it is likely impossible to fully prevent universal jailbreaks in the future. The company’s stated goal was to make them slow and costly enough to detect before they could be used at scale.

Still, the Fable AI security concerns had already reached Washington by then.

The US Government Directive

The Fable AI security concerns triggered a government response on June 13, 2026. The directive, received at 5:21 PM ET, prohibits any foreign national, whether located inside or outside the United States, from accessing the two models, including foreign national Anthropic employees.

The letter came from Commerce Secretary Howard Lutnick under the authority of the US Department of Commerce.

Because Anthropic had no real-time way to verify each user’s citizenship, the company disabled both Fable 5 and Mythos 5 globally for all customers to ensure full compliance. Access to every other Anthropic model remained unaffected.

According to CNN’s reporting, the government cited national security concerns but did not provide specific details to Anthropic, though the company believes the government became aware of a method of jailbreaking Fable 5.

You can find our full breakdown of the immediate fallout in our dedicated report on the US government’s decision to block Anthropic’s Fable 5 access.

What Export Controls Now Apply

Under the Commerce Department directive, a license is now required for the export, re-export, or domestic transfer of Fable 5 and Mythos 5 to any foreign person. Anthropic must also submit applications for individually validated licenses. Failure to comply would result in financial and civil penalties.

This places the Fable AI security concerns in a regulatory category normally reserved for military hardware and advanced dual-use technology. It is one of the most sweeping actions the US government has taken against a commercially deployed AI model.

Experts warned before launch that Fable 5 was particularly effective at identifying software vulnerabilities, and the model’s capabilities posed a risk of being used in cyberattacks.

The type of breach risk that prompted this response is something security teams have been confronting across all fronts this year. Our reporting on the GitHub breach that hit 3,800 repositories after a hacked coding tool shows just how fast a single vulnerability can escalate.

How Anthropic Is Pushing Back

Anthropic complied with the directive immediately but made its disagreement public. In its official statement published on June 13, the company argued that if this standard were applied across the industry, it would effectively halt every new frontier model deployment.

On the specific Fable AI security concerns cited by the government, Anthropic stated the jailbreak demonstrated essentially involved asking the model to read a codebase and identify software flaws, a task security professionals perform with publicly available tools every single day.

Anthropic’s position is that the vulnerability was benign. According to Anthropic’s own reading of the government’s underlying concern, the demonstration essentially consisted of asking the model to read a specific codebase and fix any software flaws.

Anthropic’s full position on the Fable AI security concerns rests on its defense-in-depth strategy. This security framework focuses on confining non-universal jailbreaks to an exceptionally narrow scope, making developing universal jailbreaks economically prohibitive, and deploying continuous telemetry monitoring to rapidly detect and shut down active attacks. The company also enforces a 30-day customer data retention policy for Mythos-class models to support continuous threat hunting and patch development.

The company ended its statement by saying it believes this is a misunderstanding and is working to restore access as soon as possible.

What This Means for Developers and Users Right Now

The Fable AI security concerns have had a direct and immediate practical impact. Anyone who had built workflows or production pipelines on Fable 5 or Mythos 5 lost that access without warning on the evening of June 13.

All other Anthropic models are still live. Claude Opus 4.8, Claude Sonnet 4.6, and the rest of the lineup remain fully operational. Only Fable 5 and Mythos 5 are offline.

The broader lesson the Fable AI security concerns carry for developers is a serious one. Frontier AI capabilities are now formally treated as national security assets by the US government. Access can be pulled with minimal notice and without detailed public explanation. Building critical workflows on the most advanced AI models now carries a regulatory risk that simply did not exist at this scale a year ago.

For teams tracking what Anthropic’s intermediate model tier can still do while Fable 5 remains offline, our earlier report on Claude Opus 4.7’s expanded agentic capabilities covers the full picture.

Where Things Stand on June 15, 2026

Fable 5 and Mythos 5 remain disabled globally as of today. According to an administration official, the model needs to remain locked down until the US government’s national security apparatus is hardened, and that could happen within the next few weeks.

Anthropic has said it is actively working with the government on a path to restore access under terms that address the Fable AI security concerns without permanently blocking the models. No specific date has been given.

The core dispute comes down to one question. Does a narrow, non-universal jailbreak in a heavily guarded commercial AI model justify a full recall and export control designation? Anthropic says the Fable AI security concerns raised here do not meet that bar. The US government concluded otherwise.

For now, developers should plan around Anthropic’s other available models and monitor Anthropic’s official channels for updates on Fable 5’s return.

The post Fable AI Security Concerns: US Blocks Anthropic Models appeared first on Tomaro Group.

This year has already seen a wave of real attacks affecting major organizations. The lesson is clear: you cannot just protect your own systems anymore. You have to think about everyone connected to you.

What Is Supply Chain Security and Why Does It Matter Now?

Supply chain security focuses on protecting not just your own systems, but the vendors, software providers, and service partners that your organization trusts. Instead of attacking victims directly, threat actors compromise one upstream supplier and then use that access to reach dozens or even hundreds of downstream organizations through legitimate integrations, OAuth tokens, and shared infrastructure.

In other words, the attacker does not need to break down your front door. They just need to compromise someone you already trust, like a software library, a CI/CD tool, or a third-party vendor.

According to the World Economic Forum, over half of large organizations now identify supply chain complexity as the single greatest barrier to cyber resilience, ranking it above concerns about direct attacks.

That is a significant shift. Boards and security leaders can no longer treat supply chain security as a niche problem for developers to solve alone.

The Biggest Supply Chain Security Incidents of 2026 So Far

This year has already produced several serious attacks that show how fast these threats move.

The TanStack / TeamPCP Campaign

The most significant software supply chain incident of 2026 involved the compromise of popular TanStack packages used extensively across modern development environments. Threat actors associated with TeamPCP distributed malicious versions of trusted packages designed to steal GitHub credentials, cloud secrets, SSH keys, and CI/CD tokens.

OpenAI was among the organizations affected. After the Axios incident, OpenAI accelerated the deployment of specific security controls, including further hardening of sensitive credential materials used in their CI/CD pipeline, deployment of package manager configurations, and additional security software to validate the provenance of new packages.

The cybersecurity community was watching these events closely, and many organizations rushed to review their own exposure.

The Checkmarx Breach

On March 23, 2026, Checkmarx identified a cybersecurity supply chain incident affecting certain developer artifacts distributed through third-party channels. Attackers gained unauthorized access to Checkmarx’s GitHub repositories due to the Trivy Supply Chain Attack. This access enabled the publication of malicious code to VS Code extensions, GitHub Actions workflows, and a Jenkins plugin.

This one is a stark reminder that even security companies themselves are not immune to supply chain security failures.

The Red Hat npm Namespace Attack

On June 1, 2026, a new supply chain attack compromised at least 32 packages published under the @redhat-cloud-services npm namespace. The attacker bypassed code review entirely, pushing a payload named Miasma.

This attack followed a pattern that security teams had been warning about for months.

If you follow recent cybersecurity developments, you may have also noticed a similar trend with the GitHub breach that hit 3,800 repositories earlier this year, another example of how attackers target the tools developers rely on daily.

How AI Is Making Supply Chain Security Harder

Artificial intelligence is changing both sides of this equation. Defenders use AI to detect threats faster. But attackers are using it too, and so far the attackers seem to be moving faster.

Group-IB’s 2026 forecast warns that AI-assisted tooling will compress attack timelines from weeks to hours, identity will overtake malware as the dominant intrusion mechanism, and multi-tenant breaches through CRM, ERP, and marketing automation platforms will become more common.

There is also a growing risk from AI-generated code. Only 1 in 5 AI-suggested dependency versions were safe to use, with 80% containing risks from hallucinations or known vulnerabilities. In addition, GPT-5 hallucinated 27.8% of component version recommendations and in some cases suggested actual malware packages.

That is a serious problem when 39% of developers accept AI-generated code without any revision, according to the same data.

The JFrog 2026 Software Supply Chain Security report found that AI-driven development is accelerating malicious package activity, insecure AI tooling, and software supply chain governance gaps across enterprises. Researchers also identified nearly 500 malicious AI models in public registries capable of credential theft.

For companies building or integrating AI tools, this adds a whole new layer to supply chain security that many teams are not yet equipped to handle. The growing conversation around AI leadership and what it means for business operations is directly connected to how organizations respond to these threats.

What Governments Are Doing About It

Regulators are not sitting still. In May 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), alongside G7 partners including Germany, Canada, France, Italy, Japan, the U.K., and the European Union, released new joint guidance aimed at strengthening transparency and cybersecurity across artificial intelligence supply chains. The guidance document outlined minimum elements for implementing an SBOM for AI to improve transparency and cybersecurity along the supply chain.

An SBOM, or Software Bill of Materials, is basically a full ingredient list for your software. It tells you every component, library, and dependency in your system so you can quickly identify what is at risk when a vulnerability surfaces.

For businesses that work with federal contracts or operate in regulated industries, this kind of regulatory push has real compliance implications.

The Top Supply Chain Security Risks to Watch

In 2026, supply chain security campaigns have matured beyond one-off vendor compromises into sophisticated operations that exploit every layer of the tech stack, from tampered software to compromised hardware and breached service providers. Attackers target places where visibility is thin and trust runs high, including package repositories, collaboration tools, service providers, and third-party add-ons that nobody properly vets.

Here are the specific risk areas getting the most attention this year:

Dependency confusion attacks. Rather than scattershot attacks, 2026 attacks are now researched. Attackers scrape job postings, GitHub repositories, error messages in public issue trackers, and even Docker layer metadata to identify internal package names before registering malicious public packages with the same name.

Shadow IT. The proliferation of cloud-based tools and remote work platforms has made shadow IT a persistent blind spot. Employees adopt unvetted SaaS solutions to improve productivity, and these applications operate outside formal procurement and security reviews, creating invisible attack surfaces.

CI/CD pipeline compromise. Once inside a build pipeline, attackers move beyond just stealing secrets. They clone repositories the runner has access to, modify build artifacts before they are signed, and persist through self-hosted runner configurations that survive pipeline reruns.

These risks are tightly connected to the broader cybersecurity vulnerabilities that businesses are dealing with in 2026, including the recent Coinbase breach and others affecting enterprise software.

How to Strengthen Your Supply Chain Security Today

You do not need to solve everything at once. But there are practical steps that reduce risk significantly.

Build and maintain an SBOM. Maintain an up-to-date Software Bill of Materials and inventory of open-source and third-party components. Scan codebases and container images for known vulnerabilities as part of the CI/CD pipeline. Use software composition analysis tools early in development to block high-risk libraries before they enter production.

Monitor vendors continuously. Rather than relying on point-in-time questionnaires, adopt continuous monitoring of critical suppliers. This can include shared threat intelligence feeds, API integration with vendors’ security tools, or ongoing scanning of their exposure including open ports and patch levels.

Apply least privilege everywhere. Apply least privilege access controls, MFA, and environment segmentation across developer systems, repositories, and CI/CD infrastructure. Also conduct secure code reviews and validation processes for AI-generated code, third-party packages, and externally sourced AI models before deployment.

Practice your response. Responding to supply chain incidents, especially those involving compromised software updates or hardware, often requires costly forensic investigations, mass patching programs, and legal or regulatory settlements. Preparation before an incident can significantly reduce the damage and cost.

The supply chain security posture of your organization is directly tied to your overall business resilience. Leaders who want to build strong teams and resilient operations need to treat this as a board-level priority, not just a technical checkbox.

The Bottom Line

Supply chain security in 2026 is not optional. Attacks are more targeted, more automated, and hitting organizations of every size. The good news is that most of the defenses are not complicated. They require discipline, visibility, and the willingness to treat your vendors as part of your security perimeter.

The organizations that avoided the worst of this year’s incidents were the ones that already had layered defenses in place: signed artifacts, pinned dependencies, short-lived credentials, and continuous vendor monitoring. That is the standard to aim for now.

The post Supply Chain Security Threats and Fixes in 2026 appeared first on Tomaro Group.

The flaw was disclosed on May 28, 2026 by security researcher Asim Manizada, who posted full details and a working proof-of-concept to the oss-security mailing list. The CVE was assigned on June 1. Patched kernels reached production repositories on June 2.

There is a second piece of news worth knowing. In early June, the U.S. Cybersecurity and Infrastructure Security Agency added a separate Linux kernel vulnerability to its Known Exploited Vulnerabilities list and gave federal agencies until June 5 to fix it. So this is a busy stretch for anyone running Linux.

What this Linux kernel vulnerability actually does

CIFSwitch lives in the Linux kernel’s CIFS client, the part that lets Linux mount and read Windows-style network file shares. The bug sits in the SPNEGO authentication path. In short, the kernel fails to properly check a key description before it acts on it. The root cause is missing validation in the cifs.spnego key type, according to a security alert published by CUHK’s IT services team.

Here is the part that makes people nervous. This Linux kernel vulnerability has been in the code since 2007. That is 19 years. It sat there, unnoticed, until someone took a close look at how the kernel trusts these authentication requests.

An unprivileged user can forge a key request and trick the kernel into running a helper program as root. From there, the attacker controls what that program loads and runs. The result is a root shell.

This is a local flaw, not a remote one. An attacker needs a way to run code on the machine first. That foothold can come from many directions: a stolen developer login, a compromised web process, a malicious build job, or a container with too much access. We have seen how quickly one weak point spreads. A hacked coding tool recently reached thousands of GitHub repositories before anyone caught it.

Not the first Linux kernel vulnerability of 2026

CIFSwitch is the fifth Linux kernel vulnerability of its kind reported this year. The list now includes Copy Fail (CVE-2026-31431) on April 29 with a CVSS score of 7.8, Dirty Frag (CVE-2026-43284) on May 7, Fragnesia (CVE-2026-46300) on May 13, ssh-keysign-pwn (CVE-2026-46333) on May 21, and now CIFSwitch on May 28.

So why so many at once? It is not that the kernel suddenly got worse. The Linux kernel team became an official CVE Numbering Authority in 2024. Since then, it has started assigning CVE numbers to old, undocumented bugs. Researchers are also digging through code paths that no one had reviewed in years. CIFSwitch is a good example. The flaw dates to 2007 and went unexamined for nearly two decades.

For administrators, the routine is familiar. Apply the quick mitigation now, then schedule the kernel update and reboot. It is the same steady patch work IT teams handled during Microsoft’s May patch cycle.

CISA flags a separate Linux kernel vulnerability

The CISA warning is about a different bug, CVE-2022-0492. It is an improper authentication flaw tied to the cgroups v1 release_agent feature. Cgroups handle resource limits and isolation, and they are everywhere in containers and cloud setups.

A local attacker can abuse the release_agent function to run commands with elevated privileges. In a container, that can mean breaking out and taking over the host. CISA placed this Linux kernel vulnerability in the Known Exploited Vulnerabilities catalog, which signals credible evidence that attackers are using it. Federal agencies had until June 5 to patch under Binding Operational Directive 22-01. Private organizations are not bound by that deadline, but the message is the same: do not wait.

CISA has raised this kind of alarm before, including for five zero-days under active attack flagged last month.

Who needs to pay attention

CIFSwitch does not hit every machine. Three conditions have to line up at the same time. The system needs cifs-utils installed (version 6.14 and higher is the main concern). It needs unprivileged user namespaces turned on. And it needs the CIFS kernel module loaded. On several popular distributions, those three sit there by default.

The list of affected distributions is broad. Red Hat, Ubuntu, Debian, SUSE, Oracle Linux, and Amazon Linux can all be exposed to this Linux kernel vulnerability, depending on how they are set up. Red Hat rates the issue as Important and notes that products built on its enterprise kernel, including OpenShift, may also be affected, per its vulnerability advisory.

The bigger risk is patch speed. The Verizon 2026 Data Breach Investigations Report found that organizations take a median of 43 days to fix critical bugs. With a public exploit available, that window is plenty of time for an attacker who already has local access. The same lesson showed up when an insider attack cost Coinbase about $400 million: once someone has access, damage moves fast.

What to do now

Start by checking exposure. See whether cifs-utils is installed, whether the CIFS module is loaded, and whether unprivileged user namespaces are enabled. If you do not mount Windows or SMB shares, you likely do not need CIFS at all.

My advice is simple: break one of those three conditions today. Remove the cifs-utils package, blacklist the CIFS kernel module, or disable the cifs.spnego request-key rule. Breaking any single condition stops the attack chain. Turning off unprivileged user namespaces also helps, and it limits other kernel flaws too.

Then do the real fix. Patching the kernel is the only lasting fix for this Linux kernel vulnerability. Apply the patched kernel from your distribution. The upstream fix is already merged, and vendor updates have been rolling out since June 2. Reboot when your maintenance window allows.

For the CISA-listed cgroups flaw, the steps rhyme: update to a patched kernel, restrict access to cgroup settings, and turn off unprivileged user namespaces where you can. Watch container environments for odd activity around cgroup changes.

We will keep tracking these privilege-escalation flaws and breach reports as patches and details land.

The short version

A 19-year-old Linux kernel vulnerability, CIFSwitch, now lets a local user grab root in one command, and a working exploit is public. CISA has flagged a separate kernel flaw as actively exploited. Patches exist for both. Check your systems, apply the quick mitigation today, and schedule the kernel update. Linux runs much of the internet’s plumbing, so a few hours of patch work now can save a lot of cleanup later.

FAQs

The post Linux Kernel Vulnerability Hands Local Users Full Root appeared first on Tomaro Group.

The May 2026 Patch Tuesday rollout landed on May 13, and security teams have been scrambling since. The actively exploited bugs touch the Windows kernel, Common Log File System, Scripting Engine, DWM Core Library, and Microsoft Excel. All five received CVSS scores above 7.0, and three allow attackers to gain SYSTEM-level access on a target machine.

If you missed the recent reports on skills-based hiring shifts, cybersecurity roles continue to top the demand list, and incidents like this explain why. Many of the same companies tracking AI skills as a career growth route are also doubling their patching budgets.

What the Zero-Days Actually Do

Two of the exploited bugs, CVE-2026-30397 and CVE-2026-30400, are elevation-of-privilege flaws. They let an attacker who already has limited access on a Windows machine push their permissions up to SYSTEM. From there, almost any further action is possible, including installing tools, creating accounts, or moving across a network.

CVE-2026-30401 affects the Scripting Engine in Microsoft Edge and older Internet Explorer components still embedded in Windows. It can be triggered by a malicious webpage. The Excel flaw, CVE-2026-30454, fires when a user opens a crafted spreadsheet, with no macros needed.

According to the official Microsoft Security Response Center advisory, exploit code for several of these bugs is now public.

Who Is Being Targeted

Early reports from threat researchers point to a financially motivated group called Storm-2460 deploying ransomware through the CLFS bug. Hospitals and small banks in Europe and North America appear to be the main targets. The Cybersecurity and Infrastructure Security Agency added all five flaws to its Known Exploited Vulnerabilities catalog on May 14, giving federal agencies three weeks to patch.

Private firms are not on that deadline, but most large enterprises are following the same window. The pattern here resembles last year’s CLFS exploitation, which also fed a wave of ransomware attacks.

Why This Round Stands Out

Five active zero-days in a single Patch Tuesday is unusual. Microsoft typically discloses two or three. The volume suggests attackers are stockpiling Windows bugs and burning them faster than vendors can detect. Apple and Google have seen similar trends this year.

For business owners watching the broader picture, the cost of a single ransomware case can wipe out a quarter of profit. The same teams reading about corporate leadership skills for strong teams are now adding incident response drills to their quarterly planning.

What Admins Should Do Now

Patch the affected systems first. Workstations running Excel and Edge should be prioritized since those two flaws need only a user interaction. Servers running CLFS-dependent services follow next.

Disable legacy scripting components if your environment does not need them. Block macro-enabled attachments at the email gateway. And review endpoint detection logs for the last 30 days, since some of these exploits were used in the wild well before disclosure. Reuters reported that at least four confirmed breaches in April traced back to one of the patched bugs.

Smaller firms without a dedicated security team should lean on managed detection services this quarter. The threat landscape is moving faster than monthly patch cycles can handle on their own.

The Bigger Picture

This round of fixes also points to a wider shift. Attackers are not waiting for disclosure anymore. They are finding and using flaws before vendors know about them. That changes the math for defenders, who now need to assume some level of compromise at all times.

The teams handling this best are the ones treating cybersecurity as a continuous practice, not a quarterly checklist. For founders watching their burn rate, this means budgeting for tools and people, not just compliance audits. Similar pressure is reshaping career paths inside business operations, where security literacy is now expected at the manager level.

The May 2026 patches close known holes. They do not stop the next wave. Staying current with monthly updates is the floor, not the ceiling.

The post Microsoft Confirms May 2026 Patch Tuesday Fixes Five Active Zero-Day Flaws appeared first on Tomaro Group.

The breach affects less than 1% of Coinbase users, but the data exposed is serious. Names, addresses, partial Social Security numbers, masked bank account details, government ID images, and account balances were all accessed. No passwords, private keys, or funds were taken, according to the company.

If you’re tracking how this fits into the broader threat landscape, our technology coverage hub and our running cybersecurity news section have more context on related incidents. Workforce and insider risk also tie into workplace trends shaping 2026, which is worth a look for HR and security leads.

What Actually Happened at Coinbase

The attackers did not break in through code. They bribed customer support contractors based outside the United States to pull internal records. The criminals then demanded a $20 million ransom from Coinbase to keep the stolen data quiet.

Coinbase refused to pay. Instead, the company posted a $20 million bounty for information leading to the arrest of those responsible. Chief Security Officer Philip Martin said the firm fired the involved support agents and referred them to law enforcement.

The Securities and Exchange Commission opened a separate inquiry into whether Coinbase overstated user numbers before its 2021 public listing. That probe is not tied to the breach itself, but the timing has put extra pressure on the stock. Shares dropped more than 7% the day the news broke, according to reporting from Reuters.

The Insider Threat Problem Is Getting Worse

The Coinbase attack is part of a clear pattern in May 2026. Insider-driven breaches now make up a growing share of high-cost incidents at US firms. Verizon’s 2026 Data Breach Investigations Report flagged a sharp rise in cases where staff or contractors were paid, pressured, or tricked into leaking data.

Banks, exchanges, and large retailers are the main targets. The attackers want identity data they can resell or use for SIM-swap attacks on crypto wallets. That makes anyone holding KYC documents a high-value target.

For business leaders trying to keep teams secure, the lesson is simple. Background checks and access controls matter just as much as firewalls. Our piece on corporate leadership skills that build strong teams touches on the trust and accountability side of this issue.

Marks and Spencer, Co-op, and the UK Retail Wave

Across the Atlantic, UK retailers are dealing with their own May crisis. Marks and Spencer is still recovering from a ransomware attack tied to the Scattered Spider group. The company has paused online clothing orders and lost an estimated £300 million in operating profit for the year.

Co-op and Harrods reported intrusions in the same window. The UK National Cyber Security Centre warned other retailers to review their identity verification steps, especially around help desk password resets, which was the entry point used in several cases. The BBC has tracked the M and S timeline in detail.

What This Means for Everyday Users

If you have a Coinbase account or hold ID data with any major service, take three steps this week. First, turn on hardware-based two-factor authentication, not SMS. Second, freeze your credit at all three bureaus. Third, watch for phishing calls or texts that reference real details about your account, because attackers will use the leaked data to sound convincing.

Coinbase will reimburse customers who were tricked into sending funds because of this breach. The company is also moving some support operations to the US and rolling out additional ID checks for high-value withdrawals.

For workers thinking about a pivot into security roles, demand is climbing fast. Our coverage of how AI skills are reshaping career growth in 2026 overlaps with the security hiring boom, since AI-driven threat detection is now a core skill in most SOC job postings.

The Bigger Picture

May 2026 has been a rough month for trust in digital platforms. The Coinbase incident, the UK retail attacks, and a fresh round of healthcare breaches in the US all share one root cause. Human access points are the soft spot. Software is getting harder to crack, so attackers are buying their way in through people.

Companies that invest in support staff training, tighter access logs, and faster incident response will weather this better. Those that treat security as an IT-only problem will keep showing up in headlines like this one.

I’ll keep tracking the Coinbase investigation as the SEC and DOJ updates roll out. For now, the safe move for users is to assume your data is in motion and lock down accounts accordingly.

The post Coinbase Confirms May 2026 Data Breach Linked to Insider Threat as SEC Probe Widens appeared first on Tomaro Group.

The disclosure landed on May 20, 2026, and quickly became one of the largest software supply chain incidents of the year. A group calling itself TeamPCP claimed responsibility and demanded a $50,000 ransom from GitHub, according to multiple security outlets. GitHub, owned by Microsoft, has not confirmed any ransom payment.

For more context on tech and security trends, see our coverage of skills-based hiring in 2026 and our full cybersecurity news section.

What happened inside GitHub

The attack started on an employee device. Hackers compromised a coding tool the employee had installed, then used that foothold to reach internal systems. From there, they pulled data out of about 3,800 internal repositories.

GitHub stresses that these were internal repos, not customer-owned code stored on the public platform. Public and private repositories belonging to users were not part of the stolen data set, based on the company’s current statement.

Still, the contents of internal repos can include service configuration files, deployment scripts, and notes that could help future attackers. Security researchers say even small leaks of that kind can lead to follow-on attacks on cloud services and CI/CD pipelines.

How the compromise spread

According to reporting from TechCrunch, the entry point was a third-party extension used by the GitHub employee. Once the tool was hijacked, the attackers harvested credentials and used them to access internal infrastructure.

This pattern is familiar. Over the past year, attackers have leaned on developer tools, browser extensions, and open source packages because they sit close to sensitive systems. A single hijacked plugin can hand attackers keys to many environments at once.

Eric Geller at Cybersecurity Dive noted the attack is “the latest example of hackers’ intense focus on open source packages.” That focus has pushed many large platforms to tighten how they review and sandbox developer tooling.

TeamPCP and the ransom demand

The attackers, identifying as TeamPCP, asked for $50,000 to keep the stolen contents private. The figure is small compared with ransom demands seen in healthcare or municipal hacks, which often run into the millions. Some researchers think the low number is meant to push GitHub toward a quick settlement.

GitHub has stayed quiet on whether it engaged the group at all. The company says affected teams have been notified, secrets have been rotated, and the employee account at the center of the incident has been locked down.

If you follow finance and business risk topics, our piece on corporate leadership skills touches on how teams handle moments like this.

Why this matters for developers

GitHub powers a huge share of software development worldwide. When the platform itself is touched by a breach, every team that builds on it pays closer attention.

Three near-term concerns stand out. First, any tokens, API keys, or webhook secrets that lived in those internal repositories must be treated as exposed. Second, anyone using a coding extension similar to the one abused here should audit installed tools. Third, build pipelines that pull dependencies from compromised sources may need fresh review.

The U.S. Cybersecurity and Infrastructure Security Agency has warned for months about supply chain risk. The CISA known exploited vulnerabilities catalog continues to add software supply chain entries each week. This incident fits that pattern.

The wider May 2026 picture

The GitHub story arrived during an already heavy month for security teams. The Canvas hack tied to Instructure disrupted schools and universities across the United States, with cybercrime group ShinyHunters claiming access to data on roughly 275 million teachers and students. The BBC reported that some universities lost access during finals week.

Verizon’s 2026 Data Breach Investigations Report, released earlier in May, found that vulnerability exploitation has overtaken phishing as the top entry point for breaches. The GitHub case lines up with that finding. The attack did not start with a tricked employee clicking a link. It started with a flaw in a trusted tool.

For readers tracking how artificial intelligence intersects with security, our look at AI skills and career growth covers the demand for security talent that can handle AI-driven threats.

What GitHub is doing next

GitHub says it is reviewing every approved developer extension and tightening how employee devices connect to internal systems. The company has also expanded its bug bounty scope to cover supply chain abuse paths.

For users, GitHub recommends rotating any personal access tokens created before May 20, 2026, reviewing third-party application permissions in account settings, and enabling secret scanning on private repos. Organizations using GitHub Enterprise should audit recent commits for unexpected changes.

The investigation is ongoing. Federal authorities have been informed, though GitHub has not named which agencies are involved.

Bottom line

The GitHub breach is a sharp reminder that the tools developers trust most often become the path attackers take. A single compromised extension on one employee’s machine led to thousands of repositories being pulled. The fallout will shape how Microsoft and other big platforms vet developer software for the rest of the year.

Stay with Tomaro Group for updates as the investigation moves forward.

The post GitHub Breach Hits 3,800 Repositories After Hacked Coding Tool appeared first on Tomaro Group.