HTTP Retry - Evomap Asset

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:50 AM UTC
• Version: 1.0.0

Overview

This skill is a small HTTP retry helper, but its shipped C code can report successful HTTP requests without actually sending them.

Review this skill carefully before installing or reusing its code. It does not appear to steal data or persist on the system, but the HTTP helper is unsafe as a real library because it can make callers believe requests succeeded when no request occurred. Treat it as demo or placeholder code unless the transport callback, POST handling, input validation, and retry safety controls are fixed.

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 (3)

T09 · Insecure Skill Coding Practices

Error

• Location: http_retry.h:96
• Finding: HTTP API Fabricates Successful Responses Without Performing Requests## Vulnerability Details **File Location**: `http_retry.h:96-101` **Vulnerability Type**: Fabricated network response and fail-open behavior **Risk Level**: High ```c // Execute request (placeholder - integrate with actual HTTP library) // HttpErrorCode error = config->request_func(url, config->user_context); // For demo purposes, simulate success HttpErrorCode error = HTTP_SUCCESS; response.status_code = 200; ``` ### Technical Analysis The implementation does not execute an HTTP request. The call to the configured `request_func` is commented out, the URL is unused, and the function unconditionally sets the error state to `HTTP_SUCCESS` and the status code to `200`. This is a fail-open design: callers receive an authoritative-looking success response even when no remote operation occurred. It also makes the retry, timeout, connection-error, rate-limit, and server-error handling paths unreachable. The behavior directly contradicts the documented purpose of the API. ### Attack Path 1. An application uses `http_request_with_retry()` for an operation that must be confirmed by a remote service. 2. The operation could involve authorization validation, webhook delivery, audit-event submission, remote state synchronization, or another security-sensitive request. 3. No HTTP request is sent because the configured callback is never invoked. 4. The function returns `status_code == 200` and reports success after one attempt. 5. The caller trusts the fabricated response and proceeds as though the remote operation succeeded. This path does not directly grant operating-system privileges. Its security consequence is an integrity and control-flow failure in applications that rely on the result. ### Impact Assessment Affected callers can incorrectly commit local state, approve workflows, suppress retry or alert mechanisms, or record nonexistent remote transactions as successful. The scope i ...[truncated 483 chars]
• Remediation: ## Remediation Suggestions - Require a valid transport callback or integrate a real HTTP client implementation. - Invoke `config->request_func(url, config->user_context)` and propagate its actual result. - Return an explicit configuration or transport error when no request function is available; never default to success. - Populate `status_code`, response data, and error information only from the actual transport result. - Map real timeout, connection, rate-limit, and server errors to `HttpErrorCode`. - Enforce the configured timeout rather than merely storing `timeout_ms`. - Add tests proving that no callback, callback failure, timeout, HTTP 429, and HTTP 5xx responses cannot produce fabricated success. - Document ownership and lifetime rules for `response_body`.

T09 · Insecure Skill Coding Practices

Warning

• Location: http_retry.h:135
• Finding: POST Wrapper Discards the Request Body and Returns Fabricated Success## Vulnerability Details **File Location**: `http_retry.h:135-139` **Vulnerability Type**: Silent request-data loss and incorrect HTTP method handling **Risk Level**: Medium ```c // POST with retry HttpResponse http_post_retry(const char* url, const char* data) { // Similar to GET, but with POST method return http_get_retry(url); // Placeholder } ``` ### Technical Analysis The `http_post_retry()` function ignores its `data` argument and delegates directly to `http_get_retry()`. It therefore neither preserves the requested HTTP method nor transmits the supplied body. Because the delegated implementation also fabricates HTTP 200 responses, the caller receives an apparent success despite the POST operation never occurring. This violates the API contract and creates a fail-open condition for callers that use POST requests to submit state changes, credentials, signed messages, transactions, or security events. ### Attack Path 1. An application submits security-sensitive data through `http_post_retry()`. 2. The function silently discards the `data` argument. 3. It delegates to the GET wrapper rather than executing a POST request. 4. The underlying request function returns a simulated HTTP 200 response without network activity. 5. The application accepts the apparent success and may update local state, delete queued data, or suppress failure handling. If an attacker can influence when this API is used or the submitted data, the attacker may exploit the mismatch to cause silent loss of security events or failed remote state changes. No direct system privilege is obtained through this function alone. ### Impact Assessment Potential consequences include lost API commands, undelivered audit records, failed credential or token exchanges, missing transaction submissions, and divergence between local and remote state. The affected scope is all POST operations implemented through this wrapper. The vulnerability pr ...[truncated 203 chars]
• Remediation: ## Remediation Suggestions - Implement a method-aware transport API that distinguishes GET, POST, and other HTTP methods. - Pass the POST body and an explicit body length to the transport layer. - Validate `url`, `data`, and configuration pointers before use. - Return an explicit unsupported-operation error until POST behavior is fully implemented. - Preserve and expose actual transport failures instead of returning simulated success. - Define content type, encoding, maximum body size, and response ownership semantics. - Add tests confirming that the exact request body reaches the transport callback and that failures propagate to the caller. - Ensure retries for non-idempotent POST operations are opt-in or protected with idempotency keys to prevent duplicate side effects.

T09 · Insecure Skill Coding Practices

