s3transfer 0.19.3

Source: https://github.com/boto/s3transfer
Tag scanned: 0.19.3
Compared with: 0.19.2 (0 signals introduced since)
Files: 75 scanned, 4 skipped (binary, oversized, or unrecognised)
Signals: 0 critical · 0 warn · 4 info
Scan time: 6.3 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 4 of 4 warn and critical signals; 4 demoted to info.
Disclude version: 4.1.0
Scanned (UTC): 2026-10-21 21:28

Signals

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

info ~~warn~~ → info by review dynamic-execution scripts/new-change:123:13

`subprocess.Popen` called with `shell=True` and a literal command (ast pass, confidence 0.70)
```
        editor = env.get('VISUAL', env.get('EDITOR', 'vim'))
        p = subprocess.Popen(f'{editor} {f.name}', shell=True)
        p.communicate()
        with open(f.name) as f:
```
likely benign LLM, confidence 0.75 A developer helper script launches the user's editor through a shell on a temp file.
Reasoning
The shell=True call runs an editor name taken from the VISUAL/EDITOR environment variable, with a temp file path appended. This is a common, if sloppy, developer-tool pattern. The only inputs are the user's own environment and a temp file the script created, so there is no sign of obfuscation or malicious intent.
info ~~critical~~ → info by review dynamic-execution scripts/performance/benchmark:62:12

`subprocess.Popen` with `shell=True` and a non-literal command — runtime-determined shell invocation (ast pass, confidence 0.85)
```
def run_script(args):
    return subprocess.Popen(args.script, shell=True)
```
likely benign LLM, confidence 0.70 A benchmark script runs a user-supplied script path through a shell.
Reasoning
The command comes from a command-line argument (args.script) and is run with shell=True. That is a shell-injection risk if the argument is untrusted, but here the caller is the developer running a local benchmark tool. The code shows no encoding, hiding, or remote fetch, so this reads as a legitimate though unsafe design choice rather than a dropper.
info ~~critical~~ → info by review dynamic-execution scripts/stress/timeout:66:12

`subprocess.Popen` with `shell=True` and a non-literal command — runtime-determined shell invocation (ast pass, confidence 0.85)
```
def run_script(args):
    return subprocess.Popen(args.script, shell=True)
```
likely benign LLM, confidence 0.70 A stress-test helper runs a CLI-supplied script through a shell.
Reasoning
The snippet is identical to the benchmark script's run_script helper: a CLI-supplied command is run with shell=True by a local developer tool. It is an unsafe pattern worth noting, but the snippet shows no sign of malicious intent.
info ~~warn~~ → info by review encoding-base64 tests/unit/test_crt.py:183:22

base64-like blob (76 bytes, compression ratio 1.14) (raw pass, confidence 0.60)
```
                    'x-amz-id-2',
                    'xDbgdKdvYZTjgpOTzm7yNP2JPrOQl+eaQvUkFdOjdJoWkIC643fgHxdsHpUKvVAfjKf5F6otEYA=',
                ),
                ('Content-Type', 'application/xml'),
```
dismissed LLM, confidence 0.90 A test fixture contains a sample AWS x-amz-id-2 header value that the raw pass flagged as base64.
Reasoning
The high-entropy base64-like string is an x-amz-id-2 header value in a unit test for an S3 client. AWS request IDs look exactly like this, so the blob is test fixture data, not an encoded payload.

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.1.0
git clone https://github.com/boto/s3transfer s3transfer && cd s3transfer
git checkout 0.19.3
disclude scan --severity info --diff 0.19.2 .