Slack Mpm MCP Server

This server (without client built-ins) exposes a complete data-exfiltration chain: get_thread_replies → list_files ⇒ send_message. Untrusted input is ingested, private data is read, and it can be sent to an external sink — and at least one leg is a direct schema wire (⇒), where a producer's output drops straight into a free-text parameter of the next tool, so the chain needs little agent cooperation. Static analysis proves the primitive exists, not that a specific run will occur.

Fix: Remove one leg of the trifecta: isolate untrusted-input tools from secret-reading tools and from egress tools, or require human approval between them.

Location: flow get_thread_replies → list_files → send_message

Tool "upload_file" can both read sensitive data and send data to an external destination. Even without an explicit untrusted-input leg, this is a single-call data-exfiltration path if the model is ever manipulated.

Fix: Separate reading from sending; require explicit user confirmation before egress of file/secret contents.

Location: flow upload_file

Tool "delete_file" can write, overwrite or delete files (keyword "delete_file" in tool name). Verify it is scoped to a safe directory.

Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.

Location: tool delete_file

In the server's implementation (`src/slack_mpm/cli/main.py:112`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: try: __import__(module) click.echo(f" {name}: [{click.style('OK', fg='green')}]")

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server src/slack_mpm/cli/main.py

A hardcoded Slack token (a live-looking credential hardcoded in shipped code) appears in `tests/test_auth.py:98`. Verify whether this is a real credential; if so, remove and rotate it.

Evidence: Slack token: xoxb…(redacted)

Fix: Remove the secret, rotate it, and load credentials from the environment or a secret store.

Location: server tests/test_auth.py

Tool "delete_file" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.

Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.

Location: tool delete_file

Tool "upload_file" takes a path parameter "file_path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool upload_file · inputSchema.properties.file_path

Tool "upload_file" takes a path parameter "filename" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool upload_file · inputSchema.properties.filename

Tool "delete_file" takes a path parameter "file" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool delete_file · inputSchema.properties.file