QQBot Multi-Bind

• Outcome: Review
• Latest audit: Sep 11, 2026 · 5:53 PM UTC
• Version: 1.0.1

Overview

This appears to be legitimate QQBot setup guidance, but it includes broad access and secret-handling examples that should be reviewed before installation.

Install only after pinning or reviewing the QQBot plugin source, avoid pasting real AppSecrets into shell commands, restrict config-file permissions, replace allowFrom ["*"] with explicit trusted QQ users or groups, and do not enable session visibility "all" unless you intentionally want broad cross-agent session access.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (4)

T08 · Insecure Dependencies

Error

• Location: SKILL.md:40

Finding

Unpinned Third-Party Code Is Retrieved and Executed

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 40–55
Vulnerability Type: Unpinned and mutable third-party dependencies
Risk Level: High

Vulnerable Code

bash

# Method A: npm installation
openclaw plugins install @tencent-connect/openclaw-qqbot

# Method B: source installation
git clone https://github.com/tencent-connect/openclaw-qqbot.git && cd openclaw-qqbot
bash ./scripts/upgrade-via-source.sh --appid YOUR_APPID --secret YOUR_SECRET

# Method C: manual installation
git clone https://github.com/tencent-connect/openclaw-qqbot.git && cd openclaw-qqbot
npm install --omit=dev
openclaw plugins install .

Technical Analysis

The installation instructions retrieve an npm package or clone a Git repository without pinning a reviewed package version, Git commit, signed release, or integrity hash. The source-based method then directly executes a shell script supplied by the mutable remote repository. The manual method also resolves npm dependencies without a demonstrated lockfile or integrity-verification procedure.

Consequently, the code executed during installation can differ from the code that was reviewed. An upstream repository compromise, malicious package release, compromised maintainer account, or dependency-chain compromise could introduce arbitrary code into the installation process.

Attack Path

1. An attacker compromises the npm package, source repository, maintainer account, or a transitive dependency.
2. The attacker publishes malicious content under the same package or repository identity.
3. An operator follows the Skill instructions and retrieves the current mutable content.
4. openclaw plugins install, the repository-provided shell script, or an npm lifecycle script executes the introduced payload.
5. The payload runs with the privileges of the operator performing the installation.

Impact Assessment

Successful exploitation could provide arbitrary code ...[truncated 323 chars]

Remediation

View remediation

Remediation Suggestions

• Pin the npm package to an explicitly reviewed version rather than installing the latest available release.
• Pin source installations to a full Git commit hash or cryptographically signed release tag.
• Verify package provenance, integrity metadata, release signatures, and repository ownership before installation.
• Review upgrade-via-source.sh and all invoked scripts before executing them.
• Use a committed lockfile and deterministic installation mode for npm dependencies.
• Perform installation in a restricted environment with minimal filesystem, credential, and network access.
• Document a trusted update process that requires review before changing pinned versions.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:47

Finding

QQBot Secrets Are Exposed Through Command-Line Arguments

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 47–48, 60–62, and 97–104
Vulnerability Type: Sensitive credentials in process arguments and shell history
Risk Level: High

Vulnerable Code

bash

git clone https://github.com/tencent-connect/openclaw-qqbot.git && cd openclaw-qqbot
bash ./scripts/upgrade-via-source.sh --appid YOUR_APPID --secret YOUR_SECRET

bash

openclaw channels add --channel qqbot --token "AppID:AppSecret"

bash

openclaw channels add --channel qqbot --account <account-id> --token "AppID:AppSecret"

bash

openclaw channels add --channel qqbot --account bot2 --token "222222222:secret-of-bot-2"

Technical Analysis

The documented commands place the QQBot AppSecret directly in command-line arguments. Command arguments may be recorded in shell history, terminal capture, diagnostic logs, audit systems, automation logs, or process metadata. On systems with permissive process inspection, another local user may be able to observe the secret while the command is running.

Quoting the token does not protect it from process listings or shell-history storage. The example also encourages operators to replace placeholders inline, increasing the likelihood that production credentials will be retained in logs or copied into support material.

Attack Path

1. An operator substitutes a real AppSecret into one of the documented commands.
2. The command is saved in shell history, captured by logging infrastructure, or exposed through process inspection.
3. A local user, support operator, log reader, or attacker with access to collected diagnostics retrieves the credential.
4. The attacker authenticates as the affected QQBot application.
5. The attacker abuses the bot identity until the credential is revoked or rotated.

Impact Assessment

Exposure may allow unauthorized use or impersonation of the QQBot application associated with the compromised A ...[truncated 307 chars]

Remediation

View remediation

Remediation Suggestions

• Replace command-line secret parameters with an interactive, non-echoing prompt.
• Alternatively, read secrets from a protected file descriptor or an approved secret-management service.
• Do not place secrets in environment variables unless their exposure characteristics are understood and appropriately controlled.
• Ensure the CLI and installation scripts redact secrets from logs, errors, and diagnostic output.
• Warn users not to paste credentials into shell commands, tickets, screenshots, or version-controlled files.
• Restrict access to terminal transcripts, process-monitoring systems, and audit logs.
• Rotate any credential that has already been entered into shell history or exposed in logs.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:133

