CVE-2026-33672

What it actually does

CVE-2026-33672 is an input-validation flaw in the JavaScript glob-matching library Picomatch. Affected versions build regular expressions from POSIX bracket expressions using a POSIX_REGEX_SOURCE object that inherits from Object.prototype. Because inherited property names such as constructor can be referenced through crafted patterns like [[:constructor:]], JavaScript implicitly converts inherited methods to strings and incorporates them into the generated regular expression. The practical result is incorrect glob matching: patterns may match files or paths that the application did not intend to allow or deny. The issue is primarily an integrity flaw and is not described as enabling remote code execution, data disclosure, or direct denial of service.

Why it matters to the business

Applications that use Picomatch to enforce security-sensitive file, path, or pattern rules may make incorrect allow/deny decisions. This can affect upload validation, file inclusion/exclusion rules, build or CI/CD filters, authorization checks, policy enforcement, and tenant- or user-controlled pattern matching. The risk is highest where untrusted users can submit glob patterns and the application relies on the result for access control or filtering. Public exploit maturity is currently listed as none, EPSS is low at 0.0041, and it is not in CISA KEV or known ransomware use, so this is generally a patch-priority dependency integrity issue rather than an emergency internet-wide exploitation event.

How an attack unfolds

An attacker first identifies an application feature that accepts glob patterns, filename filters, ignore rules, include/exclude lists, search patterns, or similar user-controlled matching expressions processed by Picomatch. They then submit a crafted POSIX bracket expression that references an inherited Object.prototype method name, such as [[:constructor:]]. In vulnerable Picomatch versions, the library looks up the value through the prototype chain, implicitly stringifies the inherited method, and injects that string into the regular expression source it generates. The resulting regular expression no longer represents the intended POSIX class and may match unintended filenames or paths. If the application uses the match decision to enforce security or operational boundaries, the attacker may bypass filtering, include files that should have been excluded, exclude files that should have been included, or otherwise manipulate path-based logic.

How to fix it

Upgrade Picomatch to a fixed release: 4.0.4 or later for the 4.x line, 3.0.2 or later for the 3.x line, or 2.3.2 or later for the 2.x line. Because Picomatch is commonly pulled in transitively through other JavaScript tooling, update lockfiles and rebuild dependencies after upgrading direct or parent packages. If immediate upgrade is not possible, do not pass untrusted or user-controlled glob patterns to Picomatch. Reject or sanitize POSIX bracket expressions in user input, especially patterns of the form [[:...:]]. Consider disabling POSIX bracket expression support for untrusted input paths. As a temporary source-level mitigation, patch POSIX_REGEX_SOURCE so it uses a null-prototype object and cannot resolve inherited Object.prototype properties.

How to confirm the fix worked

Confirm dependency versions with package manager tooling such as npm ls picomatch, yarn why picomatch, pnpm why picomatch, or software composition analysis output. Validate that all resolved Picomatch instances are at 4.0.4+, 3.0.2+, or 2.3.2+, depending on the release line in use, and that package-lock.json, yarn.lock, or pnpm-lock.yaml no longer pins vulnerable versions. Where the application accepts user-supplied glob patterns, add regression tests using crafted POSIX expressions such as [[:constructor:]] and verify they are rejected, sanitized, or matched only according to expected safe behavior. For production exposure review, inventory endpoints, APIs, configuration features, CI/CD jobs, upload workflows, and search/filter functionality that process user-controlled glob expressions.

Typical attack path

1. Find an application feature that accepts user-controlled glob patterns, file filters, include/exclude rules, ignore patterns, or path-matching input.
2. Confirm or infer that the backend uses an affected Picomatch version to compile and evaluate those patterns.
3. Submit crafted POSIX bracket expressions that reference inherited method names, for example [[:constructor:]].
4. Trigger Picomatch to convert the crafted glob into a regular expression.
5. Cause the generated regular expression to match a different set of filenames or paths than intended.
6. Abuse the incorrect match result to bypass validation, alter filtering behavior, or manipulate access-control or workflow decisions that depend on glob matching.

How to detect it

Exploitation will usually appear as suspicious user-supplied glob input rather than malware or system-level artifacts. Review application logs, API request logs, web access logs, audit logs, CI/CD job logs, repository configuration changes, and file-filtering or search telemetry for POSIX bracket expressions containing inherited JavaScript property or method names. Focus on features that accept glob patterns, include/exclude rules, ignore patterns, path filters, upload filters, or repository/build configuration. Look for repeated testing of [[:...:]] values, especially constructor, __proto__, prototype, toString, valueOf, hasOwnProperty, isPrototypeOf, propertyIsEnumerable, __defineGetter__, __defineSetter__, __lookupGetter__, and __lookupSetter__. Investigate cases where a suspicious pattern preceded unexpected file inclusion, exclusion, access, deployment, upload acceptance, policy bypass, or CI/CD workflow changes. Because this vulnerability causes logic errors rather than code execution, there are no reliable host-level process, registry, or binary indicators specific to this flaw.

• [[:constructor:]]
• [[:__proto__:]]
• [[:prototype:]]
• [[:toString:]]
• [[:valueOf:]]
• [[:hasOwnProperty:]]
• [[:isPrototypeOf:]]
• [[:propertyIsEnumerable:]]
• [[:__defineGetter__:]]
• [[:__defineSetter__:]]
• [[:__lookupGetter__:]]
• [[:__lookupSetter__:]]
• POSIX_REGEX_SOURCE
• picomatch

What your security team should do

• Inventory all direct and transitive uses of Picomatch across JavaScript and Node.js applications, build tooling, CI/CD pipelines, and developer tooling.
• Prioritize remediation for applications where users, external parties, plugins, repositories, or configuration files can supply glob patterns that affect access control, file selection, upload validation, deployment, or policy decisions.
• Upgrade to Picomatch 4.0.4+, 3.0.2+, or 2.3.2+ and refresh lockfiles to ensure vulnerable transitive copies are removed.
• Add input validation that rejects untrusted POSIX bracket expressions, particularly [[:...:]] syntax, unless there is a clear business need and safe parsing behavior is verified.
• Add regression tests for crafted patterns such as [[:constructor:]] in any security-sensitive glob-matching code paths.
• Review historical logs or audit trails for suspicious glob patterns if glob input is externally supplied or used in sensitive decisions.
• Track upstream packages that depend on Picomatch and update parent packages where direct dependency override is not sufficient.