Back to skill

Security audit

RSS监控

Security checks for vulnerabilities and agentic risk

Overview

This RSS monitoring skill is coherent and purpose-aligned, but users should treat feed URLs and the Python dependency as normal network and supply-chain trust decisions.

Install the dependency in an isolated environment when practical, prefer a pinned feedparser version, and only add public RSS/Atom feed URLs you trust. Do not expose this sample directly as a public URL-fetching service without validation and network egress restrictions.

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
SKILL.md:3
Finding
Unpinned Third-Party Dependency Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 3 and 16 **Vulnerability Type**: Unpinned and unverifiable third-party dependency **Risk Level**: Medium ### Vulnerable Code ```yaml metadata: {"openclaw": {"requires": {"python": ["feedparser"]}, "install": []}} ``` ```bash pip install feedparser ``` ### Technical Analysis The skill declares and instructs users to install `feedparser` without a version constraint, lockfile, package hash, or explicit trusted package index. Consequently, the installed code is determined by mutable package-repository state at installation time rather than by the version reviewed during the audit. This is an insecure supply-chain practice. A compromised upstream release, package repository, or dependency could introduce code that executes during installation or when the module is imported. The absence of version pinning can also cause unexpected behavior due to incompatible future releases. There is no evidence that `feedparser` is currently malicious. The finding concerns the unsafe and non-reproducible installation mechanism. ### Attack Path 1. An attacker compromises the upstream package, one of its dependencies, or the package distribution channel. 2. The attacker publishes a malicious release under the expected package name. 3. A user follows the documented `pip install feedparser` instruction after the malicious release becomes current. 4. `pip` retrieves and installs the mutable release without hash verification. 5. Malicious package code can run during installation or when `feedparser` is imported by the RSS monitor. ### Impact Assessment Successful exploitation could execute arbitrary Python or installation-time code with the privileges of the user or service performing the installation. The resulting scope may include access to that account's files, environment variables, application credentials, and network permissions. The skill does not request elevated privileges, so system-wide compr ...[truncated 100 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin `feedparser` to a specific reviewed version, for example through a version constraint such as `feedparser==<reviewed-version>`. 2. Maintain a lockfile containing resolved transitive dependencies. 3. Require package hashes, such as with a hashed requirements file and `pip install --require-hashes`. 4. Explicitly use a trusted package index and prevent unintended fallback to untrusted indexes. 5. Install the dependency in an isolated virtual environment under a non-privileged account. 6. Add automated dependency vulnerability and integrity scanning. 7. Review and deliberately update the pinned version rather than automatically consuming the latest release. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:33
Finding
Unrestricted Feed URL Fetching Enables Server-Side Request Forgery<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 33-53 **Vulnerability Type**: Unvalidated caller-controlled resource retrieval **Risk Level**: High ### Vulnerable Code ```python def add_feed(self, name: str, url: str): self.feeds[name] = url def check_updates(self) -> list: updates = [] for name, url in self.feeds.items(): feed = feedparser.parse(url) for entry in feed.entries[:5]: entry_time = datetime(*entry.published_parsed[:6]) if name not in self.last_check or entry_time > self.last_check[name]: updates.append({ 'feed': name, 'title': entry.title, 'link': entry.link, 'published': entry.get('published', 'Unknown'), }) self.last_check[name] = datetime.now() return updates def get_entries(self, url: str, limit: int = 10): feed = feedparser.parse(url) return [{ 'title': e.title, 'link': e.link, 'summary': e.get('summary', '')[:200], } for e in feed.entries[:limit]] ``` ### Technical Analysis The `add_feed` and `get_entries` methods accept caller-controlled locations and pass them directly to `feedparser.parse`. No validation restricts the URI scheme, hostname, resolved IP address, port, redirects, or destination network. When the caller can influence the URL, the runtime may be induced to request resources from destinations accessible to the agent host but inaccessible to the caller. Potential targets include loopback services, private-network services, link-local cloud metadata endpoints, and other internal HTTP resources. Depending on the schemes supported by the installed parser and runtime, non-network resource locations may also require explicit rejection. The methods return parsed titles, links, and summaries. If an internal endpoint returns content that can be interpreted as a f ...[truncated 1915 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Permit only explicitly required schemes, preferably `https`. 2. Reject URLs containing embedded credentials, ambiguous host syntax, fragments, or unnecessary nonstandard ports. 3. Resolve the hostname before making the request and reject loopback, private, link-local, multicast, reserved, and unspecified IP address ranges for both IPv4 and IPv6. 4. Revalidate the resolved destination immediately before connection to reduce DNS-rebinding risk. 5. Disable redirects where possible. If redirects are needed, validate the scheme, hostname, resolved address, and port at every redirect hop. 6. Prefer an explicit allowlist of approved feed domains when the use case permits it. 7. Perform retrieval through a restricted HTTP client or egress proxy rather than allowing the parser to fetch arbitrary locations directly. 8. Enforce connection and response timeouts, response-size limits, redirect limits, and accepted content types. 9. Run the fetcher in a sandbox with restricted filesystem access, minimal credentials, and network egress limited to public HTTP destinations. 10. Add tests covering loopback addresses, RFC 1918 private ranges, IPv6 local ranges, link-local metadata endpoints, encoded IP forms, DNS rebinding, and redirect-based bypasses. ]]>
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • 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
Findings (1)

Natural-Language Policy Violations

Medium
Confidence
91% confidence
Finding
The natural-language description and activation instructions are presented in Chinese only, with no indication that other languages are supported or that the user can opt in to this locale. This can violate language/locale policy because it implicitly constrains usage to a specific language without documented justification or user choice.

Static analysis

No suspicious patterns detected.