Finding

Example Configuration Permits Every QQ Sender

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 133–149 and 186–195
Vulnerability Type: Unrestricted inbound authorization
Risk Level: High

Vulnerable Code

json

"channels": {
  "qqbot": {
    "enabled": true,
    "allowFrom": ["*"],
    "accounts": {
      "main": {
        "enabled": true,
        "appId": "1903000001",
        "clientSecret": "your-secret-here"
      },
      "<new-account-id>": {
        "enabled": true,
        "appId": "<new-app-id>",
        "clientSecret": "<new-secret>"
      }
    }
  }
}

json

"channels": {
  "qqbot": {
    "enabled": true,
    "allowFrom": ["*"],
    "accounts": {
      "main": { "enabled": true, "appId": "1903000001", "clientSecret": "secret-1" },
      "coding": { "enabled": true, "appId": "1903000002", "clientSecret": "secret-2" },
      "notify": { "enabled": true, "appId": "1903000003", "clientSecret": "secret-3" }
    }
  }
}

Technical Analysis

The wildcard value in allowFrom authorizes every sender instead of limiting access to explicitly trusted QQ identities or groups. This violates least-privilege principles and is not required to establish multi-account bindings.

If an operator copies the example into a live configuration, unknown and untrusted users may be able to deliver messages to the associated agents. Any tools or sensitive context available to those agents would then be exposed to interactions originating outside the intended trust boundary.

Attack Path

1. An operator copies the example configuration with "allowFrom": ["*"].
2. The QQBot channel is enabled and the gateway is started or restarted.
3. An untrusted user discovers or contacts the bot.
4. The gateway accepts the user's messages because the wildcard matches every sender.
5. The attacker interacts with the routed agent, attempts prompt injection, consumes resources, or induces use of any tool ...[truncated 465 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the wildcard with an explicit allowlist of trusted QQ user or group identifiers.
• Use a default-deny policy when allowFrom is absent or empty.
• Define access restrictions per account where different bots have different audiences.
• Grant exposed agents only the tools and data required for their role.
• Add rate limiting, authentication checks, abuse monitoring, and audit logging.
• Clearly label wildcard access as unsafe for production rather than presenting it in the primary example.
• Test authorization from both approved and unapproved accounts before deployment.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:221

Finding

Global Session Visibility Breaks Agent Isolation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 221–231
Vulnerability Type: Excessive cross-agent session permissions
Risk Level: High

Vulnerable Code

json

{
  "tools": {
    "sessions": {
      "visibility": "all"
    }
  }
}

The instructions then direct the operator to restart the gateway so this configuration becomes active.

Technical Analysis

Setting session visibility to all grants broad cross-agent access to session information. This weakens isolation between agents and exceeds the permissions required to install QQBot, add accounts, or configure account-to-agent routing.

Agents may operate at different trust levels or process data belonging to different users and workflows. Global visibility allows a compromised, publicly reachable, or lower-trust agent to inspect sessions outside its legitimate scope, creating a lateral data-access path.

Attack Path

1. An operator enables "visibility": "all" and restarts the gateway.
2. A publicly reachable or lower-trust agent is contacted, manipulated, or compromised.
3. The agent invokes session tooling under the globally permissive policy.
4. It enumerates or accesses sessions associated with other agents.
5. Sensitive conversation context or operational state is disclosed and may be used for additional attacks.

Impact Assessment

Successful exploitation may expose conversations, prompts, user information, operational context, and other session state belonging to unrelated agents. The affected scope can include every session made visible by the global configuration. Information recovered from those sessions may also facilitate social engineering, prompt injection, credential discovery, or lateral access to connected workflows.

Remediation

View remediation

Remediation Suggestions

• Keep cross-agent session visibility disabled by default.
• Use per-agent, per-user, or explicitly enumerated session scopes instead of all.
• Require an authorization decision before one agent can inspect another agent's sessions.
• Separate public-facing agents from agents handling sensitive data.
• Limit session tools to trusted agents and apply least-privilege tool permissions.
• Record and monitor cross-agent session access through tamper-resistant audit logs.
• Document the privacy consequences and require explicit administrative approval before enabling broader visibility.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The instructions tell users to pass QQBot secrets via CLI token arguments and store them directly in configuration files, but provide no warning about shell history, process listing exposure, file permissions, or secret rotation. This increases the chance of accidental credential disclosure, which could allow unauthorized use of the bot account or compromise of connected services.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The skill includes guidance to enable tools.sessions.visibility = "all", which expands cross-agent session access and is unrelated to QQBot multi-account binding. In a multi-agent deployment, this can unnecessarily weaken isolation boundaries and expose conversations or data across agents if operators follow the instructions without understanding the security implications.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 86% confidence

Finding

The file's instructional content forces a specific language/locale for all users without indicating that Chinese is optional or that other language support exists. Under SQP-3, language policy violations should be flagged when a skill imposes a language without user opt-in.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.