Back to skill

Security audit

Bid Document Review (Lite)

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed bid-document review helper that reads user-selected documents and produces an AI-assisted report, with manageable dependency and accuracy cautions.

Install dependencies in a virtual environment, prefer pinned versions if possible, and use the generated report as an aid for human procurement review rather than a final compliance decision, especially for images, seals, certificates, or legacy .doc files where extraction may be incomplete.

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

T08 · Insecure Dependencies

Warning
Location
SKILL.md:136
Finding
Unpinned Third-Party Python Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:136-139`; also documented in `scripts/extract_text.py:7` and `scripts/extract_doc_text.py:7` **Vulnerability Type**: Supply-chain exposure through unpinned dependencies **Risk Level**: Medium ### Vulnerable Code `SKILL.md:136-139`: ```markdown ## Dependencies - Python 3.6+ - python-docx (`pip3 install python-docx`) - olefile (`pip3 install olefile`) — for .doc files only ``` `scripts/extract_text.py:7`: ```python Requires: pip3 install python-docx ``` `scripts/extract_doc_text.py:7`: ```python Requires: pip3 install olefile ``` ### Technical Analysis The installation instructions retrieve the latest package versions selected by the configured Python package index. No reviewed versions, integrity hashes, constraints file, or lock file are provided. Although `python-docx` and `olefile` are consistent with the scripts' declared functionality, installing mutable and unverified releases creates a supply-chain risk. Python package installation can execute package build or installation logic. Consequently, compromise of a package release, transitive dependency, package-index account, index configuration, or package resolution environment could result in arbitrary code execution during installation or when the dependency is imported. The audited project does not itself retrieve dependencies automatically, use an untrusted package index, or contain evidence that the named packages are malicious. Exploitation therefore depends on a compromise or manipulation of the external dependency supply chain. ### Attack Path 1. An attacker compromises a named package, one of its resolved dependencies, its publishing account, or the package index used by the victim. 2. The attacker publishes or causes resolution of a malicious release under the expected package name. 3. A user follows the documented unpinned command: - `pip3 install python-docx`, or - `pip3 install olefile`. 4. Pip resolves the attack ...[truncated 1010 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Create a dependency file containing explicitly reviewed versions of `python-docx`, `olefile`, and all required transitive dependencies. 2. Generate and verify cryptographic hashes for every approved distribution, then install with pip's `--require-hashes` option. 3. Replace the generic installation examples with a reproducible command such as: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 4. Maintain separate lock files when different operating systems or Python versions require different distributions. 5. Install dependencies inside a dedicated virtual environment rather than globally or with administrative privileges. 6. Use the official Python package index over TLS, explicitly control index configuration, and avoid untrusted additional indexes. 7. Review dependency updates before changing locked versions, including package ownership, release provenance, dependency changes, and published artifacts. 8. Add automated dependency and vulnerability scanning to the release process while retaining manual review for package changes. ]]>
Vulnerability Patterns
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
This finding indicates the skill claims support for both `.docx` and `.doc` plus AI review outputs, while the detected behavior only covers a subset and omits the actual analytical functions. In a procurement-review context, overstated capability is dangerous because it may create false assurance that a bid was fully audited when critical requirements were never evaluated.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
This finding indicates the skill claims support for both `.docx` and `.doc` plus AI review outputs, while the detected behavior only covers a subset and omits the actual analytical functions. In a procurement-review context, overstated capability is dangerous because it may create false assurance that a bid was fully audited when critical requirements were never evaluated.

Lp3

Medium
Category
MCP Least Privilege
Confidence
70% confidence
Finding
Without declared permissions the skill's intent is opaque and cannot be validated.

Static analysis

No suspicious patterns detected.