Back to skill

Security audit

RollingGo Hotel Search

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent hotel-search helper, but it ships a shared API key and directs agents to run always-latest third-party packages, which users should review before installing.

Install only if you are comfortable with a third-party hotel CLI receiving your travel-search details and with the current documentation's shared API key model. Prefer using your own API key, avoid passing secrets on command lines or storing them in Markdown config, and pin RollingGo to a reviewed version in an isolated environment instead of following the always-latest or global upgrade instructions.

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

Error
Location
SKILL.md:70
Finding
Automatic Execution of Unpinned Third-Party Package Releases<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:70-81` **Additional Locations**: `references/env.md:52-53`; `references/rollinggo-npx.md:21-30, 52-62, 189-193`; `references/rollinggo-uv.md:19-36, 42-52, 141-146` **Vulnerability Type**: Supply-chain risk caused by mutable dependency versions and automatic upgrades **Risk Level**: High ### Vulnerable Code ```markdown ## Version Freshness (Always Latest) Default policy for this skill: use the newest release on every run. - **npm/npx:** `npx --yes --package rollinggo@latest rollinggo ...` - **uvx:** `uvx --refresh --from rollinggo rollinggo ...` If using an installed command instead of temporary execution, upgrade first: - **npm global:** `npm install -g rollinggo@latest` - **uv tool:** `uv tool upgrade rollinggo` ``` The same unsafe pattern appears in the runtime references: ```bash npx --yes --package rollinggo@latest rollinggo --help npm install -g rollinggo@latest uvx --refresh --from rollinggo rollinggo <subcommand> ... uv tool upgrade rollinggo ``` ### Technical Analysis The Skill deliberately retrieves the newest available `rollinggo` release whenever it runs or upgrades an installed copy before use. The `@latest` npm selector and the `uvx --refresh` behavior resolve to mutable external artifacts whose contents can change after this Skill has been reviewed. The project does not provide an exact reviewed version, integrity hash, lockfile, signed artifact verification procedure, or publisher identity validation. The `npx --yes` option also suppresses the normal installation confirmation. Consequently, the code eventually executed is not limited to the code represented by this audited project. Package installation and invocation can execute package CLI code and, depending on package-manager behavior, installation lifecycle code. The documented global installation path expands the affected scope by modifying the user's global tool environment. The external package implementation is ...[truncated 1824 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `rollinggo@latest` and unconstrained Python package references with an exact, reviewed version. 2. Pin and verify artifact integrity using npm lockfiles and integrity metadata or equivalent Python lockfiles and package hashes. 3. Remove the policy requiring automatic upgrades before every execution. 4. Do not use `uvx --refresh` during normal operation unless the newly resolved artifact is separately reviewed and verified. 5. Remove `--yes` from installation workflows where interactive approval is appropriate. 6. Avoid global installation. Prefer an isolated, non-privileged environment dedicated to this Skill. 7. Verify package ownership, registry source, signatures or provenance attestations, and expected package contents before approving a new version. 8. Run the CLI with a minimal environment, restricted filesystem access, no unnecessary credentials, and network access limited to required service endpoints. 9. Establish a controlled update process in which new versions are reviewed, tested, pinned, and promoted only after approval. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:48
Finding
Hard-Coded Shared API Credential Exposed in Project Documentation and Commands<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:48-55` **Additional Locations**: `SKILL.md:83-98`; `references/env.md:5-25, 36-53`; `references/rollinggo-npx.md:68-83, 152-175, 189-193`; `references/rollinggo-uv.md:58-73, 120-124, 141-145` **Vulnerability Type**: Hard-coded plaintext API credential **Risk Level**: Medium ### Vulnerable Code ```markdown ## API Key **Pre-configured Public API Key:** ```bash AIGOHOTEL_API_KEY=mcp_171e1ffa7da343faa4ec43460c52b13f ``` ``` The environment reference also recommends exposing the credential directly in command-line arguments and persistent Markdown configuration: ```bash rollinggo search-hotels \ --api-key mcp_171e1ffa7da343faa4ec43460c52b13f \ --origin-query "..." \ --place "..." \ --place-type "..." ``` ```markdown # In your TOOLS.md ## RollingGo Hotel Skill - **API Key**: `AIGOHOTEL_API_KEY=mcp_171e1ffa7da343faa4ec43460c52b13f` ``` ### Technical Analysis A reusable API credential is embedded directly in tracked project files and repeated throughout the operational documentation. Anyone who can obtain the Skill can extract and reuse it without authorization from the credential owner. Describing the value as a “public API Key” does not eliminate the security consequences of embedding a functional credential. Shared credentials prevent reliable attribution between users and expose the associated service account or quota to abuse. They also make targeted revocation difficult because revocation affects all legitimate users relying on the same value. The documented `--api-key` form creates an additional exposure channel: command-line arguments may be retained in shell history, process-monitoring data, audit logs, terminal transcripts, or Agent execution logs. The recommendation to store the key in `TOOLS.md` places plaintext credential material in another persistent file. ### Attack Path 1. An attacker downloads the project, reads a published copy, accesses a log containing the documen ...[truncated 1286 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Revoke or rotate the exposed credential and investigate its historical usage. 2. Remove the credential value from all project files, examples, generated documentation, and repository history where feasible. 3. Require each user or deployment to obtain an individual API key with the minimum necessary service permissions. 4. Load credentials at runtime from an approved secret manager or protected environment variable supplied outside the Skill package. 5. Do not pass credentials through command-line arguments, because they can be exposed through process listings, shell history, and execution logs. 6. Do not recommend storing plaintext secrets in `TOOLS.md` or other Markdown configuration files. 7. Redact credential values from Agent output, debugging information, telemetry, and error messages. 8. Apply per-key quotas, rate limits, expiration, rotation, monitoring, and revocation controls. 9. Update examples to use placeholders such as `AIGOHOTEL_API_KEY=<your-api-key>` rather than a working credential. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (27)

