Back to skill

Security audit

Slack Standup

Security checks for vulnerabilities and agentic risk

Overview

This Slack standup skill is broadly aligned with its stated purpose, but it ships risky credential handling and live-posting behavior that users should review before installing.

Review this before installing. Use only a newly created, least-privileged Slack bot token, avoid `chat:write.public` and `channels:read` unless you truly need them, and treat `/standup test` as a live post unless the package is changed. Do not use the packaged hardcoded token value; remove or replace it with a secure environment variable and rotate any token that may have been exposed.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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 (2)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/slack-standup.sh:7
Finding

Hardcoded Slack Bot Credential in Executable Script

Content
View full analysis

Vulnerability Details

File Location: scripts/slack-standup.sh:7-10
Vulnerability Type: Hardcoded credential
Risk Level: High

bash
# Configuration
SLACK_TOKEN="xoxb-12345678901-1234567890"
CHANNEL="#standup"
TIME="09:00"

Technical Analysis

The executable script embeds a Slack-style bot token directly in source code. Credentials committed to a repository or distributed package are accessible to every person and system that can read the package, including source-control history, build logs, caches, and installed copies.

Although the observed value may be an example or placeholder, the script treats it as an operational credential and sends it in the Authorization header at scripts/slack-standup.sh:15. If the value is valid—or is replaced with a valid token and subsequently committed—no additional authentication barrier prevents its misuse. This also contradicts the warning in references/SETUP.md:29 not to commit tokens.

Attack Path

  1. An attacker obtains a copy of the repository, package, build artifact, backup, or source-control history.
  2. The attacker extracts the xoxb-* value from scripts/slack-standup.sh.
  3. The attacker submits Slack Web API requests using Authorization: Bearer <token>.
  4. If the token is valid, Slack accepts requests under the bot identity.
  5. The attacker can exercise every OAuth scope granted to that bot until the credential is revoked or expires.

Impact Assessment

A valid exposed token permits impersonation of the Slack bot and use of its granted workspace permissions. Under the documented configuration, this may include posting messages, posting to public channels without membership, and enumerating public channels. The precise workspace and data exposure depend on whether the displayed token is valid and which scopes were granted.

Remediation
View remediation

Remediation Suggestions

  1. Remove the embedded token and immediately revoke or rotate it if it was ever valid.
  2. Read the token from a protected environment variable or secrets manager:
    bash
    SLACK_TOKEN="${SLACK_BOT_TOKEN:-}"
    
  3. Terminate safely when the variable is missing:
    bash
    if [[ -z "$SLACK_TOKEN" ]]; then
        printf '%s\n' "SLACK_BOT_TOKEN is required" >&2
        exit 1
    fi
    
  4. Ensure secrets are never printed in command traces, logs, diagnostics, or Slack API error output.
  5. Add secret scanning to pre-commit hooks and CI, including detection of Slack xoxb-* tokens.
  6. Review repository history and distributed artifacts because deleting the current line does not remove historical copies.
  7. Store production secrets with restricted read permissions and rotate them periodically and after any suspected disclosure.

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
references/SETUP.md:6
Finding

Slack Bot Is Instructed to Request Permissions Beyond Implemented Requirements

Content
View full analysis

Vulnerability Details

File Location: references/SETUP.md:6-9
Vulnerability Type: Excessive OAuth permissions and violation of least privilege
Risk Level: Medium

markdown
## 2. Permissions
- OAuth & Permissions → Add scopes:
  - `chat:write` | `chat:write.public` | `channels:read`

Technical Analysis

The reviewed scripts only invoke Slack's chat.postMessage API. The setup instructions nevertheless request chat:write.public and channels:read in addition to chat:write.

chat:write.public expands the bot's posting capability to public channels that it has not joined. channels:read permits public-channel discovery and metadata enumeration. Neither capability is required by the implemented message-posting behavior, which can operate with chat:write after the bot is invited to the intended channel as instructed elsewhere in the setup guide.

