The new front line of application security

Developers across the planet are under attack. Mythos showed this is only the beginning

Every so often the industry gets news after which you can no longer pretend everything is following the old script. In the spring and summer of 2026, two such pieces of news arrived at once.

The first is a new wave of attacks on software supply chains. Attackers have shifted their focus far deeper — away from users’ computers and servers and onto the machines and tools of the developers who build software. This isn’t a single attack or a single compromised package, but a whole tangle of them: Megalodon, Mini Shai-Hulud, Glassworm, and compromises of npm, PyPI, GitHub Actions, VS Code and OpenVSX extensions, as well as CI/CD environments and OIDC tokens.

The second is the interim results of Anthropic’s Project Glasswing and its Claude Mythos Preview model. It has already found thousands of serious vulnerabilities in critically important software. Its productivity is telling. In just a few weeks, Mythos and around 50 Anthropic partners uncovered roughly 23,000 findings, of which more than 6,000 are high- and critical-severity vulnerabilities. For comparison: across all of 2025, about 48,000 CVEs were registered worldwide. In other words, a single tool produced, in weeks, a stream of findings comparable to several months of vulnerability registration across the entire planet.

Both stories are signs of a new front line in the war with attackers — and of a fundamental shift in application security. Let’s look at this news more closely, starting with the first.

Attacks on the software factory

The SolarWinds incident in 2020 became one of the first major blows to the supply chain. Attackers planted the SUNBURST backdoor in the SolarWinds Orion platform. Other high-profile episodes followed.

Codecov (2021) was a painful lesson for continuous integration (CI). A modified Bash Uploader could exfiltrate environment variables, keys, tokens and other secrets from CI environments.

Log4Shell (2021) showed how dangerous a single vulnerability in a widely used library can be. It wasn’t a classic supply-chain compromise, but the blow came through a dependency embedded in a vast number of systems. CISA, the FBI, the NSA and other agencies issued joint guidance on mitigating the risk.

3CX (2023) demonstrated something even more unpleasant — one supply-chain attack can become the entry point for another. Mandiant described a rare cascading case in which the compromise of one supplier (Trading Technologies) led to the compromise of another — the 3CX desktop application.

XZ Utils (2024) read almost like a spy novel. A backdoor made its way into the upstream tarballs of xz/liblzma, and the problem was noticed because of an odd load during SSH logins. NVD describes CVE-2024-3094 as malicious code injected into the xz sources starting with version 5.6.0, with sophisticated obfuscation and interference in the liblzma build process.

The current wave differs from all of these stories. Attackers used to strike at a finished product, an update or a specific supplier. Now they increasingly hit “the whole area” — the software factory itself: developers, IDEs, extensions, CI/CD, GitHub Actions, npm and PyPI, OIDC, secrets and publishing processes. Figuratively speaking, this is closer to swapping out the “assembly line” than swapping a “box on the warehouse shelf,” as before.

A chronicle of the new wave

Megalodon: six hours and 5,561 repositories. According to SafeDep, on 18 May 2026 an automated campaign injected malicious changes into 5,561 public GitHub repositories (more than 5,700 commits) within a six-hour window. The attacker added workflow files disguised as routine CI optimization. The application code might not be touched at all. Instead, the pipeline began stealing cloud credentials, SSH keys and OIDC tokens.

Here’s an important nuance. Many teams still review only application code. But if the malicious logic lives in a workflow, a runner, an action or a publish job, ordinary code review will easily miss it. The repository looks “fine,” yet the secrets are already gone.

