TT3: credential sent through urllib.request.build_opener(...).open() is not reported

[jamesjsanders]

Checked on v2.12.0 and main at 3527006, --no-llm.

behavioral_taint_tracking._NETWORK_OUTPUT_SINKS includes urllib.request.urlopen but not OpenerDirector.open. This is reported as TT3:

req = urllib.request.Request(URL, headers={"Authorization": "Bearer " + os.environ["API_KEY"]})
urllib.request.urlopen(req)

The same request sent through an opener is not:

urllib.request.build_opener().open(req)

So a common hardening step (an opener with a no-redirect handler, so the Authorization header cannot follow a redirect to another origin) silences the finding, and any skill can send an environment credential out this way without TT3 firing.

[agentsope]

I've opened #721 with a deliberately scoped, partial improvement: recognize directly chained build_opener(...).open(...) calls (including absolute import aliases and handler arguments), with conservative binding checks and regression tests. The behavioral taint module passes all 106 tests; the offline non-integration/non-provider suite passes 8,533 tests.

One separate gap surfaced during analyzer-level reproduction: nesting os.environ["API_KEY"] inside Request headers misses TT3 even for the direct urlopen(req) control on the tested main commit. With .get("API_KEY"), the control reports TT3 and #721 restores the inline opener finding. That nested-subscript propagation gap and opener instances first stored in variables remain outside this PR, so this issue should stay open. Happy to discuss whether this small step is useful before extending the scope.

[rng1995]

PR-state snapshot checked on 2026-10-04:

• PR #721 — open, non-draft; no aggregate review decision reported; latest reported check rollup: success.

PR #721 is explicitly partial: directly chained urllib openers only. Nested-subscript propagation and variable-bound opener gaps remain open.

Keeping this issue open: the relevant implementation is not merged and the remaining scope still needs verification. Check/review status is a point-in-time snapshot, not a claim of merge readiness.