Back to skill

Security audit

http-requests-1.0.0

Security checks for vulnerabilities and agentic risk

Overview

This is a real HTTP request helper, but it can contact arbitrary network targets and keeps full request URLs in local logs by default.

Install only if you are comfortable with the agent making outbound HTTP requests from its runtime environment. Avoid using it for internal services, metadata endpoints, signed URLs, production secrets, or credential-bearing query strings, and prefer --no-log when requests may include sensitive data.

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/request_http.py:66
Finding

Unrestricted URL Requests Permit Server-Side Request Forgery

Content
View full analysis

Vulnerability Details

File Location: scripts/request_http.py, lines 66 and 91–99
Vulnerability Type: Server-Side Request Forgery (SSRF)
Risk Level: High

Vulnerable Code

python
parser.add_argument("--url", required=True)
python
response = requests.request(
    method=args.method.upper(),
    url=args.url,
    headers=headers,
    params=params,
    json=json_body,
    data=data_body,
    timeout=args.timeout,
)

Technical Analysis

The script accepts an arbitrary URL and passes it directly to requests.request() without validating the URL scheme, destination hostname, resolved IP address, port, or redirect destination.

Python Requests follows HTTP redirects by default. Consequently, validating only the initial URL would not be sufficient: an attacker-controlled public endpoint could redirect the request to a loopback, private-network, or link-local address.

The vulnerable behavior can permit requests to destinations such as:

  • Loopback services accessible only from the execution environment
  • RFC 1918 private-network services
  • Link-local and cloud instance metadata services
  • Internal administrative interfaces
  • Services bound to otherwise inaccessible ports

The response status, final URL, and response body are printed to standard output, allowing information obtained through SSRF to be returned to the invoking agent or user.

Attack Path

  1. An attacker supplies or influences the --url argument used by the skill.
  2. The URL directly references an internal address, or references an attacker-controlled public server that redirects to an internal address.
  3. The script calls requests.request() without destination restrictions and follows redirects by default.
  4. The HTTP request is sent using the network privileges of the environment running the skill.
  5. The internal service's response body is printed to standard output.
  6. The attacker may ...[truncated 697 chars]
Remediation
View remediation

Remediation Suggestions

Implement centralized URL validation before every request:

  1. Allow only explicitly required schemes, normally https and, where necessary, http.
  2. Reject URLs containing embedded usernames or passwords.
  3. Resolve the hostname and reject every resolved loopback, private, link-local, multicast, unspecified, or reserved IP address.
  4. Consider an explicit hostname and port allowlist when the intended integrations are known.
  5. Disable redirects by default with allow_redirects=False, or validate the destination of every redirect before following it.
  6. Protect against DNS rebinding by connecting only to an address that has already been validated and by avoiding an unchecked second DNS resolution.
  7. Apply outbound firewall or proxy restrictions so the process cannot reach metadata services or sensitive internal networks.
  8. Require an explicit, prominently documented override for legitimate internal requests rather than permitting them by default.
  9. Add tests covering IPv4, IPv6, alternative IP representations, DNS aliases, embedded credentials, and redirect chains.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/request_http.py:34
Finding

Sensitive URL Values Are Persisted in Plaintext Logs

Content
View full analysis

Vulnerability Details

File Location: scripts/request_http.py, lines 34–51 and 135–136
Vulnerability Type: Sensitive Information Exposure Through Logging
Risk Level: Medium

Vulnerable Code

python
def build_log_record(args, response=None, error=None, duration_ms=0):
    record = {
        "ts": datetime.now().astimezone().isoformat(timespec="seconds"),
        "method": args.method.upper(),
        "url": args.url,
        "status": response.status_code if response is not None else None,
        "ok": bool(response is not None and response.ok),
        "duration_ms": round(duration_ms, 2),
        "response_bytes": len(response.content) if response is not None else 0,
        "error": error,
    }
    return record


def write_log(record: dict):
    LOG_DIR.mkdir(parents=True, exist_ok=True)
    log_file = LOG_DIR / f"{datetime.now().date().isoformat()}.jsonl"
    with log_file.open("a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
python
if not args.no_log:
    write_log(build_log_record(args, response=response, error=error, duration_ms=duration_ms))

Technical Analysis

The complete value of args.url is inserted into each log record and appended to logs/YYYY-MM-DD.jsonl. No sanitization is applied to URL user information, query parameter names, or query parameter values.

URLs commonly carry sensitive data such as:

  • API keys and access tokens
  • Signed request parameters
  • Session identifiers
  • Password-reset or account-verification codes
  • Webhook secrets
  • Credentials embedded in URL authority components

Although the script defines redact_headers(), that function does not sanitize URLs and is not involved in constructing these log records. Logging occurs by default unless --no-log is supplied. Request failures are also logged through the same record-building mechanism.

This behavior conflicts ...[truncated 1228 chars]

Remediation
View remediation

Remediation Suggestions

  1. Do not log complete URLs by default. Store only the scheme, hostname, port, and path when operationally necessary.
  2. Remove URL user information and query strings before constructing the log record.
  3. If selected query parameters must be retained, use an allowlist of known non-sensitive fields rather than a denylist.
  4. Redact values associated with names such as token, key, api_key, signature, password, secret, code, and session.
  5. Treat fragments as sensitive and omit them as well.
  6. Create log directories and files with restrictive permissions appropriate to the operating system.
  7. Define log retention, deletion, and backup policies to minimize the lifetime of sensitive metadata.
  8. Consider making logging opt-in instead of enabled by default.
  9. Update SKILL.md so its logging documentation accurately describes what is retained.
  10. Add tests verifying that query tokens, embedded credentials, signed URLs, and failure messages cannot be persisted unredacted.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (5)

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
92% confidence
Finding

The skill enables both network access and local file writes via its documented behavior and referenced script, but the manifest declares no explicit tool scope or permissions boundaries. In an agent environment, that increases the chance the skill is invoked with overly broad ambient authority, allowing unintended outbound requests, SSRF-style access to internal endpoints, or persistent logging of sensitive operational metadata.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The trigger phrases are very broad and map to common, everyday API-related requests, so the skill may activate in situations where the user did not explicitly intend a network-capable tool to run. Because this skill performs outbound HTTP requests and writes logs, overbroad activation raises the risk of unintended data egress, accidental calls to sensitive endpoints, or unsafe handling of secrets included in routine prompts.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

This markdown file includes HTTP usage examples that send an Authorization bearer token in headers, but the document does not warn users that request headers may contain sensitive credentials and will be transmitted over the network. Under the markdown-specific warning rule, examples affecting privacy or user data should include a disclosure when demonstrating credential-bearing requests.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The example POST form data includes a password field and demonstrates transmitting it to a remote endpoint, yet the markdown provides no warning about privacy, credential handling, or using non-production secrets. This omission is material because the documented behavior can affect user data and privacy.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The script persists request metadata to local JSONL logs even though its stated purpose is to send HTTP requests and display responses. In an agent context, requested URLs can contain secrets in query strings, internal hostnames, webhook endpoints, or other sensitive operational data, and this creates unnecessary retention of potentially sensitive request history on disk.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.