Excess permissions do not independently compromise the workspace, but they increase the privileges available to anyone who compromises the bot token. This is particularly relevant because the package also contains a hardcoded Slack-style token.

Attack Path

  1. A workspace administrator follows the setup guide and grants all documented OAuth scopes.
  2. An attacker acquires the bot token through source exposure, logs, a compromised host, or another credential leak.
  3. The attacker authenticates to the Slack Web API as the bot.
  4. Using channels:read, the attacker enumerates public channels and associated metadata.
  5. Using chat:write.public, the attacker posts bot-authored content to public channels even where the bot is not a member.
  6. The attacker may use this expanded reach for spam, phishing, social engineering, or workspace disruption.

Impact Assessment

A compromised bot credential receives broader workspace visibility and messaging reach than the implemented standup function requires. The attacker may discover public-channe ...[truncated 256 chars]

Remediation
View remediation

Remediation Suggestions

  1. Reduce the documented OAuth configuration to chat:write.
  2. Require administrators to invite the bot only to the designated standup channel.
  3. Remove chat:write.public unless posting to public channels without membership becomes an explicit, reviewed requirement.
  4. Remove channels:read unless channel discovery is implemented and necessary.
  5. Document the purpose of every requested scope and map it to a specific application feature.
  6. Reinstall or reauthorize existing Slack applications after scope reduction so previously issued tokens no longer retain unnecessary permissions.
  7. Periodically review granted scopes in Slack and revoke capabilities that are no longer used.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (7)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The skill describes automated collection of team updates and posting summaries to Slack, but it does not warn users that message content will be collected, aggregated, and reposted to a channel. This creates a privacy and consent gap: users or administrators may enable the skill without understanding the visibility of submitted content, which can lead to unintended disclosure of sensitive work information.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The header comments state the script will 'Collect daily updates from team members' and 'Post summary to Slack channel'. In the actual code, each iteration sends a message asking a user for an update via chat.postMessage and then appends the API response metadata to the responses array; it does not retrieve team member replies or post any summary.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
99% confidence
Finding

The script contains a hardcoded Slack bearer token and uses it to make authenticated external API calls. Embedding live credentials in a script is dangerous because anyone with access to the file, logs, backups, or repository history can reuse the token to post messages or potentially access other Slack resources permitted by that token.

Content

Scanner excerpt · scripts/slack-standup.sh (reported line 15)May include surrounding context.

sh
# Collect responses
responses=()
for user in user1 user2 user3; do
    response=$(curl -s -X POST https://slack.com/api/chat.postMessage \
        -H "Authorization: Bearer $SLACK_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"channel\":\"$CHANNEL\",\"text\":\"$user, what did you do today?\"}")

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

This shell script makes outbound HTTP requests to Slack containing user names and message content, but the file provides no confirmation prompt or user-facing disclosure beyond internal comments. For code files, network calls that transmit user or system data should have some visible warning unless the disclosure appears elsewhere.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

The script posts a standup prompt to Slack via an HTTP request, which transmits workspace/channel data and message content to an external service. While there is a log after sending, there is no prior user disclosure, confirmation, or explanatory comment/docstring warning that invoking this command will send a real message to Slack.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
70% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · scripts/standup.sh (reported line 18)May include surrounding context.

sh
send_prompt() {
    msg='{"channel":"'"$CHANNEL_ID"'","text":"🎯 *Daily Standup*\nUpdates:\n• Yesterday?\n• Today?\n• Blockers?","as_user":true}'
    curl -s -X POST -H "Authorization: Bearer $SLACK_TOKEN" -H "Content-Type: application/json" -d "$msg" https://slack.com/api/chat.postMessage
    log_info "Prompt sent"
}

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The script's test mode is misleading because it logs Test mode... but still performs a live send_prompt call to Slack. This can cause unintended messages to be sent during validation, CI, or operator testing, creating operational risk and violating user expectations about non-destructive test behavior.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.