Back to skill

Security audit

EngageLab WhatsApp Business

Security checks for vulnerabilities and agentic risk

Overview

The skill is a real EngageLab WhatsApp API helper, but it handles high-impact messaging credentials and business resources with under-scoped safeguards.

Review before installing. Use only with scoped EngageLab credentials, do not override the API base URL except in a controlled test environment with non-production keys, confirm exact templates before deletion, and add independent webhook protections such as a shared-secret gateway, schema validation, replay checks, and rate limiting before trusting callbacks.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/whatsapp_client.py:47
Finding
Basic Authentication Credentials Can Be Disclosed to a Caller-Controlled API Origin<![CDATA[ ## Vulnerability Details **File Location**: `scripts/whatsapp_client.py`, lines 47–58 **Vulnerability Type**: Credential disclosure through an unrestricted API base URL **Risk Level**: High ### Vulnerable Code ```python def __init__(self, dev_key: str, dev_secret: str, base_url: str = BASE_URL): auth = base64.b64encode(f"{dev_key}:{dev_secret}".encode()).decode() self._headers = { "Content-Type": "application/json", "Authorization": f"Basic {auth}", } self._base_url = base_url.rstrip("/") def _request(self, method: str, path: str, payload: Optional[dict] = None, params: Optional[dict] = None): url = f"{self._base_url}{path}" resp = requests.request(method, url, headers=self._headers, json=payload, params=params) ``` ### Technical Analysis The constructor accepts an unrestricted `base_url`, while `_request()` unconditionally sends the stored HTTP Basic Authorization header to the resulting origin. No validation ensures that the destination uses HTTPS or belongs to the expected EngageLab API host. The flagged Base64 operation is not, by itself, a covert output or exfiltration mechanism. Base64 encoding is required by the documented HTTP Basic authentication protocol, and the encoded value is not printed to stdout. However, Base64 provides no confidentiality: anyone receiving the header can decode it into `dev_key:dev_secret`. The behavior exceeds minimum privilege when arbitrary API origins are permitted to receive the credentials. The declared functionality only requires sending authentication data to the trusted EngageLab API endpoint. ### Attack Path 1. An attacker or compromised configuration influences the `base_url` argument passed to `EngageLabWhatsApp`. 2. The application initializes the client with valid EngageLab credentials and the attacker-controlled URL. 3. The application invokes any message or template API method. 4. `_request()` sends the `Authorization: Basic ...` header to the attacker-co ...[truncated 798 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove the `base_url` override if custom API origins are not required. - Otherwise, validate the URL before storing or using it: - Require the `https` scheme. - Allowlist the exact expected hostname, `wa.api.engagelab.cc`. - Reject embedded credentials, unexpected ports, and hostname suffix tricks. - Disable automatic redirects for authenticated requests, or validate every redirect target before forwarding the Authorization header. - Prefer `requests.auth.HTTPBasicAuth` or an equivalent authentication facility to reduce manual credential handling. - Add an explicit network timeout to prevent indefinite blocking. - Never include Authorization headers or encoded credentials in logs, exceptions, debug output, or Agent-visible responses. - If testing against another endpoint is necessary, require separate non-production credentials and an explicit development-only configuration. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/callback-api.md:15
Finding
Callback Integration Guidance Requires an Unauthenticated Webhook Endpoint<![CDATA[ ## Vulnerability Details **File Location**: `references/callback-api.md`, lines 15–22 **Vulnerability Type**: Missing webhook authentication and event-integrity validation **Risk Level**: Medium ### Vulnerable Guidance ```markdown ## Setup Configure callback URLs in the [EngageLab console](https://www.engagelab.com) under callback settings. Your endpoint must: - Accept `POST` requests with `Content-Type: application/json` - Return HTTP 200 within 3 seconds - Not require authentication (callback security mechanism is pending) ``` ### Technical Analysis The documentation instructs integrators to expose an endpoint that does not require authentication. The same callback interface carries delivery and read statuses, user messages, orders, phone numbers, WhatsApp account identifiers, and business-level notifications. No alternative integrity controls are prescribed, such as: - Provider signatures or a shared secret. - Source-network restrictions. - Timestamp and replay validation. - Strict schema validation. - Rate limiting and idempotency controls. Consequently, a handler implemented according to this guidance cannot reliably distinguish legitimate EngageLab events from attacker-generated requests. Although a provider limitation may explain the absence of native callback authentication, advising an entirely unauthenticated endpoint without compensating controls creates an exploitable integration pattern. ### Attack Path 1. An attacker discovers, observes, or guesses the callback URL. 2. The attacker constructs JSON matching one of the documented callback schemas. 3. The attacker submits a forged delivery event, user reply, order, or system notification. 4. The endpoint accepts the request because it has no authentication or event-integrity check. 5. Downstream automation treats the forged event as legitimate. 6. The attacker repeats or varies requests to manipulate workflows or exhaust endpoint resources. ### Impact Assessment Depending on how ...[truncated 544 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Where native provider signatures are unavailable, document and implement compensating controls: - Place the callback endpoint behind an independently controlled gateway that verifies a high-entropy shared secret. - Use a high-entropy, unguessable callback path, while recognizing that URL secrecy alone is not sufficient authentication. - Apply source-IP allowlisting if EngageLab publishes stable and verifiable callback ranges. - Enforce HTTPS for callback transport. - Validate the request method, content type, maximum body size, and complete JSON schema. - Validate timestamps within a narrow acceptance window and reject stale events. - Track event or message identifiers to prevent replay and duplicate processing. - Apply rate limits and request-volume monitoring. - Treat all callback fields as untrusted input. - Require secondary verification before callbacks trigger sensitive actions such as order fulfillment, account changes, or financial operations. - Minimize retention and logging of phone numbers, message content, and account identifiers. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (10)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The code substantially matches the declared messaging and template-management capabilities: it authenticates, constructs requests, handles errors, sends all listed message types, and performs template CRUD/list/get operations against EngageLab WhatsApp endpoints. However, the description also claims callback webhook handling and callback configuration, which are not present in this code chunk. There are no webhook server routes, handlers, signature validation, callback registration methods, or related logic. Therefore the description overstates the implemented capabilities in a material way, producing a description-behavior mismatch.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
**Update** — `PUT /v1/templates/:templateId` (same body as create)

**Delete** — `DELETE /v1/templates/:templateName` (deletes all languages for that name)

### Template Categories
Confidence
93% confidence
Finding
The documented delete operation targets a template name and states that it deletes all languages for that name, which creates a high-risk destructive action from a potentially ambiguous user input. In an agent setting, this can lead to bulk deletion of multiple templates when the user may have intended to remove only one localized variant or review the target first.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
## 5. Delete Template

`DELETE /v1/templates/:templateName`

Pass the **template name** (not ID) in the URL path. This deletes all language variants of that template.
Confidence
91% confidence
Finding
Using a destructive DELETE operation keyed only by `templateName` creates a parameter-abuse risk because a simple, human-guessable identifier can trigger deletion of multiple resources at once. In this skill, an LLM-driven agent may select or transform names incorrectly, causing overbroad or unauthorized destructive actions against WhatsApp business templates.

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill documents network-capable behavior against an external API but does not declare any explicit tool scope or allowed-tools constraints. In an agent environment, that omission weakens policy enforcement and can allow unintended outbound requests or broader tool access than users expect.

Vague Triggers

Medium
Confidence
93% confidence
Finding
The trigger phrases are broad enough to activate on generic 'WhatsApp' or 'WhatsApp API' requests, which can cause the wrong skill to be selected and prompt unnecessary use of external messaging functionality. Misrouting in this context is risky because the skill deals with credentials, recipient phone numbers, and outbound communications to a third-party service.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The skill lacks an explicit warning that recipient identifiers, message bodies, media links, and possibly template data will be transmitted to an external provider. Without that disclosure, users may unknowingly expose sensitive personal or business data to a third-party API and webhook flow.

Missing User Warnings

Medium
Confidence
99% confidence
Finding
The documentation explicitly instructs users to expose a webhook endpoint that does not require authentication because the callback security mechanism is 'pending'. That creates a true vulnerability: any internet client could forge callback requests, inject fake delivery or reply events, trigger business logic, pollute audit trails, or abuse downstream automation that trusts webhook contents.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation states that deleting by template name removes all language variants, but it does not prominently warn users about this broad destructive effect or require a safer confirmation pattern. In an agent skill context, this can lead to unintended bulk deletion if the agent or user assumes only a single localized template will be removed.

Missing User Warnings

Medium
Confidence
83% confidence
Finding
The constructor accepts a developer key and secret, encodes them into a Basic Authorization header, and uses them for all outbound API calls. Although this is functionally expected for an API client, the file does not include any warning or disclosure about handling sensitive credentials or sending them to a remote service.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
This code sends payloads containing recipient numbers, message bodies, and template data to an external WhatsApp API via HTTP requests. While the module docstring describes API usage, there is no runtime confirmation, logging, or explicit warning that user-provided data will be transmitted off-system.

Static analysis

No suspicious patterns detected.