Debug Checklist - Evomap Asset

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

Overview

This is a small C/C++ debugging checklist skill with no hidden persistence, network access, credential use, or privileged behavior, though its bundled header has code-quality risks users should treat cautiously.

Install only if you want a lightweight C/C++ checklist or learning aid. Do not rely on its printed pass/fail messages as a security guarantee, and review or harden checklist.h before compiling it into production or attacker-facing code.

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

T09 · Insecure Skill Coding Practices

Warning

• Location: checklist.h:36
• Finding: Unchecked String Pointers Cause Undefined Behavior<![CDATA[ ## Vulnerability Details **File Location**: `checklist.h`, lines 36-66 and 86-95 **Vulnerability Type**: Unchecked pointer use in formatted output **Risk Level**: Medium ### Vulnerable Code ```c void check_null_pointer(void* ptr, const char* var_name) { printf("[check] Null pointer: %s\n", var_name); if (ptr == NULL) { printf("[warning] Null pointer\n"); printf("[remediation] Add a NULL check\n"); printf("if (%s != NULL) { ... }\n", var_name); } else { printf("[pass]\n"); } } void check_memory_leak(const char* alloc_func, const char* free_func) { printf("[check] Memory leak\n"); printf("Allocation function: %s\n", alloc_func); printf("Release function: %s\n", free_func); if (free_func == NULL || strlen(free_func) == 0) { printf("[warning] No corresponding release function found\n"); } else { printf("[pass]\n"); } } void check_race_condition(const char* shared_resource) { printf("[check] Race condition: %s\n", shared_resource); /* Additional checklist output omitted because it does not affect the flaw. */ } void check_uninitialized(const char* var_name, const char* init_value) { printf("[check] Uninitialized variable: %s\n", var_name); if (init_value == NULL) { printf("[warning] Variable is uninitialized\n"); printf("%s = 0; or %s = NULL;\n", var_name, var_name); } else { printf("[pass] %s = %s\n", var_name, init_value); } } ``` The displayed message text is translated into English, while the pointer handling and control flow reproduce the audited implementation. ### Technical Analysis The public functions accept string pointers from callers and pass them directly to the `%s` conversion of `printf` without first confirming that the pointers are non-null and reference valid, null-terminated strings. In `check_memory_leak`, `free_func` is checked for `NULL` only after it has already been passed to `printf`. The ...[truncated 2155 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Validate every string pointer before its first use. - Substitute a fixed safe label when an optional argument is null. - Define whether each parameter is mandatory or optional in the API contract. - Require valid, null-terminated strings with lifetimes covering the entire function call. - Where string lengths are known, use bounded output such as `printf("%.*s", length, value)` after validating the pointer and length. - Add unit tests covering null, empty, unterminated, and invalid-lifetime inputs. - Compile and test with AddressSanitizer and UndefinedBehaviorSanitizer. A basic null-safe pattern is: ```c static const char *safe_string(const char *value) { return value != NULL ? value : "(null)"; } void check_memory_leak(const char *alloc_func, const char *free_func) { printf("Allocation function: %s\n", safe_string(alloc_func)); printf("Release function: %s\n", safe_string(free_func)); if (free_func == NULL || free_func[0] == '\0') { printf("No corresponding release function was supplied.\n"); } } ``` Null checks do not make arbitrary dangling or unterminated pointers safe. Callers must still satisfy a documented ownership and validity contract. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: checklist.h:72
• Finding: Incomplete Range Validation Produces False Safety Results<![CDATA[ ## Vulnerability Details **File Location**: `checklist.h`, lines 72-82 **Vulnerability Type**: Incomplete array-boundary validation **Risk Level**: Low ### Vulnerable Code ```c void check_off_by_one(int loop_start, int loop_end, int array_size) { printf("[check] Off-by-one error\n"); printf("Loop range: [%d, %d)\n", loop_start, loop_end); printf("Array size: %d\n", array_size); if (loop_end > array_size) { printf("[warning] Loop may exceed the array boundary\n"); printf("[remediation] Ensure loop_end <= array_size\n"); } else { printf("[pass]\n"); } } ``` The displayed message text is translated into English, while the validation condition and control flow reproduce the audited implementation. ### Technical Analysis The function reports that a range passes whenever `loop_end` is not greater than `array_size`. That single comparison is insufficient to establish that the half-open range `[loop_start, loop_end)` is valid. It does not reject: - A negative `loop_start`, such as `(-1, 10, 10)`. - A negative `loop_end` or `array_size`. - A start position greater than the end position. - A start position greater than the array size. - Integer values whose signed representation is incompatible with the caller's actual array-size type. Consequently, invalid ranges can receive a positive result. For example, both `check_off_by_one(-1, 10, 10)` and `check_off_by_one(20, 10, 10)` print the passing branch even though they do not describe safe array traversals. The helper does not itself access an array, so it does not directly perform an out-of-bounds read or write. The risk arises because its result can mislead code reviewers or developers into treating unsafe indexing logic as valid. ### Attack Path 1. A developer uses `check_off_by_one` to assess a loop range before or during debugging. 2. An invalid range is supplied where `loop_end <= array_size`, but another necessary invariant is false. 3. The helper ...[truncated 999 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Validate all invariants required for a half-open array range: ```c bool check_off_by_one(size_t loop_start, size_t loop_end, size_t array_size) { if (loop_start > loop_end) { printf("Invalid range: start exceeds end.\n"); return false; } if (loop_end > array_size) { printf("Invalid range: end exceeds array size.\n"); return false; } printf("Range is within the supplied array bounds.\n"); return true; } ``` Additional hardening should include: - Prefer `size_t` for array sizes and indexes when negative values are never valid. - If signed inputs must remain supported, explicitly reject values below zero before converting them to `size_t`. - Return a boolean or structured result rather than only printing a message, allowing callers to enforce failure handling. - Clearly document that validating numeric bounds does not prove that an underlying pointer references an allocation of the declared size. - Add tests for empty ranges, zero-sized arrays, negative signed inputs, reversed ranges, starts beyond the size, ends beyond the size, and maximum representable values. ]]>

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: This header's user-facing strings and comments are entirely in Chinese, including the title at L002 and runtime output beginning at L145. Because the file provides no language choice, opt-in, or documented region-specific constraint, it imposes a specific language/locale in a way that matches the policy's locale-constraint concern.

Vague Triggers

Low

• Confidence: 82% confidence
• Finding: This markdown file describes the skill's purpose and use cases, but it does not define any explicit invocation phrases, constraints, or negative examples. In a skill catalog, such broad descriptions can overlap with many general debugging requests and lead to unintended activation.