-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Summary
The runtime no longer starts Flask-SocketIO from app.py with a hard-coded allow_unsafe_werkzeug=True call. That part was fixed by the bootstrap/runtime refactor.
The remaining gap is in nmapui/bootstrap.py: run_socketio_server() still enables Werkzeug whenever the app binds to 127.0.0.1 or localhost, even outside explicit debug mode.
Current Evidence
allow_unsafe_werkzeug = runtime_options["debug"] or runtime_options["host"] in {
"127.0.0.1",
"localhost",
}That means the app still defaults to the development server in the common local-daemon deployment path.
Why It Matters
Running on localhost reduces exposure, but it does not change the fact that Werkzeug is still a development server with weaker concurrency and operational behavior than a production-capable Socket.IO server.
This app performs long-running scan work and maintains persistent websocket-style client connections, so server/runtime behavior still matters for stability.
Proposed Fix
- Make the server backend explicit in runtime configuration.
- Default production-style runs to an async server/runtime that Flask-SocketIO supports cleanly.
- Reserve Werkzeug fallback for explicit debug/developer mode only.
- Document the supported local-daemon deployment model clearly.
Severity
Medium — narrower than the original report, but still a valid runtime-hardening issue.