Back to skill

Security audit

Slack Api Toolkit Free

Security checks for vulnerabilities and agentic risk

Overview

This Slack integration is coherent, but it needs review because Slack credentials and private workspace data may pass through a third-party gateway with broad read/write examples and limited safeguards documented.

Install only if you are comfortable trusting slack-gateway.com with Slack OAuth access and the Slack content you send or retrieve. Prefer a least-privilege Slack authorization, avoid private-channel and message-history reads unless necessary, confirm all message updates/deletes, rotate or revoke SGW_API_KEY after use, and review the CLI package source/version before global installation.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:92
Finding

Unpinned Global Installation of a Third-Party Slack Gateway CLI

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 92-95
Vulnerability Type: Supply-chain exposure through unpinned third-party dependencies
Risk Level: Medium

Vulnerable Code

bash
# NPM
npm install -g @slack-gateway/cli
# ...
# Or Homebrew
brew install slack-gateway/cli/sgw

Technical Analysis

The Skill directs users or an Agent with execution privileges to globally install a third-party CLI without specifying an audited version, cryptographic checksum, package signature, or trusted source revision. A global NPM installation may execute package lifecycle scripts under the invoking user's privileges. The Homebrew command similarly resolves the formula available from its configured repository at installation time.

Because no version is pinned, the code installed during a future Skill invocation can differ from the component that existed when the Skill was audited. Compromise of the package publisher, registry account, formula repository, or distribution infrastructure could therefore introduce arbitrary executable code.

This behavior is needed only if the third-party CLI is chosen as the integration mechanism; global and unpinned installation is not the minimum privilege necessary to call Slack APIs.

Attack Path

  1. An attacker compromises the package publisher, NPM package, Homebrew formula, or associated distribution account.
  2. The attacker publishes a malicious version under the expected dependency name.
  3. A user or Agent follows the Skill and executes the unpinned installation command.
  4. The package manager resolves and installs the malicious current version.
  5. Installation hooks or later CLI execution run attacker-controlled code with the user's privileges.
  6. The malicious component can access files, environment variables, stored gateway credentials, and network resources available to that account.

Impact Assessment

