Picture this scenario: An Anthropic Skill scanner runs a full analysis of a Skill pulled from ClawHub or skills.sh. Its markdown instructions are clean, and no prompt injection is detected. No shell commands are hiding in the SKILL.md. Green across the board.

The scanner never looked at the .test.ts file sitting one directory over. It didn’t need to. Test files aren’t part of the agent execution surface, so no publicly documented scanner inspects them (as of publication of this post). The file runs anyway. Not through the agent but through the test runner, with full access to the filesystem, environment variables, and SSH keys.

Gecko Security researcher Jeevan Jutla detailed this attack flow, demonstrating that when a developer runs npx Skills add, the installer copies the entire skill directory into the repo. If a malicious Skill bundles a *.test.ts file, the Jest and Vitest testing frameworks discover it through recursive glob patterns, treat it as a first-class test, and execute it during npm test or when the IDE auto-runs tests on save. The default configuration in open-source JavaScript test framework Mocha follows a similar recursive discovery pattern. The payload fires in beforeAll, before any assertions run. Nothing in the test output flags anything unusual. In CI, process.env holds deployment tokens, cloud credentials, and every secret the pipeline can reach.

The attack class is not new; malicious npm postinstall scripts and pytest plugins have exploited trust-on-install for years. What makes the Skill vector worse is that installed Skills land in a directory designed to be committed and shared across the team, propagate to every teammate who clones, and sit outside every scanner’s detection surface.

The agent is never invoked, and the Anthropic Skill scanner reads the right files for the wrong threat model.

Three audits, one blind spot

Gecko’s disclosure didn’t arrive in isolation. It landed on top of two large-scale security audits that had already documented the scope of the problem from the other direction, illustrating what scanners detect rather than what they miss. Both audits did exactly what they’re designed to do: They measured the threat on the execution surface scanners already inspect. Gecko measured what sits outside it.

A SkillScan academic study, published on January 15, analyzed 31,132 unique Anthropic Skills collected from two major marketplaces. Their findings: 26.1% of Skills contained at least one vulnerability spanning 14 distinct patterns across four categories. Data exfiltration showed up in 13.3% of Skills. Privilege escalation appeared in 11.8%. Skills bundling executable scripts were 2.12x more likely to contain vulnerabilities than instruction-only Skills.

Three weeks later, Snyk published ToxicSkills, the first comprehensive security audit of the ClawHub and skills.sh marketplaces. Snyk’s team scanned 3,984 Skills (as of February 5). The results: 13.4% of all Skills contained at least one critical-level security issue. Seventy-six confirmed malicious payloads were identified through a combination of automated scanning and human-in-the-loop review. Eight of those malicious Skills were still publicly available on ClawHub when the research was published.

Then Cisco shipped its AI Agent Security Scanner for IDEs on April 21, integrating its open-source Skill Scanner directly into VS Code, Cursor, and Windsurf. The scanner brings genuine capability to developers’ workflows. It does not inspect bundled test files, because the detection categories Cisco built target the agent interaction layer, not the developer toolchain layer.

The three major Anthropic Skill scanners share a structural blind spot: None inspects bundled test files as an execution surface, even though Gecko Security proved that those files execute with full local permissions through standard test runners.

Snyk Agent Scan, Cisco’s AI Agent Security Scanner, and VirusTotal Code Insight all work. They catch prompt injection, shell commands, and data exfiltration in Skill definitions and agent-referenced scripts. What they do not do is look beyond the agent execution surface to the developer execution surface sitting in the same directory.

How the attack chain works

The mechanics of the attack chain matter because the fix is precise. When a developer runs npx skills add owner/repo-name, the installer clones the Skill repository and copies its contents into .agents/skills// inside the project. Claude Code, Cursor, and other agent IDEs get symlinks into their own Skill directories. The only files excluded are .git, metadata.json, and files prefixed with _. Everything else lands on disk.

Jest and Vitest both pass dot: true to their glob engines. That means they discover test files inside dot-prefixed directories like .agents/. Mocha’s behavior depends on configuration but follows similar recursive patterns by default. None of them exclude .agents/, .claude/, or .cursor/ from their default discovery paths.

An attacker publishes a Skill with a clean SKILL.md and a tests/reviewer.test.ts file containing a beforeAll block. The block reads process.env, .env files, ~/.ssh/ private keys, and ~/.aws/credentials. It posts everything to an external endpoint. The test cases look real. The exfiltration happens during setup, silently, whether the tests pass or fail.

The vector is not limited to TypeScript. Python repos face the same exposure through conftest.py, which pytest auto-executes during test collection. Add .agents to testpaths exclusion in pyproject.toml to block it.

