Double asterisk globbing is a pattern-matching rule that uses two asterisks, usually written as **, to match multiple directory levels or any sequence of characters. It is used in shells, file paths, and configuration patterns to select many files or resources at once, depending on the tool’s matching rules.
What double asterisk globbing does
Double asterisk globbing is a pattern rule that lets a single glob match across directory boundaries or across long character sequences, depending on the tool. It gives users a compact way to address many paths or names without listing each one individually.
The meaning of ** is not universal. Some shells and tools treat it as recursive path matching, while others treat it as an ordinary wildcard or require a specific option before it becomes special.
Where it appears in shells and tooling
This pattern is common in command shells, build tools, file synchronisation utilities, and configuration systems that accept glob syntax. It is often used for broad file selection, such as matching nested source trees, logs, or resource directories.
Because globbing happens before many programs see their arguments, the same pattern can behave differently across environments. That makes it important to know whether the shell expands the pattern first, or whether the application itself interprets the glob.
How matching scope changes with recursive patterns
With ordinary single-asterisk globbing, a match usually stays within one path segment. Double asterisk globbing expands that scope, so one pattern can traverse multiple levels of a tree and capture deeply nested files or directories.
That broader scope is useful for automation, but it also makes the pattern less precise. A loose recursive glob can match more content than intended, especially when directory layouts change over time.
Why the syntax is useful and where it can surprise you
Double asterisk globbing reduces repetition, simplifies scripts, and makes broad resource selection easier to read. It is especially helpful when the exact depth of a file tree is not known in advance.
It can also create surprises in portability, because different shells and libraries may interpret the same pattern differently. A pattern that works in one environment may fail, over-match, or under-match in another unless the matching rules are documented and tested.
Risk and Threat Considerations
Double asterisk globbing can widen the set of files, paths, or resources a script touches, so a small pattern mistake may expose sensitive files, include unintended inputs, or overwrite more data than the author expected. In security-sensitive automation, that broad match scope can become an availability or data-handling problem rather than a convenience feature.
Failure mechanism: An overly broad recursive glob matches unexpected directories or filenames because the tool interprets ** more permissively than the author assumed, or because shell expansion and application-level expansion differ.
Impact: The result can be accidental disclosure, destructive file operations, incorrect deployment targets, or inconsistent security checks when scripts rely on a path set that is larger than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Broad path matching can affect which files or resources are processed under operational controls. |
| Recommendation — Restrict automated file and resource selection to approved paths and validate recursive patterns before execution. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Glob behaviour depends on tool and shell configuration, so matching rules must be controlled and documented. |
| AC-6 — Least Privilege | Overly broad recursive matches can cause scripts to act on more content than intended, violating least privilege in automation. | |
| Recommendation — Standardize glob expansion behaviour and document the exact recursive pattern rules used in each tool. Limit automated jobs to the narrowest path set needed for the task and review recursive patterns for excess scope. | ||
| NIST CSF 2.0 | PR.PS-02 — Software Platform Configuration | Pattern matching behaviour is part of software platform configuration and should be controlled for consistency. |
| Recommendation — Configure platforms consistently so recursive glob patterns resolve predictably across environments. | ||
| OWASP ASVS | V13 — Configuration | Applications and tooling that accept glob syntax need secure, explicit configuration to prevent unintended matching. |
| Recommendation — Require explicit configuration for any feature that interprets user-supplied or policy-supplied glob patterns. | ||
Practitioner Guidance
What to watch for: Treat recursive glob patterns as environment-specific input, not portable syntax. Test them in the exact shell, runtime, or build system that will execute them, and confirm whether the tool, the shell, or both are responsible for expansion.
Governance implication: Where scripts or pipelines use **, define the matching rules explicitly in the implementation or runbook so reviewers understand what paths can be included or excluded.