Missing User Warnings

High
Confidence
97% confidence
Finding
Publishing a usable API key in the skill without any warning about credential sensitivity or usage boundaries is a serious security and operational weakness. It can enable unauthorized reuse, quota exhaustion, service abuse, and downstream compromise if users assume embedding secrets in skill docs is acceptable practice.

Missing User Warnings

High
Confidence
99% confidence
Finding
Publishing a real API key in markdown and instructing direct use is a severe secret-handling failure. In context, a travel/hotel skill does not need to expose shared credentials to end users, so the mismatch makes this more dangerous by enabling unauthorized API use, abuse, billing exposure, and downstream privacy issues.

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
The file embeds and promotes use of a hard-coded API key in plaintext, including copy-paste export commands and direct CLI usage. Exposing a credential in reference documentation enables unauthorized use, quota theft, billing abuse, and makes secret rotation difficult; in a skill context it also normalizes unsafe credential handling for downstream users and agents.

Missing User Warnings

High
Confidence
98% confidence
Finding
The markdown not only exposes an API key but presents it without any warning about secrecy, least privilege, or privacy implications. That increases the likelihood of uncontrolled reuse and leakage, and in an agent skill ecosystem it can propagate bad practices into automated workflows and logs.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The skill sends user travel data such as destination, dates, occupancy, and search queries to an external hotel service but does not clearly disclose that this information leaves the local system. While this is consistent with the tool's purpose, the omission weakens informed consent and may create privacy/compliance issues for sensitive itineraries or corporate travel data.

Context-Inappropriate Capability

Medium
Confidence
98% confidence
Finding
The documentation embeds and directs use of a hardcoded API key, effectively distributing a credential inside the skill. Even if intended as a public/shared key, this encourages unsafe credential handling, makes abuse attribution impossible, and may grant unauthorized access or quota consumption against the external service.

Intent-Code Divergence

Medium
Confidence
92% confidence
Finding
The documentation claims credentials are resolved from flag or environment variable, but surrounding instructions normalize use of a fixed embedded key. This inconsistency can mislead operators into trusting that normal secret-management practices are being used when the workflow actually substitutes a shared hardcoded credential.

Rp1

Medium
Category
MCP Rug Pull
Confidence
91% confidence
Finding
The skill explicitly instructs use of `rollinggo@latest` via `npx`, which pulls and executes whatever the newest package version is at runtime. This creates a supply-chain risk: a compromised publisher account, malicious release, or breaking update could cause arbitrary code execution in the user's environment without review.

Rp1

Medium
Category
MCP Rug Pull
Confidence
90% confidence
Finding
`uvx --refresh --from rollinggo rollinggo ...` likewise fetches the latest available package at execution time, increasing exposure to malicious or unreviewed upstream changes. Because this is an execution path for a CLI tool, a bad release could immediately run attacker-controlled code locally and access environment variables such as API keys.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The primary workflow tells the operator to export a specific API key, overriding the manifest's expectation that the environment should supply the required secret. This directly operationalizes insecure secret distribution and increases the chance that the shared credential is copied into shells, logs, transcripts, or automation.