The .agents/skills/ directory is designed to be committed to the repo so teammates can share Skills. GitHub’s default .gitignore templates do not include .agents/. Once the malicious test file enters the repo, every developer who clones and runs tests executes the payload. So does every CI pipeline on every branch and every fork that inherits the test suite.

Scanners are reading the wrong threat surface

CrowdStrike CTO Elia Zaitsev put the structural challenge in operational terms during an exclusive VentureBeat interview at RSAC 2026. “Observing actual kinetic actions is a structured, solvable problem,” Zaitsev said. “Intent is not.”

That distinction cuts directly at the Anthropic Skill scanner gap. No publicly documented scanner operates outside the assumption that the threat lives in the SKILL.md and in scripts the agent is instructed to run. These tools analyze intent: What does the Skill tell the agent to do? Gecko’s finding sits on the kinetic side. The test file executes through the developer’s own toolchain. No agent is involved. No prompt is interpreted. The payload is TypeScript, running with full local permissions through a legitimate test runner. The scanner was solving the wrong problem.

CrowdStrike’s Zaitsev framed the identity dimension: “AI agents and non-human identities will explode across the enterprise, expanding exponentially and dwarfing human identities,” he told VentureBeat. “Each agent will operate as a privileged super-human with OAuth tokens, API keys, and continuous access to previously siloed data sets.”

CrowdStrike’s Charlotte AI and similar enterprise agents operate with exactly these privileges. When those credentials live in environment variables accessible to any process in the repo, a test-file payload does not need agent privileges. It already has developer privileges, which in most CI configurations means deployment tokens and cloud access.

Mike Riemer, SVP of the network security group and field CISO at Ivanti, quantified the exploitation window in a VentureBeat interview. “Threat actors are reverse engineering patches within 72 hours,” Riemer said. “If a customer doesn’t patch within 72 hours of release, they’re open to exploit.”

Most enterprises take weeks. The Anthropic Skill scanner blind spot compounds that window. A developer installs a malicious Skill today. The test file executes immediately. No patch exists because no scanner flagged it.

The Anthropic Skill Audit Grid

VentureBeat has covered the Anthropic Skill supply chain since the ClawHavoc campaign hit ClawHub in January. Every conversation with security leaders lands on the same frustration. Their teams bought a scanner, it reports clean, and they have no framework for asking what it does not check.

VentureBeat has polled dev teams who install Anthropic Skills from ClawHub and skills.sh. The grid below connects the published-audit half (Snyk, SkillScan) with the scanner-bypass half (Gecko). Each row represents a detection surface a security team should verify before approving any Skill scanning tool for Q2 procurement.

Three CI hardening steps to add now

Riemer made the broader point in VentureBeat interviews that placing security controls at the perimeter invites every threat to that exact boundary. Anthropic Skill scanners placed the boundary at SKILL.md. Attackers put the payload one directory over. The three changes below move the boundary to where the code actually executes.

These changes take minutes. None requires replacing current tools or waiting for scanner vendors to close the gap.