Mini Shai-Hulud: when a trusted build ships an untrusted package. On 11 May 2026, between 19:20 and 19:26 UTC, 84 malicious versions were published across 42 packages in the @tanstack/* family. The packages were not published via a stolen npm password. They were published by TanStack’s legitimate release pipeline, using its trusted OIDC identity, after the attacker hijacked the runner mid-workflow.

And this is where the familiar picture breaks down. If there’s a signature, if provenance is verified, if the build ran “correctly” — can you trust the package? Not always. Snyk states it plainly: SLSA provenance confirms which trusted process built the package, but does not guarantee that the code fed into that process is safe. This is, by available accounts, the first documented case of malicious npm packages carrying a valid SLSA Build Level 3 attestation. Aikido estimated the scale of the entire wave at 373 malicious versions across 169 package names.

The @antv attack. Snyk separately described the @antv incident — the compromise of the maintainer’s npm account and the publication of 637 malicious versions in 323 packages, with a total estimated download volume of approximately 16 million per week. Microsoft Threat Intelligence analyzed the payload delivered via a compromised Mistral AI package in the same wave.

Miasma and @redhat-cloud-services. On June 1, 2026, Unit 42 described a new supply chain incident. At least 32 npm packages in the @redhat-cloud-services namespace were compromised. According to researchers, the attacker used a compromised GitHub account of a Red Hat employee, bypassed code review via orphan commits, launched GitHub Actions, obtained OIDC tokens, and published trojanized packages with valid SLSA proof of concept. Again, the conclusion is the same: proper build process attestation is of no help if the pipeline itself has already become part of the attack.

Glassworm: the developer as “rich prey.” On 26 May 2026, CrowdStrike, together with Google and The Shadowserver Foundation, carried out a coordinated takedown of the Glassworm botnet, striking all four of its command-and-control (C2) channels at once: servers on commercial VPSs, the Solana blockchain, the BitTorrent DHT network, and the titles of Google Calendar events. 

Glassworm used trojanized VS Code and OpenVSX extensions, npm and Python packages, and postinstall/setup scripts, and was designed to target not only VS Code but also Cursor, Positron, Windsurf, VSCodium and other editors. CrowdStrike puts the conclusion bluntly: adversaries now attack not only products but also the developers who build them.

Why developers specifically? Because they’re “rich prey.” They have access to source code, GitHub, npm, PyPI, clouds, Kubernetes, CI/CD and production secrets. Sometimes — to all of it at once. A single infected laptop can become a bridge to hundreds of downstream customers. 

Why this wave of supply-chain attacks happened

In terms of state-level resonance, SolarWinds still stands apart — that was a large-scale cyber-espionage operation. But in terms of how much of the development ecosystem it covers, the current wave looks, to put it cautiously, like one of the broadest since 2020. Several factors converged at once:

• developers use IDE extensions en masse;
• CI/CD has been granted too many privileges;
• secrets live too close to the build process;
• package registries have become a channel for delivering code straight into production;
• AI assistants have sharply accelerated the generation and modification of code;
• many teams can’t keep up with reviewing what they now generate themselves.

This “explosive mixture” is exactly what ignited this past spring.

AI has long been used by attackers as an accelerator. But in May 2026, Google Threat Intelligence Group described a shift from early, isolated misuse to the industrial-scale use of generative models in offensive workflows: vulnerability discovery, exploit generation, AI-assisted malware development, autonomous malware operations, and attacks on AI environments and dependencies themselves.

Anthropic provided another important signal in June 2026. The company analyzed 832 malicious accounts and compared their actions with MITRE ATT&CK. The conclusion was disturbing: AI is now being used not only for attack preparation, phishing, or writing simple malicious code, but also for actions after an initial compromise. According to Anthropic, 560 of the 832 accounts analyzed used AI to write malware, and 54 used it for lateral movement. The share of medium- and higher-risk actors increased from 33% in the first half of the period to 56% in the second.

This changes the very threat assessment. Previously, the number of techniques, the set of tools, and the type of interface could indirectly indicate the attacker’s skill level. Now, a weak operator with a well-developed agent “string” around the model can perform actions that previously required higher qualifications. Anthropic explicitly states that MITRE ATT&CK does not yet fully capture the dangerous properties of AI attacks: sequential orchestration of stages, real-time decision-making, and execution of a chain of actions with minimal human intervention.

In its Global Threat Report 2026, CrowdStrike reports figures that change the economics of attacks: activity by AI-enabled adversaries grew 89% year over year; the average “breakout” time (from initial access to lateral movement) fell to 29 minutes, and the fastest observed breakout took 27 seconds.

This doesn’t mean all malicious commits are made by AI models. The key question is different: AI sharply lowers the cost of the boring, dirty, labor-intensive parts of an attack — crafting a believable pull request, rewriting malicious code to match a project’s style, generating obfuscation variants, preparing phishing for a maintainer, quickly parsing a CI/CD configuration, assembling an exploit chain. It used to take more hands. Now you need fewer people, but with better tools.

Who is on the side of good?

On the other side of the front line, the charge is being led by Project Glasswing. In early April 2026, Anthropic gave roughly fifty partners early access to its AI model, Claude Mythos Preview. The mission is lofty — to harden software that is critically important for the planet before such capabilities end up in attackers’ hands. The partners include AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks and others.

The numbers are striking. Anthropic reports that the Mythos Preview model found 6,202 high- and critical-severity vulnerabilities across more than a thousand open-source projects — out of 23,019 findings in total. Of a sample of 1,752 findings checked by independent researchers, 90.6% turned out to be genuine vulnerabilities. Individual partners reported their own results. Cloudflare found about 2,000 bugs, roughly 400 of them high- or critical-severity.

But the most important thing in the report is not how much was found, but where the bottleneck now lies. Anthropic honestly admits: disclosure is only part of what was found, because the limiting step has become human triage, review and remediation. According to the company, by 22 May 2026 around a hundred vulnerabilities across hundreds of projects had gone through coordinated disclosure, but only a small share (less than 1%) have been fixed so far. Some maintainers have even asked Anthropic to slow the pace of disclosures, since patching a high- or critical-severity vulnerability takes about two weeks on average.

This, perhaps, is the main problem. The bottleneck is shifting. Not “finding,” but verifying, prioritizing, disclosing, fixing and safely delivering the patch.

At the same time, Anthropic also warns that Mythos-class models will soon appear at many AI companies, while strong enough safeguards against misuse don’t yet exist. That sounds alarming.

Fortunately, Anthropic isn’t alone

By early June, Anthropic had expanded Glasswing. Around 150 new organizations from more than 15 countries are expected to join the program, including critical infrastructure providers and vendors whose code many other organizations depend on. At the same time, Anthropic’s competitors are trying to catch up with the leader.

Google DeepMind introduced CodeMender as an AI agent for code security. According to Google, its Big Sleep and OSS-Fuzz efforts have already shown AI’s ability to find zero-days in well-tested software, and over six months CodeMender helped upstream about 72 security fixes to open source.

GitHub is developing Code Security and Copilot Autofix. The company claims an average 3x speedup in vulnerability remediation and suggestions for 90% of alert types. An agentic Autofix is meant to autonomously open pull requests with fixes.

OpenAI is developing Codex Security with an emphasis on the full cycle — threat model, realistic attack paths, isolated validation and patches for human review.

Microsoft is extending Security Copilot agents to phishing triage, vulnerability remediation and alert triage — now not only for AppSec, but also for cloud, identity and incident response.

Semgrep is advancing AI-assisted AppSec: SAST, SCA, secrets scanning, prioritization and protection of AI-generated code “at the source.”

IBM and Red Hat announced Project Lightwell on 28 May 2026 — a $5 billion investment and a team of more than 20,000 engineers who, together with AI tools, will protect open source through a “trusted clearinghouse.”

The race is on. The more vigorous the healthy competition among vendors, the more the entire security industry stands to gain.

Old and new problems in secure development

The old application-security problems haven’t gone anywhere: SQL injection, XSS, broken access control, and so on. Secrets still surface in repositories. Outdated dependencies linger for years. CI/CD is often built on the principle of “as long as it compiles.”

At the same time, new problems have been layered on top of the classic ones:

• Accelerated accumulation of technical debt. Vibe coding produces a quick working prototype, but “it works” doesn’t mean “it’s secure” — especially without threat modeling and negative-scenario testing.
• A false sense of security. An LLM can explain code convincingly even when the solution is insecure. The well-known cognitive bias — a feeling of security standing in for the state of security — reaches a new level.
• Dependence on external context. A prompt, a README, an issue, dependency documentation, a test fixture or a comment in the code can influence an agent’s behavior. This opens the way to indirect injection into developer workflows.
• Access to secrets. An AI agent, an IDE extension or a local tool often sees more than it needs: the terminal, the repository, .env, the SSH config, cloud profiles, package tokens.
• Accelerated “pollution” of the supply chain. If an assistant suggests adding a package that looks popular but was recently compromised, a team may accept the risk faster than it can grasp it.

NIST SSDF makes a simple point: secure development practices must be built into the SDLC. Now a new requirement is added on top. You need to review not only the code a human writes, but also the code an AI proposes. Review prompt flows, AI agents, IDE extensions, CI/CD identities. Treat provenance not as a pretty seal, but as part of a broader trust model.

That’s why secure use of AI in development isn’t a ban — it’s a managed process: policies, isolation, extension control, dependency allowlists, short-lived secrets, and reviewing AI-written code as strictly as human-written code.

Forecasts

The main problem of 2026 is no longer that AI “writes insecure code.” This is too narrow definition. The real risk is that AI is becoming involved in the entire development and attack surface: helping write code, select dependencies, manage workflows, search for vulnerabilities, build exploits, navigate within the network, and adapt to the environment. Therefore, it’s not just the application that needs to be protected, but the entire software fabric and the entire AI-assisted development system. Our predictions for 2026-2027:

First. Attacks on developer workstations, IDE extensions, GitHub Actions, OIDC, package registries and AI development workflows will become far more numerous.

Second. A new type of malware has already been demonstrated. Adaptive AI worms don’t simply use a pre-written exploit, but tailor their tactics to a specific target. The next risk is the migration of similar agent-based logic into supply chains: IDE extensions, CI/CD, GitHub Actions, npm/PyPI, publish-pipeline, and developer workstations.

Third. Mythos-class capabilities will become more accessible. Even if Anthropic stays cautious, competitors, open-source models, state-sponsored labs and the grey market will move in the same direction.

Fourth. The AppSec market will shift from “we found a list of bugs” to “we reduced real risk.” Finding will get easier. The value will lie in proving exploitability, eliminating false positives, fixing the root cause, not breaking the release, and not burying the team in alert fatigue.

Fifth. Companies will start requiring an AI security review almost as naturally as they once required a pentest before launch — especially if they use Copilot, Cursor, Claude Code, GitHub Actions, npm/PyPI, LLM agents or their own AI features in the product.

What to do?

Don’t panic — but don’t sleep, either.

Every development team should review CI/CD privileges: remove long-lived secrets, tighten OIDC trust policies, audit GitHub Actions (especially pull_request_target, unsafe handling of forks, cache poisoning, broad permissions and automated publish jobs), enable secret scanning, control dependencies and their “age,” separate build, test, release and deploy privileges, vet IDE extensions, log runners’ outbound connections, and treat the developer workstation as a privileged asset rather than “just a laptop.”

Teams that use AI in development need additional, dedicated rules. AI-generated code should be treated as untrusted until reviewed. You must not hand models secrets, customer data, production configs or proprietary code without a clear legal and technical framework. For AI agents this is doubly critical: there, autonomy turns into a problem far faster than with ordinary LLM-assisted code generation.

For us, this wave confirms what we’ve long been seeing in application-security, DevSecOps, AI security and architecture-audit projects. Risk no longer lives only in the application code. It lives in the connections, the dependencies, the pipeline, the access, the secrets, the developer’s tools and the automation — and increasingly in the AI itself that helps write, read, fix and run code.

That’s why protection must be comprehensive. H-X Technologies helps assess application security, source code, cloud configurations, DevOps and AI-assisted development. We do more than pentests, application-security audits, SAST/SCA and CI/CD analysis — we also assess the security of the supply chain, the architecture, AI solutions and AI governance.

We can carry out a targeted post-incident analysis of events like Mini Shai-Hulud or Megalodon, help build a secure SDLC, and assess the risks of Copilot, Claude Code, Codex, Cursor, Windsurf and other tools in your environment. Not a “tick the box” exercise, but a real check of where your chain of trust could actually break, how to prove it, and what to fix first.

This isn’t about fear of AI — it’s about maturity. AI accelerates development and defense, but it also accelerates mistakes and attacks. The companies that learn to manage this new risk perimeter before others will gain not only better security, but also more reliable development, stronger customer trust and a more resilient software supply chain.

Today, the winner isn’t whoever shouts “we use AI” the loudest, but whoever knows how to live safely in a world where everyone already uses AI: developers, defenders and attackers alike.

Contact us today for a free consultation on application and AI security.