ClawHub
Back to skill

Security audit

Cpp Pro

Security checks for vulnerabilities and agentic risk

Overview

This is a C++ guidance skill with no executable payload; some example templates should be hardened before copying into real projects.

Reasonable to install for C++ assistance. Before accepting generated build files or concurrency code, ask the agent to pin dependency versions or action SHAs, use lockfiles where possible, and avoid production lock-free memory reclamation examples unless they use a reviewed safe strategy.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
references/build-tooling.md:47
Finding
Build and CI Templates Use Unpinned Executable Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `references/build-tooling.md`, lines 47-51 and 377-415 **Vulnerability Type**: Supply-chain exposure through mutable or unversioned dependencies **Risk Level**: Medium ### Vulnerable Code ```cmake FetchContent_Declare( fmt GIT_REPOSITORY https://github.com/fmtlib/fmt.git GIT_TAG 10.1.1 ) ``` ```yaml steps: - uses: actions/checkout@v3 - name: Install dependencies run: | pip install conan conan install . --output-folder=build --build=missing ``` The same mutable `actions/checkout@v3` reference also appears in the sanitizer and static-analysis jobs. ### Technical Analysis The documented build and CI templates retrieve and execute third-party components without cryptographically fixing their contents: - `pip install conan` does not specify an exact package version or verify an artifact hash. - `actions/checkout@v3` is a mutable major-version reference rather than an immutable commit SHA. - `GIT_TAG 10.1.1` identifies a Git tag rather than a full immutable commit SHA. Package installation, GitHub Actions, and CMake `FetchContent` dependencies can execute code in developer or CI environments. If an upstream account, package, release tag, or distribution channel is compromised, the retrieved payload can differ from the content originally reviewed. No evidence indicates that the named dependencies are currently malicious. The vulnerability is the absence of immutable and verifiable dependency resolution in templates likely to be copied into real projects. ### Attack Path 1. A developer adopts the documented CMake or GitHub Actions template. 2. A build or CI job resolves the package, action tag, or Git tag at execution time. 3. An attacker compromises the relevant upstream account or distribution channel, or causes a mutable reference to resolve to altered content. 4. The build system downloads the altered component. ...[truncated 774 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin Python dependencies to reviewed, exact versions and install them with verified hashes, preferably through a locked requirements file. - Pin GitHub Actions to full commit SHAs. Use automated dependency tooling to submit reviewed SHA updates. - Pin `FetchContent` Git dependencies to full commit SHAs rather than mutable tags. - Generate and enforce dependency lockfiles where supported. - Restrict CI token permissions with an explicit least-privilege `permissions` block. - Avoid exposing secrets to jobs that download or execute unnecessary third-party components. - Add dependency review, provenance verification, and artifact integrity checks to CI. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/concurrency.md:55
Finding
Lock-Free Stack Example Permits Use-After-Free and ABA Corruption<![CDATA[ ## Vulnerability Details **File Location**: `references/concurrency.md`, lines 55-84 **Vulnerability Type**: Unsafe concurrent memory reclamation **Risk Level**: Medium ### Vulnerable Code ```cpp template<typename T> class LockFreeStack { struct Node { T data; Node* next; Node(const T& value) : data(value), next(nullptr) {} }; std::atomic<Node*> head_{nullptr}; public: void push(const T& value) { Node* new_node = new Node(value); new_node->next = head_.load(std::memory_order_relaxed); while (!head_.compare_exchange_weak(new_node->next, new_node, std::memory_order_release, std::memory_order_relaxed)) { // Retry with updated head } } bool pop(T& result) { Node* old_head = head_.load(std::memory_order_relaxed); while (old_head && !head_.compare_exchange_weak(old_head, old_head->next, std::memory_order_acquire, std::memory_order_relaxed)) { // Retry } if (old_head) { result = old_head->data; delete old_head; // Note: ABA problem exists return true; } return false; } }; ``` ### Technical Analysis The stack immediately dereferences and deletes a removed node without a safe concurrent reclamation mechanism such as hazard pointers, epoch-based reclamation, reference counting, or quiescent-state tracking. One consumer can retain `old_head` while another consumer successfully removes and deletes that same node. The first consumer may then evaluate `old_head->next` or access `old_head->data` after the allocation has been freed, producing a use-after-free. The implementation is also vulnerab ...[truncated 1628 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace the example with a proven, maintained concurrent container whenever possible. - If a custom lock-free stack is required, implement a formally reviewed reclamation strategy such as hazard pointers or epoch-based reclamation. - Protect against ABA with tagged or versioned pointers where platform support and alignment constraints permit. - Do not reclaim a node until no concurrent reader can retain a reference to it. - Add stress tests under AddressSanitizer and ThreadSanitizer, while recognizing that sanitizer success does not prove a lock-free algorithm correct. - Document memory-ordering and reclamation invariants explicitly and obtain specialist review. - If retaining the current snippet for teaching purposes, mark it prominently as intentionally incomplete, unsafe, and unsuitable for production use. ]]>

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.