Wolfram Alpha

• Outcome: Pass
• Latest audit: Sep 10, 2026 · 9:06 PM UTC
• Version: 1.0.2

Overview

This Wolfram Alpha skill does what it claims, but users should know their query and Wolfram app ID are sent to Wolfram Alpha.

Install only if you are comfortable sending Wolfram queries, including any sensitive input you type, to Wolfram|Alpha. Treat WOLFRAM_APP_ID as a credential: avoid verbose URL logging, redact appid values in diagnostics, monitor quota use, and rotate the app ID if it may have appeared in logs.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: wolfram_query.py:11
• Finding: API Credential Exposed in URL Query Parameters## Vulnerability Details **File Location**: `wolfram_query.py`, lines 11–15 **Vulnerability Type**: API credential exposure through URL query parameters **Risk Level**: Medium ```python url = "https://www.wolframalpha.com/api/v1/llm-api" params = { "input": query, "appid": app_id } ``` The vulnerable data flow is completed by the request at line 18: ```python response = requests.get(url, params=params) ``` ### Technical Analysis The script reads `WOLFRAM_APP_ID` from the process environment and passes it as the `appid` parameter of an HTTP GET request. The `requests` library serializes this parameter into the URL query string. Although HTTPS encrypts the URL while it is in transit, full URLs can still be captured by client-side debugging facilities, HTTP proxies, gateways, observability platforms, exception telemetry, or other systems that record outbound request URLs. Consequently, infrastructure operators or attackers with access to such records may be able to recover the API credential. The credential is not hardcoded in the repository, and the examined code does not deliberately transmit it to an unrelated endpoint. The exposure risk arises from placing sensitive authentication material in a URL rather than a less commonly logged authorization channel. ### Attack Path 1. A user configures a valid `WOLFRAM_APP_ID` and invokes `wolfram_query.py`. 2. The script constructs a GET URL containing the credential as the `appid` query parameter. 3. A local diagnostic facility, outbound proxy, gateway, monitoring platform, or error-reporting system records the complete request URL. 4. An attacker or unauthorized operator gains read access to those records. 5. The attacker extracts the `appid` value and reuses it in requests to the Wolfram|Alpha API. 6. The stolen credential may remain usable until it is revoked, rotated, or otherwise restricted. ### Impact Assessment Successful exploitation would ...[truncated 536 chars]
• Remediation: ## Remediation Suggestions 1. Prefer an API-supported authorization header or POST body so the credential is not included in the URL. 2. If the Wolfram|Alpha API requires `appid` as a query parameter, treat that exposure as an API constraint and configure clients, proxies, gateways, telemetry systems, and exception handlers to redact the `appid` parameter. 3. Disable verbose HTTP request logging in production and verify that monitoring platforms do not retain full query strings. 4. Restrict the credential's permissions and usage where supported, apply quota and anomaly monitoring, and rotate it periodically. 5. Revoke and replace the credential immediately if URLs containing it may already have been recorded in systems accessible to unauthorized parties. 6. Document that request URLs contain sensitive authentication material so operators do not copy them into tickets, chat messages, logs, or public diagnostics.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Tainted flow: 'params' from os.getenv (line 13, credential/environment) → requests.get (network output)

Critical

• Category: Data Flow

Content

}

    try:
        response = requests.get(url, params=params)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: The skill requires access to environment variables and makes networked API calls, but it does not declare an explicit tool scope such as permissions or allowed-tools. That mismatch can cause the runtime or agent to grant broader capabilities than reviewers expect, increasing the chance of unauthorized network use or unintended exposure of the WOLFRAM_APP_ID secret.

Missing User Warnings

Low

• Confidence: 88% confidence
• Finding: The script transmits the full user query to a third-party service without any in-code notice, consent prompt, or minimization. In a skill context, users may enter sensitive mathematical, scientific, or data-analysis inputs, so undisclosed external transmission can create a privacy and data-handling risk even though the destination is the intended Wolfram Alpha service.

Static analysis

No suspicious patterns detected.