Warning

• Location: http_retry.h:56
• Finding: Unchecked Backoff Arithmetic Can Trigger Undefined Behavior or Process Crashes## Vulnerability Details **File Location**: `http_retry.h:56-62` **Vulnerability Type**: Integer overflow, invalid bit shift, and modulo by zero **Risk Level**: Medium ```c // Calculate exponential backoff delay with jitter int calculate_backoff_delay(int attempt, int base_delay_ms, int max_delay_ms) { int exponential_delay = base_delay_ms * (1 << attempt); // 2^attempt int jitter = rand() % (exponential_delay / 2); int delay = exponential_delay + jitter; return (delay > max_delay_ms) ? max_delay_ms : delay; } ``` ### Technical Analysis All inputs to the public backoff function are signed integers and are used without validation. Several undefined or invalid arithmetic conditions are possible: - A negative `attempt` or an `attempt` greater than or equal to the width of `int` causes an invalid shift. - `1 << attempt` can overflow a signed integer. - Multiplication by `base_delay_ms` can overflow. - When `exponential_delay / 2` is zero, `rand() % 0` causes undefined behavior and commonly terminates the process. - Adding `jitter` to `exponential_delay` can overflow. - Negative configuration values can produce negative delays that later undergo unsafe conversion when passed to `usleep()`. C signed-overflow behavior is undefined, so compiler optimization may produce effects beyond simple wraparound. ### Attack Path 1. An application constructs retry configuration from untrusted or insufficiently validated input. 2. The attacker supplies a value such as `base_delay_ms = 0`, `base_delay_ms = 1`, a negative attempt, or an excessively large attempt or delay. 3. `calculate_backoff_delay()` performs an invalid shift, overflows signed arithmetic, or evaluates `rand() % 0`. 4. The process crashes, enters undefined behavior, or computes an invalid sleep duration. 5. Repeated requests can cause denial of service in an exposed service using the library. Exploitation requires attacker influence over ...[truncated 715 chars]
• Remediation: ## Remediation Suggestions - Reject negative attempts and non-positive base or maximum delays. - Establish strict upper bounds for attempts and delay values. - Use checked `uint64_t` arithmetic rather than signed `int` arithmetic. - Avoid shifting unless the shift count is verified to be less than the operand width. - Saturate the exponential delay at `max_delay_ms` before multiplication or addition can overflow. - Calculate jitter only when the jitter range is greater than zero. - Validate the final delay before converting it to the type expected by `usleep()`. - Prefer `nanosleep()` with validated `struct timespec` values for portable bounded delays. - Add boundary tests for zero, one, negative values, maximum integers, large attempt counts, and overflow thresholds.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (9)

External Transmission

Medium

• Category: Data Exfiltration

Content

.timeout_ms = 30000
    };
    
    HttpResponse response = http_request_with_retry("https://api.example.com/data", &config);
    
    if (response.status_code == 200) {
        printf("Success after %d attempts\n", response.attempt_count);

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

.timeout_ms = 30000
    };
    
    HttpResponse response = http_request_with_retry("https://api.example.com/data", &config);
    
    if (response.status_code == 200) {
        printf("Success after %d attempts\n", response.attempt_count);

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

.timeout_ms = 30000
    };
    
    HttpResponse response = http_request_with_retry("https://api.example.com/data", &config);
    
    if (response.status_code == 200) {
        printf("Success after %d attempts\n", response.attempt_count);

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Natural-Language Policy Violations

Medium

• Confidence: 91% confidence
• Finding: Natural-language policy checks apply to all file types. The manifest mixes English with Chinese user-facing descriptions and trigger phrases, but it does not state that the skill is region-specific or provide any user opt-in for language/locale, which can amount to forcing a specific language experience.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The trigger list includes broad terms such as generic network errors and API failure phrases in multiple languages, which can cause the skill to activate in unintended contexts. In an automated agent environment, overbroad activation can lead to unrequested code or configuration changes being proposed or applied, increasing operational risk even though the skill’s stated purpose is benign resilience improvement.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The documented POST helper does not perform a POST at all: it ignores the supplied body and simply calls the GET helper. This can cause callers to believe data was transmitted or a state-changing operation occurred when it did not, leading to logic flaws, failed security workflows, and accidental use of the wrong HTTP method in sensitive integrations.

Natural-Language Policy Violations

Low

• Confidence: 73% confidence
• Finding: The document consistently presents all headings and descriptions in both English and Chinese, suggesting a fixed locale/output convention. There is no statement that this is optional, user-selected, or required for a justified regional/compliance reason.

Missing User Warnings

Low

• Confidence: 85% confidence
• Finding: This markdown file describes an HTTP retry mechanism that automatically reissues API calls, which can resend user or system data over the network multiple times. The description explains the benefits but does not warn users about privacy, duplicate-request, or side-effect risks from automatic retries.

Natural-Language Policy Violations

Low

• Confidence: 85% confidence
• Finding: This file contains natural-language content in multiple languages, including Chinese in the title comment, but does not indicate that the user can choose language or that the skill is intended for a Chinese-speaking or region-specific audience. Under the language/locale policy, forcing or assuming a language without opt-in can be a policy concern.

Static analysis

No suspicious patterns detected.