Proposal: Detecting Flask file-serving API misuse

[invoke1442]

Is your feature request related to a problem? Please describe.
Yes. I'm using Bandit on Flask code and ran into a gap around send_file().

Bandit already has targeted plugins for specific risky APIs and framework misuse, for example B201 for Flask debug mode and B202 for unsafe tarfile.extractall(). But there does not seem to be a similar plugin for a very common Flask pattern: passing a request-controlled path into send_file().

A real example is CVE-2025-6166 in Agent-Zero:

path = input.get("path", request.args.get("path", ""))
if not path:
    raise ValueError("No path provided")
return send_file(path)

This ended up as a false negative in my Bandit baseline run, even though it is a straightforward arbitrary file read / path traversal case.

Similar Flask send_file traversal cases also exist in:

• CVE-2022-31583
• CVE-2022-31549
• CVE-2022-31506

Describe the solution you'd like
I'd like a small Flask-specific plugin that warns when send_file() is called with a path taken directly from common request accessors such as:

• request.args.get(...)
• request.form.get(...)
• request.values.get(...)

A minimal first version could stay narrow and only cover:

• direct use inside the call, or
• a simple local assignment right before the call

For example:

return send_file(request.args.get("path"))

or

path = request.args.get("path")
return send_file(path)

This feels similar in spirit to other Bandit plugins that target one dangerous API pattern without trying to do full taint tracking.

Describe alternatives you've considered
I first looked for an existing Bandit plugin that could be extended, but I couldn't find one that was close enough. B202 is the nearest match conceptually because it covers a path-traversal-style misuse of a specific API, but it is limited to archive extraction.

I also considered asking for a more general request-to-file-path plugin, but that seems broader than Bandit's scope. A narrow send_file() plugin looks like the smallest useful change.

Additional context
I implemented a plugin prototype according to one of CodeQL's rules for Flask, which could be used as a reference. It worked well on my project, and could detect CVE-2025-6166 and CVE-2022-31549 with no FPs on fixed commits.

flask-secure-static-file.zip

Love this idea? Give it a 👍. We prioritize fulfilling features with the most 👍.

[Varshith-Kali]

I'd like to pick this up. Plan:

1. New plugin bandit/plugins/flask_send_file.py registered as B905 (next free B-number — verified B704 is the current max in the B7xx range, and the B9xx range appears unused; happy to use a different number if maintainers prefer).
2. Detection scope (narrow first version per the issue):
   • Flag send_file(...) calls where the path argument is directly a request.args.get(...) / request.form.get(...) / request.values.get(...) call.
   • Flag send_file(...) calls where the path argument is a simple local variable that was assigned from one of those request accessors in the same function scope (AST-level, no interprocedural dataflow).
3. Severity: MEDIUM, Confidence: MEDIUM (consistent with B201 Flask debug, which is HIGH/MEDIUM — but file-read path traversal is typically lower severity than RCE).
4. CWE: CWE-22 (Path Traversal).
5. Tests: tests/functional/test_functional.py entry + examples/flask_send_file.py with positive and negative cases (request-controlled path → flagged; hardcoded path → not flagged; send_file called without flask imported → not flagged, to avoid false positives on unrelated send_file definitions).
6. Docs: plugin docstring per the existing RST convention used in app_debug.py (B201), with CVE references (CVE-2025-6166, CVE-2022-31583, CVE-2022-31549, CVE-2022-31506).
7. setup.cfg: register the new entry point.

Will follow up with a PR once I have a working draft. Maintainers — please flag if B905 isn't the right number, or if the scope should be narrower/wider.