What is Path Equivalence Wildcard (CWE-56)?

TL;DR: CWE-56 lets an attacker use wildcard characters like “*” to match unintended files when the application passes unsanitized input into glob or shell expansion; the fix is rejecting wildcard metacharacters and validating against an allowlist.

What is Path Equivalence?

Path Equivalence: Wildcard (CWE-56) is a type of access-control bypass vulnerability that occurs when an application accepts a filename containing an asterisk or other wildcard character without neutralizing it, potentially matching unintended files during path resolution. As defined by the MITRE Corporation under CWE-56, this weakness has no official OWASP Top 10:2025 category mapping but is a direct child of Improper Resolution of Path Equivalence (CWE-41) and Improper Neutralization of Wildcards or Matching Symbols (CWE-155).

Quick Summary

Wildcard characters mean something very different to a shell or glob function than they do to a plain string comparison — “*” isn’t a literal character to those APIs, it’s an instruction to match anything. If unsanitized user input reaches one of those functions, a filename check designed around exact, single-file matching can be quietly turned into a multi-file match.

Jump to: Quick Summary · Path Equivalence Overview · How Path Equivalence Works · Business Impact of Path Equivalence · Path Equivalence Attack Scenario · How to Detect Path Equivalence · How to Fix Path Equivalence · Framework-Specific Fixes for Path Equivalence · How to Ask AI to Check Your Code for Path Equivalence · Path Equivalence Best Practices Checklist · Path Equivalence FAQ · Vulnerabilities Related to Path Equivalence · References · Scan Your Own Site

Path Equivalence Overview

What: An application passes an unsanitized filename containing wildcard characters into a glob or shell-expansion function, letting it match more files than intended.

Why it matters: A check designed for exact, single-file access can be silently broadened into a multi-file match by wildcard expansion.

Where it occurs: File-processing features that pass user input into shell commands, glob functions, or any API that treats *, ?, or [] specially.

Who is affected: Applications that pass unsanitized filenames into glob-matching or shell-expansion functions.

Who is NOT affected: Applications that reject or escape wildcard metacharacters before any glob or shell operation, or that never pass user input into such functions at all.

How Path Equivalence Works

Root Cause

The application passes a filename containing unsanitized wildcard characters into a function that interprets them as glob patterns rather than literal characters.

Attack Flow

1. The attacker identifies a filename parameter that reaches a glob-matching or shell-expansion function.
2. The attacker submits a value containing a wildcard, e.g. *.conf.
3. The underlying function expands the wildcard, matching every file fitting that pattern instead of a single intended file.
4. The attacker receives or affects the contents of multiple unintended files.

Prerequisites to Exploit

• User input reaches a glob-matching or shell-expansion function without neutralizing wildcard characters.
• The attacker can influence the filename value used in that operation.
• The matched files are accessible to the process running the operation.

Vulnerable Code

#!/bin/bash
filename="$1"
cat /var/app/data/$filename

The unquoted, unsanitized $filename is expanded by the shell before cat runs, so a value like * matches and dumps the contents of every file in the directory.

Secure Code

#!/bin/bash
filename="$1"
if [[ "$filename" =~ [\*\?\[\]] ]]; then
    echo "Invalid filename" >&2
    exit 1
fi
cat -- "/var/app/data/${filename}"

Wildcard metacharacters are rejected outright before the value is used, and quoting the final path prevents any remaining shell expansion.

Business Impact of Path Equivalence

Confidentiality: Attackers may read the contents of multiple unintended files matched by a wildcard expansion.

Integrity: In write- or delete-oriented operations, a wildcard match could modify or remove far more files than intended.

• Bulk exposure of configuration files, logs, or other data matching a broad wildcard pattern
• Accidental or intentional multi-file deletion if the wildcard reaches a destructive operation

Path Equivalence Attack Scenario

1. An attacker finds a log-viewer script that accepts a filename parameter and passes it unsanitized into a shell command.
2. They submit *.log instead of a single log filename.
3. The shell expands the wildcard, and the script dumps the contents of every log file in the directory.
4. The attacker reviews the combined output for credentials or sensitive data accidentally logged elsewhere.

How to Detect Path Equivalence

Manual Testing

• Identify filename parameters that reach a shell command or glob-matching function.
• Submit wildcard characters (*, ?, []) as or within the filename value.
• Confirm whether more than the intended single file is returned or affected.

Automated Scanners (SAST / DAST)

Static analysis can flag unsanitized input reaching shell commands or glob functions directly, while dynamic testing confirms whether wildcard characters actually expand at runtime.

PenScan Detection

PenScan’s scanner engines submit wildcard-injection payloads against filename parameters and confirm whether unintended files are exposed.

False Positive Guidance

If the application always quotes filenames and never passes them through a shell or glob function, a wildcard character in the input is inert and this weakness does not apply — confirm the actual code path before treating it as a real finding.

How to Fix Path Equivalence

• Reject or escape wildcard metacharacters (*, ?, [, ]) before any glob-matching or shell operation.
• Validate the final filename against an allowlist or exact match rather than trusting glob expansion results.
• Avoid passing user input into shell commands entirely where possible; use direct file APIs instead.

Framework-Specific Fixes for Path Equivalence

• Shell scripts: reject wildcard metacharacters explicitly and always quote variables in commands, as shown above.
• Python: use glob.escape() before passing user input to glob.glob(), or avoid glob entirely in favor of exact filename checks.
• Node.js: avoid passing user input to child_process.exec(); use execFile() with an argument array, and validate filenames against an allowlist.
• Java: avoid Runtime.exec() with a shell string built from user input; use ProcessBuilder with an explicit argument list and validate filenames server-side.

How to Ask AI to Check Your Code for Path Equivalence

Path Equivalence Best Practices Checklist

✅ Reject or escape wildcard metacharacters before any glob or shell operation ✅ Validate filenames against an allowlist rather than trusting glob expansion ✅ Avoid passing user input into shell commands; prefer direct file APIs ✅ Always quote filename variables in shell scripts

Path Equivalence FAQ

How does a wildcard character like “*” cause an equivalence bypass?

If unsanitized input reaches a glob-matching or shell-expansion function, an asterisk expands to match multiple filenames at once, so a request intended to reference one file can instead match several files a single-filename check never anticipated.

How is this different from standard Path Traversal?

Path Traversal escapes a restricted directory using “../”; wildcard equivalence stays inside the intended directory but exploits glob-expansion semantics to match more (or different) files than the exact filename an access check expected.

How would an attacker actually exploit this?

If an application passes user input into a shell command or glob function without neutralizing wildcard characters, a value like “*.conf” could match and expose every configuration file in a directory instead of the single intended one.

How do I detect this in my own application?

Test any filename parameter that reaches a glob or shell-expansion function with wildcard characters (*, ?, []) and confirm whether more files are returned or affected than intended.

How do I fix this correctly?

Reject or escape wildcard metacharacters before the input reaches any glob-matching or shell function, and validate the final filename against an allowlist or exact match.

How does escaping wildcards differ from escaping path traversal sequences?

Path traversal defenses focus on directory-separator and dot sequences; wildcard defenses must additionally neutralize glob metacharacters (*, ?, [, ]) that have special meaning to shells and glob functions but not to plain path resolution.

How can PenScan help find this weakness?

PenScan tests filename-based access controls with wildcard-injection payloads to confirm whether unintended files are exposed.

Vulnerabilities Related to Path Equivalence

References

• MITRE - CWE-56
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find this Path Equivalence variant and other risks before an attacker does.