Missing User Warnings

Medium
Confidence
98% confidence
Finding
The file embeds a real-looking API key directly in documentation and instructs users to export it as an environment variable or pass it on the command line, but does not warn that CLI flags may be exposed in shell history, process listings, logs, screenshots, or shared config files. Even if described as a 'public' key, normalizing hardcoded credential distribution increases the chance of misuse, quota theft, service abuse, and accidental reuse in more sensitive contexts.

Rp1

Medium
Category
MCP Rug Pull
Confidence
93% confidence
Finding
The documentation tells users to execute a package from npm using `npx ... rollinggo@latest`, which pulls and runs the newest published code at execution time rather than a reviewed, fixed version. If the package is compromised, hijacked, or updated with unsafe behavior, users of the skill could execute attacker-controlled code on their machine or in an agent runtime.

Rp1

Medium
Category
MCP Rug Pull
Confidence
70% confidence
Finding
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Rp1

Medium
Category
MCP Rug Pull
Confidence
98% confidence
Finding
The documentation instructs users to run `npx --yes --package rollinggo@latest ...`, which fetches and executes the newest remote npm release at runtime. Using `@latest` creates a supply-chain risk because any compromised or malicious future publish would be executed immediately without review or pinning.

Context-Inappropriate Capability

Medium
Confidence
96% confidence
Finding
The file instructs runtime installation and execution of a remote npm package, which introduces code-fetch and execution capability not bounded by the static skill content. In this hotel-search skill, that is especially risky because the skill's apparent narrow purpose can mask broad code execution inherited from the npm package and any of its dependencies.

Rp1

Medium
Category
MCP Rug Pull
Confidence
98% confidence
Finding
This command again directs runtime execution of `rollinggo@latest` via npx, pulling fresh code from npm on each invocation. In a skill context, that means behavior can change outside the reviewed repository, increasing supply-chain and remote code execution exposure.

Rp1

Medium
Category
MCP Rug Pull
Confidence
84% confidence
Finding
This finding appears to refer to the 'Version Freshness' guidance that recommends always using the latest npm release. Even though the matched text is imprecise, the surrounding content promotes unpinned remote package execution, which is a real supply-chain risk.

Rp1

Medium
Category
MCP Rug Pull
Confidence
97% confidence
Finding
The reference states that the latest-by-default prefix is `npx --yes --package rollinggo@latest rollinggo`, again normalizing unpinned code execution. This is dangerous because a later npm publish could alter behavior or execute malicious code under the user's privileges.

Context-Inappropriate Capability

Medium
Confidence
99% confidence
Finding
The documentation embeds a hardcoded API key and tells users to export or pass it on the command line. This exposes credentials in plaintext, encourages leakage into shell history/process lists/logs, and suggests insecure credential distribution practices.

Rp1

Medium
Category
MCP Rug Pull
Confidence
70% confidence
Finding
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Rp1

Medium
Category
MCP Rug Pull
Confidence
88% confidence
Finding
The troubleshooting section recommends `npx --yes --package rollinggo@latest rollinggo ...`, which again encourages fetching and executing the newest remote package in order to resolve issues. Troubleshooting paths are frequently copied verbatim, so this repetition materially increases exposure to supply-chain compromise.

Rp1

Medium
Category
MCP Rug Pull
Confidence
70% confidence
Finding
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Rp1

Medium
Category
MCP Rug Pull
Confidence
91% confidence
Finding
The documentation instructs users to execute the `rollinggo` package via `uvx --from rollinggo` without pinning a specific version. That creates a supply-chain risk: future compromised or malicious releases would be fetched and executed automatically, and this file explicitly recommends latest-by-default behavior, which increases exposure.

Rp1

Medium
Category
MCP Rug Pull
Confidence
91% confidence
Finding
This command again uses `uvx --from rollinggo` without a pinned version, so running it may fetch and execute whatever release is current at invocation time. In an agent skill context, that means behavior can change silently and a compromised upstream package could lead to arbitrary code execution.

Rp1

Medium
Category
MCP Rug Pull
Confidence
97% confidence
Finding
`uvx --refresh --from rollinggo` is especially risky because it forces retrieval of the latest release on every execution. That maximizes supply-chain exposure by ensuring no previously vetted version is reused, so any malicious or broken upstream update is immediately executed.

Static analysis

No suspicious patterns detected.