Successful exploitation could result in a ...[truncated 287 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin the CLI to a specific, security-reviewed version.
  • Publish and verify cryptographic checksums or package signatures before installation.
  • Identify the official publisher, source repository, and expected package provenance.
  • Prefer a project-local installation over a global installation.
  • Disable or carefully control package lifecycle scripts where possible.
  • Use a lockfile or immutable artifact reference for reproducible deployment.
  • Run the CLI in a sandbox or restricted service account without access to unrelated secrets.
  • Establish a dependency update and vulnerability-review process before changing the pinned version.

other

Error
Location
SKILL.md:155
Finding

Slack Credentials and Message Data Are Entrusted to a Third-Party Gateway

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 155-164
Vulnerability Type: Third-party credential and workspace-data exposure
Risk Level: High

Vulnerable Code

python
api_key = os.environ['SGW_API_KEY']
base_url = 'https://api.slack-gateway.com'
# ...
resp = requests.post(
    f'{base_url}/slack/api/chat.postMessage',
    headers={
        'Authorization': f'Bearer {api_key}',
        'Content-Type': 'application/json'
    },
    json={'channel': 'C0123456789', 'text': 'Hello from Python!'}
)
print(resp.json())

The Skill also states that the Slack OAuth token is managed by the gateway:

markdown
- **Slack OAuth Token**: Managed by the gateway, with the connection established through OAuth authorization; it is not stored locally.

Technical Analysis

The example deliberately sends the gateway API key and Slack message content to api.slack-gateway.com. The documented architecture also requires the gateway operator to manage a Slack OAuth token capable of acting on the authorized workspace.

This transfer is explicit and functionally necessary for the advertised hosted-OAuth design, so the observed behavior is not covert exfiltration. However, it creates a material third-party trust boundary: the gateway can observe request contents and may be able to perform Slack actions permitted by the OAuth grant.

The Skill does not document the gateway operator's identity, exact OAuth scopes, data-retention policy, request or content logging, encryption controls, tenant isolation, incident-response process, token protection, or revocation procedure. Consequently, users cannot determine whether credentials and Slack data receive protections appropriate to their sensitivity.

Attack Path

  1. A user creates a gateway account and grants the gateway OAuth access to a Slack workspace.
  2. The gateway stores or otherwise manages the resulting Slack OAuth token.
  3. The Age ...[truncated 949 chars]
Remediation
View remediation

Remediation Suggestions

  • Prefer direct use of Slack's official OAuth endpoints and APIs when hosted credential custody is unnecessary.
  • Clearly identify the gateway operator and publish its security, privacy, retention, deletion, and incident-response policies.
  • Document the exact Slack OAuth scopes requested and justify each scope.
  • Provide separate, least-privilege authorization profiles, including a send-only profile.
  • Encrypt tokens at rest using a dedicated key-management system and restrict decryption to the minimum required service identity.
  • Never log authorization headers, API keys, OAuth tokens, or message bodies by default.
  • Provide explicit procedures for rotating SGW_API_KEY and revoking the gateway's Slack OAuth authorization.
  • Use short-lived credentials where supported and monitor for anomalous gateway activity.
  • Require user confirmation before transmitting sensitive message content through the gateway.
  • Document tenant-isolation controls and provide independent security assurance before use with confidential workspaces.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:173
Finding

Broad Slack Workspace Enumeration Without Least-Privilege Safeguards

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 173-185
Vulnerability Type: Excessive access to private channels, message history, and user information
Risk Level: High

Vulnerable Code

bash
# List channels
sgw slack channel list --types public_channel,private_channel --limit 100
# ...
# View channel information
sgw slack channel view C0123456789
# ...
# View channel message history
sgw slack message list --channel C0123456789 --limit 50
# ...
# List users
sgw slack user list --limit 100
# ...
# Look up a user by email
sgw slack user lookup --email alice@example.com

Technical Analysis

The examples encourage enumeration of private channels, message history, workspace users, and email-linked user records. These read capabilities are not required for the primary notification use cases described elsewhere in the Skill, such as sending CI results or operational alerts.

The document recommends confirmation for create, update, and delete operations, but it does not impose equivalent confirmation requirements on privacy-sensitive reads. It also does not define minimum Slack OAuth scopes, restrict enumeration to channels explicitly identified by the user, or separate send-only access from administrative and read access.

If an Agent receives a broad OAuth grant, these commands allow it to retrieve substantially more information than is necessary for sending a notification. Retrieved information also transits the hosted gateway, expanding the exposure identified in the preceding finding.

Attack Path

  1. A user authorizes the hosted gateway with broad Slack read scopes.
  2. The Agent invokes channel enumeration with private_channel included.
  3. The Agent identifies accessible private channels and retrieves message history.
  4. The Agent enumerates workspace users or performs email-based user lookup.
  5. Slack returns the authorized information through the third-party ga ...[truncated 611 chars]
Remediation
View remediation

Remediation Suggestions

  • Make send-only Slack access the default authorization profile.
  • Separate message-sending, channel-reading, message-history, private-channel, and user-directory permissions into independently authorized capabilities.
  • Remove private_channel from default examples and require an explicit user request before accessing private channels.
  • Require confirmation before reading message history, enumerating users, or looking up personal information.
  • Limit retrieval to a user-specified channel and use the smallest practical result limit.
  • Display the requested OAuth scopes and their consequences before authorization.
  • Reject operations that are outside the scopes needed for the user's declared task.
  • Minimize returned user fields and avoid email lookup unless it is essential to the requested operation.
  • Record privacy-sensitive reads in an auditable log without recording message bodies, credentials, or unnecessary personal data.
  • Provide clear Slack and gateway revocation instructions after temporary access is no longer needed.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (7)

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

The description emphasizes '消息收发与频道管理核心能力' and lists channel/user info query as the main supported features, while the examples later document sgw slack message list for channel history access and user lookup --email, which expand into broader message retrieval and directory search behavior. These are materially broader than a narrow send/reply plus channel-management toolkit presentation for the free tier.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The description says to use the skill for broad situations like API integration, interface docking, webhook configuration, and system connection, but it does not define specific trigger phrases, boundaries, or exclusion examples beyond one unrelated negative case. This ambiguity could cause the skill to be invoked for many common integration tasks beyond the intended Slack-specific scope.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The coverage statement lists many generic keywords such as '安全调用', 'Webhook', '系统连接时使用', and even fragmented terms, implying the skill may match on broad everyday integration language rather than precise Slack tasks. Because there are no limiting conditions or negative examples, this creates a high risk of unintended invocation collisions.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
93% confidence
Finding

The skill instructs the agent to send authenticated requests containing a bearer API key to an external third-party service endpoint. In an agent context with exec capability, this creates real external data transmission risk: prompts, channel IDs, message content, and sensitive workspace metadata may be sent off-platform, and users may not understand that a separate gateway service is receiving and processing those requests.

Content

Scanner excerpt · SKILL.md (reported line 158)May include surrounding context.

md
api_key = os.environ['SGW_API_KEY']
base_url = 'https://api.slack-gateway.com'
# ...
resp = requests.post(
    f'{base_url}/slack/api/chat.postMessage',
    headers={
        'Authorization': f'Bearer {api_key}',

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
86% confidence
Finding

The display name and summary are presented only in Chinese, and the rest of the skill instructions are predominantly Chinese without indicating that the user can choose another language. This can violate language or locale policy when users have not opted into Chinese output.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Low
Category
Not specified by scanner
Confidence
75% confidence
Finding

The capability sections describe abstract operations such as '创建/查询/导出', '修改/重置/导入', and '导出/保存/转换操作' without tying them to Slack-specific limits, which conflicts with the earlier narrow free-tier scope and the later statement that batch and other advanced features are unsupported. This creates an intent-level mismatch about how broad the skill's operational surface really is.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low
Category
Not specified by scanner
Confidence
90% confidence
Finding

The scenario presents daily scheduled reporting as a straightforward use case, which reads as endorsed functionality. Later, the known limitations explicitly say '不支持定时消息', creating a contradiction in documented intent about whether scheduling is part of the supported behavior.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.