Security audit

bluebubbles

Security checks for vulnerabilities and agentic risk

Overview

This messaging skill is coherent, but its sample configuration encourages broad access and insecure transport for a password-protected messaging server.

Review before installing. Use HTTPS or a trusted TLS reverse proxy for the BlueBubbles server, avoid wildcard allowed_senders, restrict sender handles to trusted contacts, and treat attachments as sensitive because the skill is designed to send them outside the local workspace.

A.I.G

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

Warning

Location: SKILL.md:24
Finding: Plaintext HTTP Used for Password-Authenticated Messaging Server
Content: View full analysis
Vulnerability Details

File Location: SKILL.md, lines 24–25
Vulnerability Type: Plaintext transmission of credentials and messaging traffic
Risk Level: Medium

Complete Code Snippet:

toml
server_url = "http://192.168.1.100:1234" # Your BlueBubbles server URL password = "your-server-password"

Technical Analysis

The documented configuration uses an unencrypted HTTP endpoint for a server that requires password authentication. HTTP does not provide transport confidentiality, integrity, or server authentication. If the password or authenticated session information is transmitted through this connection, an attacker with network visibility could capture credentials or messaging data. An active network attacker could also modify traffic or impersonate the configured server.

The issue is particularly sensitive because the integration supports message transmission and attachment handling. Although the example uses a private-network address, local networks must not be assumed to be trusted or immune to interception.

Attack Path

A user adopts the documented http:// configuration.

An attacker gains visibility or an active interception position on the same network, such as through a compromised router, hostile wireless access point, or ARP spoofing.

The gateway communicates with the BlueBubbles server without TLS protection.

The attacker captures authentication material or alters the HTTP exchange.

Using any recovered credentials or session information, the attacker attempts to access the server and invoke the messaging operations available to that account.

Impact Assessment

Successful exploitation could expose the BlueBubbles server password, message contents, attachment data, message metadata, and recipient identifiers. Depending on the permissions granted by the server, an attacker could impersonate the authorized user, send unauthorized messages, or perform other supported ...[truncated 132 chars]
Remediation: View remediation
Remediation Suggestions

Replace the example endpoint with an https:// URL and explicitly require TLS for all server connections.

Reject plaintext HTTP endpoints by default. If legacy HTTP support is unavoidable, require an explicit insecure override accompanied by a prominent warning.

Validate server certificates and hostnames; do not disable certificate verification.

Document how to configure a trusted certificate or a TLS-terminating reverse proxy for self-hosted deployments.

Store the server password in an appropriate secret-management facility rather than ordinary configuration where supported.

Rotate the server password if it has previously been transmitted over an untrusted plaintext connection.

Consider certificate pinning or mutually authenticated TLS for deployments with elevated security requirements.

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: SKILL.md:26
Finding: Wildcard Sender Allowlist Grants Unrestricted Access
Content: View full analysis
Vulnerability Details

File Location: SKILL.md, line 26
Vulnerability Type: Overly permissive sender authorization
Risk Level: Medium

Complete Code Snippet:

toml
allowed_senders = ["*"] # Allow all senders, or list specific handles

Technical Analysis

The example configuration uses a wildcard sender allowlist, authorizing every sender rather than restricting access to explicitly trusted handles. This violates least-privilege principles and makes sender-based access control ineffective.

If inbound BlueBubbles messages are processed by the gateway or can initiate agent actions, any person capable of contacting the configured messaging account may be treated as an authorized sender. The ultimate effect depends on the tools and permissions exposed to message-originated requests, but the wildcard unnecessarily broadens the authorization boundary.

Attack Path

An administrator copies the documented configuration with allowed_senders = ["*"].

An untrusted person obtains or already knows a handle associated with the configured messaging account.

The attacker sends a message to that account.

The wildcard allowlist accepts the attacker as an authorized sender.

The message reaches the gateway or agent workflow.

The attacker submits requests intended to trigger any capabilities exposed to inbound messages, subject to the gateway's remaining authorization controls.

Impact Assessment

Exploitation could permit unauthorized interaction with the gateway, consumption of processing resources, and attempted invocation of agent capabilities available to inbound senders. If sensitive tools are exposed without additional confirmation or authorization, the attacker could potentially trigger messaging or other actions under the gateway's privileges. The precise scope is constrained by downstream tool permissions and any additional access controls not shown in the audited file.
Remediation: View remediation
Remediation Suggestions

Replace the wildcard example with an explicit allowlist containing only trusted phone numbers, email addresses, or messaging handles.

Deny unknown senders by default and require administrators to opt in deliberately before enabling unrestricted access.

Normalize and validate sender identifiers before comparing them with allowlist entries to prevent formatting-based authorization bypasses.

Apply separate authorization checks for sensitive tools rather than relying solely on sender identity.

Require explicit user confirmation for consequential actions such as sending attachments, messaging new recipients, editing messages, or deleting messages.

Add rate limits, audit logging, and alerts for rejected senders and repeated authorization failures.

Document the security implications of wildcard access prominently if the option must remain supported.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The skill enables sending messages and attachments to external recipients via a self-hosted BlueBubbles server, but the documentation does not prominently warn users that these actions transmit data off the local system to other people and infrastructure. This can lead to unintended disclosure of sensitive content, especially because examples make outbound messaging easy and the sample configuration permits all senders by default.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.