virtualenv 21.14.11

Source: https://github.com/pypa/virtualenv
Tag scanned: 21.14.11
Compared with: 21.14.10 (0 signals introduced since)
Files: 208 scanned, 33 skipped (binary, oversized, or unrecognised)
Signals: 0 critical · 0 warn · 14 info
Scan time: 10.3 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 10 of 10 warn and critical signals; 10 demoted to info.
Disclude version: 4.0.0
Scanned (UTC): 2026-10-18 09:41

Signals

Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.

info ~~critical~~ → info by review dynamic-import docs/render_cli.py:40:34

`__import__` called on a non-literal expression (ast pass, confidence 0.70)
```
        module_name, attr_name = self.options["module"], self.options["func"]
        parser_creator = getattr(__import__(module_name, fromlist=[attr_name]), attr_name)
        core_result = parse_parser(parser_creator())
```
likely benign LLM, confidence 0.80 Documentation renderer dynamically imports a configured parser-creator module and function.
Reasoning
The __import__ call loads a module named in the options dict, which is a standard pattern for documentation tooling that resolves a parser factory by configured module and function name. The target is set by the documentation author, not by untrusted input, and the code then calls the resolved function as a normal documentation step.
info ~~critical~~ → info by review dynamic-import docs/render_cli.py:236:20

`__import__` called on a non-literal expression (ast pass, confidence 0.70)
```
    of_class = of_type.split(".")
    data = getattr(__import__(".".join(of_class[:-1]), fromlist=[of_class[-1]]), of_class[-1])
    return [n.literal("", text=",".join(data))], []
```
likely benign LLM, confidence 0.80 Documentation renderer resolves a dotted class name via __import__ to read a data attribute for display.
Reasoning
The import path is derived from a dotted type string split into module and class parts, the same resolve-by-name pattern used by documentation generators. Nothing in the snippet shows an attacker-controlled or network-sourced input, and the resolved attribute is only used to format text.
info ~~warn~~ → info by review dynamic-execution docs/tutorial/getting-started.rst:102:21