Add .agents/ to the test runner’s ignore list. In Jest, add /\.agents/ to testPathIgnorePatterns in jest.config.js. In Vitest, add **/.agents/** to the exclude array in vitest.config.ts. One line in one config file prevents the test runner from discovering files inside installed Skill directories. Do it whether or not the team currently uses Anthropic Skills. The directory may appear in a cloned repo without anyone installing the Skill directly.

Audit every Skill install for non-instruction files before merge. Add a CI check that flags any file in .agents/skills/ matching *.test.*, *.spec.*, __tests__/, *.config.*, or conftest.py. These files have no legitimate reason to exist inside a Skill directory. The check is a shell one-liner: [ -d .agents ] && find .agents/ -name “*.test.*” -o -name “*.spec.*” -o -name “conftest.py” -o -name “*.config.*” -o -type d -name “__tests__” | grep -q . && exit 1. If it matches, block the merge. For any test files that do land in a PR, require a reviewer to skim for shell invocations (exec, spawn, child_process), external network calls, and file operations touching secrets or SSH keys.

Pin Skill sources to specific commits, not latest. The npx skills add command copies whatever the repo contains at the moment of install. A Skill author can push a clean version for scanner review, then add a malicious test file after approval. Pinning to a specific commit hash converts a trust-on-first-use model into a verify-on-every-change model. The OWASP Agentic Skills Top 10 recommends exactly this.

If Skills are already in your repo: Run the find command above against your existing .agents/ directory now. If test files are present, treat them as a potential compromise: Rotate any credentials accessible to CI (deployment tokens, cloud keys, SSH keys), audit CI logs for unexpected outbound network calls during test execution, and review git history to determine when the test files entered the repo and which pipelines have executed them.

Five questions to ask your Anthropic Skill scanner vendor

Security teams are signing contracts for their first dedicated Skill scanning tools. The Gecko bypass means the questions on those sales calls need to change. Do not stop at “Do you detect prompt injection?” Ask:

• Which files and directories do you actually analyze in a Skill repo?

• Do you treat test files as potential execution surfaces?

• Can you flag Skills that bundle tests, CI configs, or build scripts as higher-risk? SkillScan showed script-bundling Skills are 2.12x more likely to be vulnerable.

• Do you provide integration or guidance for restricting test-runner globs in CI? Cisco deserves credit for open-sourcing its Skill Scanner on GitHub, which lets security teams inspect exactly which detection categories the tool implements. That transparency is the baseline every vendor should meet. If your vendor will not publish detection categories or open-source their scanning logic, you cannot verify what they check and what they skip.

• Have you published an ecosystem-scale audit with methodology and sample size? Snyk published at 3,984 Skills. SkillScan published at 31,132. Riemer described the disclosure pattern: “They chose not to publish a CVE. They just quietly patched it and moved on with life,” he said. The Anthropic Skills ecosystem is showing early signs of the same pattern: scanners document what they detect without mapping the surfaces they do not reach. The gap between documented coverage and actual execution surface is where the test-file vector lives.

The audit grid matters because the scanner model is incomplete

The Anthropic Skills ecosystem is repeating the early npm supply chain story, except without the decade of accumulated incidents that forced package registries to build security infrastructure. SkillScan’s 31,132-Skill dataset showed a quarter of the ecosystem carrying vulnerabilities. Snyk found 76 confirmed malicious payloads in fewer than 4,000 Skills. Gecko proved the scanner model itself has a structural gap that no vendor has publicly documented closing.

Scanner evaluations consistently test the covered surface. The Anthropic Skill Audit Grid gives security teams the seven audit surfaces to verify before signing. The three CI steps are the fixes to deploy before the next Skill install. Riemer’s Ivanti team watches the patch-to-exploit cycle compress in real time across enterprise environments. The test-file vector compresses it further: No scanner flagged the threat, so no patch window exists.

The scanner is not broken. It is incomplete. The threat model stopped at the agent. The test runner did not.

from the ctrl-alt-speech dept

Ctrl-Alt-Speech is a weekly podcast about the latest news in online speech, from Mike Masnick and Everything in Moderation‘s Ben Whitelaw.

Subscribe now on Apple Podcasts, Overcast, Spotify, Pocket Casts, YouTube, or your podcast app of choice — or go straight to the RSS feed.

In this week’s roundup of the latest news in online speech, content moderation and internet regulation, Mike is joined by First Amendment lawyer Ari Cohn. Together they discuss:

Support the podcast by joining our Patreon, with special founder membership available until May 28th.

Filed Under: age verification, ari cohn, artificial intelligence, chatbots, content moderation, free speech, trust and safety

Companies: character.ai

A new trojan named TCLBanker, which targets 59 banking, fintech, and cryptocurrency platforms, uses a trojanized MSI installer for Logitech AI Prompt Builder to infect systems.

Additionally, the malware includes self-spreading worm modules for WhatsApp and Outlook that automatically infect new victims.

The new banking trojan was discovered by Elastic Security Labs, whose researchers believe it’s a major evolution of the older Maverick/Sorvepotel malware family.

While TCLBanker currently appears focused in Brazil, specifically checking timezone, keyboard layout, and locale, LATAM malware has, in the past, been updated to broaden its targeting scope, so the risk of the threat expanding is real.

TCLBanker capabilities

Elastic warns that TCLBanker is extremely well protected against analysis and debugging, featuring environment-dependent payload decryption routines that fail in sandboxes or analyst environments.

It also runs a persistent watchdog thread that continuously hunts for analysis tools like x64dbg, IDA, dnSpy, Frida, ProcessHacker, Ghidra, de4dot, and others.

The malware is loaded within the context of the legitimate Logitech application via DLL side-loading, so it won’t trigger any alarms from security products protecting the infected host.

The researchers noted that, while the loader is rich in features, none go very far toward being truly advanced, and code artifacts indicate that AI may have been used in its development.

The banking module monitors the browser address bar every second using Windows UI Automation APIs, watching for when the victim opens a website of one of its 59 targeted platforms.

When that happens, it establishes a WebSocket session with the command-and-control (C2), sends victim and system information, and starts remote control operations.

The capabilities given to the operators include:

• Live screen streaming
• Screenshot capturing
• Keylogging
• Clipboard hijacking
• Shell command execution
• Window management
• File system access
• Process enumeration
• Remote mouse/keyboard control

During active sessions, the Task Manager process is killed to prevent disruptions and hide the malicious activity from the victim.

To support data theft, TCLBanker uses a WPF-based overlay system that can push to victims fake credential prompts, PIN keypads, phone-number collection forms, fake “bank support” waiting screens, fake Windows Update screens, and various fake progress screens.

There are also “cutout” overlays that stay on top, allowing only selected portions of real applications to be shown to the victim, and masking other parts.

WhatsApp and Outlook worms

An interesting aspect of TCLBanker is its ability to propagate autonomously to contacts linked to the primary victim.

The malware searches Chromium browser profiles for authenticated WhatsApp Web IndexedDB data, and launches a hidden Chromium instance that hijacks the victim’s account.

Then, it harvests contacts, filters for Brazilian numbers, and sends them spam messages from the victim’s account, leading them to TCLBanker distribution platforms.

Another worm module abuses Microsoft Outlook through COM automation, launching the app, harvesting contacts and sender addresses, and sending phishing emails through the victim’s email account.

Elastic concludes that TCLBanker is as a characteristic example of the evolution of LATAM malware, offering lower-tier cybercriminals features that were once only available in highly sophisticated tools.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what’s exploitable, proves controls hold, and closes the remediation loop.

Claim Your Spot

The ShinyHunters extortion gang has breached education technology giant Instructure again, this time exploiting a vulnerability to deface Canvas login portals for hundreds of colleges and universities.

The defacements, which were visible for roughly 30 minutes before being taken offline, displayed a message from ShinyHunters claiming responsibility for the earlier Instructure breach and threatening to leak stolen data if a ransom is not paid.

The message warns that Instructure and schools have until May 12 to contact them to negotiate a ransom, or students’ data will be leaked.

“ShinyHunters has breached Instructure (again). Instead of contacting us to resolve it they ignored us and did some ‘security patches’,” reads the defacement.

“If any of the schools in the affected list are interested in preventing the release of their data, please consult with a cyber advisory firm and contact us privately at TOX to negotiate a settlement. You have till the end of the day by May 12 2026 before everything is leaked,” continued the message.

BleepingComputer has learned that threat actors defaced the Canvas login portals for approximately 330 educational institutions, replacing the standard login pages with an extortion message. This defacement message also appeared in the Canvas app.

The defacement was allegedly caused by a vulnerability in Instructure’s systems that allowed the threat actor to modify the login portals. Instructure has since taken Canvas offline while they respond to the latest cyberattack.

Last week, Instructure disclosed that it was investigating a cyberattack after threat actors claimed to have stolen 280 million student and staff records tied to 8,809 schools, universities, and education platforms using its Canvas learning management system.

The ShinyHunters gang later told BleepingComputer that the stolen data included user records, private messages, enrollment data, and other information allegedly gathered through Canvas data export features and APIs.

Instructure confirmed that data was stolen during the attack but that they are continuing to investigate the incident.

BleepingComputer has repeatedly contacted Instructure with questions about the attack, including today’s, and whether they plan on notifying students and staff about the data breach. However, our emails have so far remained unanswered.

Canvas is one of the most widely used learning management systems in higher education and K-12 environments, helping schools manage coursework, assignments, grading, and communication between students and faculty.

Who is ShinyHunters

The name ShinyHunters has long been associated with numerous threat actors who have conducted data breaches since 2018.

This year, threat actors using the ShinyHunters name have become among the most prolific groups conducting data theft and extortion attacks against companies worldwide.

Primarily focusing on Salesforce and other cloud SaaS environments, the threat actors are linked to a growing number of breaches involving companies such as Google, Cisco, PornHub, and online dating giant Match Group.

The extortion gang commonly breaches third-party integration companies and uses stolen authentication tokens to access connected SaaS environments and steal customer data.

The threat actors are also known for conducting voice phishing (vishing) attacks targeting Okta, Microsoft, and Google single sign-on (SSO) accounts, impersonating IT support staff to trick employees into entering credentials and multi-factor authentication (MFA) codes on phishing sites.

As BleepingComputer first reported, the ShinyHunters group has also recently adopted device code vishing attacks to obtain Microsoft Entra authentication tokens.

After stealing credentials and authentication codes, the threat actors hijack SSO accounts to breach connected enterprise services such as Salesforce, Microsoft 365, Google Workspace, SAP, Slack, Adobe, Atlassian, Zendesk, and Dropbox.

While members of the ShinyHunters gang are responsible for numerous attacks, they are also known to operate as an extortion-as-a-service group, conducting extortion on behalf of other threat actors in exchange for a share of ransom payments.

There have been numerous arrests linked to the ShinyHunters name, including suspects connected to the Snowflake data-theft attacks, breaches at PowerSchool, and the operation of the Breached v2 hacking forum.

Yet despite these arrests, companies continue to receive extortion emails signed with the message, “We are ShinyHunters.”

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what’s exploitable, proves controls hold, and closes the remediation loop.

Claim Your Spot

Apple has failed to reduce the scope of a UK class-action lawsuit, and all iCloud users in the country will be owed $95 if the company loses.

Apple has had its fair share of lawsuits in the United Kingdom, with ongoing cases regarding App Store fees, an alleged price-fixing scheme with retailers, and more.

In November 2024, consumer rights group and publication Which? also sued Apple, alleging that the company had an anti-competitive way of locking users into paying for iCloud storage.

It was argued that Apple breached UK competition law and abused its dominant market position by not letting iOS and iPadOS choose an alternative cloud provider. Additionally, Apple was accused of charging “rip-off prices” for iCloud storage in the country.

As Apple failed to narrow down the scope of the class-action lawsuit, the case is now moving to trial.

As Which? claims in a social media post, Apple locked “millions of consumers into its iCloud service at rip-off prices.” The group says that around 40 million UK iCloud users may be eligible for compensation equating to $95, assuming its lawsuit is successful.

The lawsuit seeks damages for iPhone and iPad users who paid for iCloud storage. However, with the principle of Forgone Consumer Surplus (FCS), the suit also argues that iCloud users in the UK were priced out of an iCloud subscription, as Apple abused its market position.

Hypothetically, users who found Apple’s roughly $12 monthly payment for 2TB of cloud storage would have paid around $11 if it were a “fair” market price. Per the FCS legal theory, those potential customers “lost” $1 because of Apple’s uncompetitive pricing and the lack of an adequate alternative.

Consumer rights group Which? argued that Apple should pay these hypothetical buyers, even though they never really lost anything or paid for anything in the traditional sense.

It says that “around 40 million Apple customers in the UK who have used iCloud services on or after 8 November 2018” could be entitled to compensation.

Apple attempted to narrow the scope of the lawsuit so that it only included UK iCloud users who paid for a subscription. “We reject any suggestion that our iCloud practices are anticompetitive and will vigorously defend against any legal claim otherwise,” said the company in 2024.

However, its attempts were unsuccessful. The UK’s Competition Appeal Tribunal ruled in a two-to-one vote that the FCS legal theory is applicable. In essence, the class-action suit could result in compensation for both paying and non-paying UK iCloud users.

The iCloud restrictions that inspired the lawsuit

iCloud itself has been around since 2011, when it debuted with iOS 5. The service delivered system-wide integration, allowing users to sync their notes, emails, photos, files, and more via the cloud storage platform.

Apple has been accused of using uncompetitive pricing for its iCloud storage options in the UK.

At the time, Apple gave its users 5GB of iCloud storage for free. While that may have been generous all those years ago, Which? argued that 5G wouldn’t meet consumer needs in 2024 and beyond.

There might be some truth to this claim, as almost two-thirds of US Apple users paid for extra iCloud storage in 2024. However, Apple dealt with a lawsuit about its 5GB free iCloud storage option in the United States, and that case was ultimately dismissed the same year.

The UK lawsuit against Apple, however, is still ongoing, and it revolves around more than just the free 5GB storage plan.

Which? also argued that Apple made iCloud the simplest cloud service to use on iOS. Alternative cloud storage options on iOS truly don’t deliver the same degree of integration.

If you wanted to store your photos and videos via Google Drive, for instance, you’d have to install the app yourself. You also wouldn’t be able to use a Google-designed tool or locking tool in place of Find My on iOS, which requires the use of an iCloud account.

If the UK lawsuit against Apple succeeds, all iCloud users in the country will be automatically opted in, meaning they’ll be eligible for payment. This includes UK consumers who have used iCloud on or after November 8, 2018.

The case could also set a precedent in the country. One member of the UK’s Competition Appeal Tribunal argued that we could see a multitude of similar cases centered around hypothetical purchases.

Still, the outcome of the class-action lawsuit remains to be seen, and it could be months before a decision is made.