[embedded bash] command name is a variable (`$which`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
        (myproject) $ which python
        /home/user/myproject/bin/python
```
likely benign LLM, confidence 0.90 Tutorial shell-prompt example misparsed as a variable command name.
Reasoning
The flagged token is the shell prompt sample '$ which python' inside a reStructuredText tutorial. The '$' is a prompt marker, not a variable used as a command name, so the finding comes from parsing documentation text as shell.
info ~~critical~~ → info by review path-command-shadow docs/tutorial/getting-started.rst:109:23

[embedded bash] redirect writes to `python` — filename matches a system command (PATH hijack setup) (ast pass, confidence 0.88)
```
        (myproject) PS> where.exe python
        C:\Users\user\myproject\Scripts\python.exe
```
dismissed LLM, confidence 0.90 Windows tutorial output example falsely flagged as a PATH-shadowing redirect.
Reasoning
The snippet is the output of a 'where.exe python' example shown in a Windows tutorial, which is a sample path rather than a command redirected to a file. The 'python' token is a filename-like word in the output, so the PATH-hijack reading does not fit this documentation context.
info ~~warn~~ → info by review obfuscated-command-name docs/tutorial/getting-started.rst:110:9

[embedded bash] command name contains 5 backslash-escape sequences — hiding the true command (ast pass, confidence 0.85)
```
        (myproject) PS> where.exe python
        C:\Users\user\myproject\Scripts\python.exe
```
dismissed LLM, confidence 0.90 Windows path separators in tutorial output misread as backslash escapes in a command name.
Reasoning
The backslashes are ordinary Windows path separators in the sample output C:\Users\...\python.exe. The parser treated the path as an escape-sequence command name, and nothing is hidden or obfuscated.
info ~~warn~~ → info by review obfuscated-command-name docs/tutorial/getting-started.rst:117:9

[embedded bash] command name contains 5 backslash-escape sequences — hiding the true command (ast pass, confidence 0.85)
```
        (myproject) C:\> where.exe python
        C:\Users\user\myproject\Scripts\python.exe
```
dismissed LLM, confidence 0.90 Windows path in tutorial output flagged as an obfuscated command name.
Reasoning
This is a tutorial sample of 'where.exe python' output with a standard Windows path. The backslash count comes from path separators, not obfuscation of a command name.
info ~~warn~~ → info by review dynamic-execution docs/tutorial/getting-started.rst:127:17

[embedded bash] command name is a variable (`$pip`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
    (myproject) $ pip install requests
    Collecting requests
      Using cached requests-2.32.3-py3-none-any.whl (64 kB)
```
likely benign LLM, confidence 0.90 Tutorial prompt example with pip misread as a variable command name.
Reasoning
The '$ pip install requests' line is a standard shell prompt example in a Python packaging tutorial. The 'pip' token is an ordinary, expected command name in this context.
info ~~warn~~ → info by review dynamic-execution docs/tutorial/getting-started.rst:137:17

[embedded bash] command name is a variable (`$python`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
    (myproject) $ python -c "import requests; print(requests.__file__)"
    /home/user/myproject/lib/python3.13/site-packages/requests/__init__.py
```
likely benign LLM, confidence 0.90 Tutorial prompt example with python misread as a variable command name.
Reasoning
The '$ python -c ...' line is a documentation prompt example showing a normal interpreter invocation that prints a package path. It is benign tutorial content.
info ~~warn~~ → info by review obfuscated-command-name docs/tutorial/getting-started.rst:176:9

[embedded bash] command name contains 3 backslash-escape sequences — hiding the true command (ast pass, confidence 0.85)
```
        PS> .\myproject\Scripts\python.exe -c "import sys; print(sys.prefix)"
        C:\Users\user\myproject

        PS> .\myproject\Scripts\pip.exe install httpx
```
dismissed LLM, confidence 0.90 Relative Windows venv path in tutorial misflagged as obfuscated command name.
Reasoning
The backslashes are Windows relative path separators in a PowerShell example invoking a virtualenv interpreter. The escape-sequence reading is a parser artifact and nothing is obfuscated.
info ~~warn~~ → info by review obfuscated-command-name docs/tutorial/getting-started.rst:185:9

[embedded bash] command name contains 3 backslash-escape sequences — hiding the true command (ast pass, confidence 0.85)
```
        C:\> .\myproject\Scripts\python.exe -c "import sys; print(sys.prefix)"
        C:\Users\user\myproject

        C:\> .\myproject\Scripts\pip.exe install httpx
```
dismissed LLM, confidence 0.90 Relative Windows venv path in tutorial misflagged as obfuscated command name.
Reasoning
This is the same relative Windows venv invocation style used in the tutorial, with backslashes as path separators. It is ordinary documentation for running pip and python from a virtualenv.

info unicode-homoglyph tests/conftest.py:310:47

identifier `èрт` contains homoglyph candidates: р (0440)→p (in string/comment) (raw pass, confidence 0.35)

    # in PowerShell paths
    base = "'\";&&e-$ !%`|>__VIRTUAL_NAME__[1]èрт🚒♞中片-j"
    if IS_WIN:
        # NTFS path components cannot contain any of these, regardless of where they sit in the string

info unicode-mixed-script tests/conftest.py:310:47

identifier `èрт` mixes scripts: Latin + Cyrillic (in string/comment) (raw pass, confidence 0.40)

    # in PowerShell paths
    base = "'\";&&e-$ !%`|>__VIRTUAL_NAME__[1]èрт🚒♞中片-j"
    if IS_WIN:
        # NTFS path components cannot contain any of these, regardless of where they sit in the string

info unicode-homoglyph tests/unit/activation/test_batch.py:27:21

identifier `èрт` contains homoglyph candidates: р (0440)→p (in string/comment) (raw pass, confidence 0.35)

    """Exclude ampersands, which batch activation does not support in paths."""
    base = "'\";e-$ èрт🚒♞中片-j"
    if IS_WIN:
        base = base.replace('"', "").replace(";", "")

info unicode-mixed-script tests/unit/activation/test_batch.py:27:21

identifier `èрт` mixes scripts: Latin + Cyrillic (in string/comment) (raw pass, confidence 0.40)

    """Exclude ampersands, which batch activation does not support in paths."""
    base = "'\";e-$ èрт🚒♞中片-j"
    if IS_WIN:
        base = base.replace('"', "").replace(";", "")

Reproduce This Scan

Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.

cargo install disclude --version 4.0.0
git clone https://github.com/pypa/virtualenv virtualenv && cd virtualenv
git checkout 21.14.11
disclude scan --severity info --diff 21.14.10 .