lazyweb

SUSPICIOUS: the visible skill is mostly a documentation-style router, and its local command use is benign, but its actual footprint is broader than a normal design guide because it dynamically fetches and applies third-party skill instructions from many raw URLs. The official Lazyweb installer is same-domain and plausible, yet still a medium/high supply-chain risk due to curl|bash and lack of visible verification. No confirmed malware or overt credential theft is present.

No direct, self-contained malware behavior is evident in this snippet; it functions primarily as a defensive/behavioral test harness for a setup script (pruning legacy skills/plugins, generating integrity markers, and sanitizing MCP configuration). However, the fragment contains several high-impact security patterns that would warrant scrutiny in the underlying setup implementation and config consumers: (1) executing an external bash setup script via spawnSync with overridden PATH/HOME and injected token/URL environment values, and (2) using eval on shell code extracted from the setup script via sed. Additionally, the test fixtures include an execution-capable MCP directive (sh -lc running npx -y mcp-remote), and while the tests expect that unsafe directive to be removed, its presence underscores the importance of strict validation to prevent unintended remote command execution if config were consumed elsewhere.

No definitive malware/backdoor code is visible in this fragment, but there are significant security risks: (1) the `/health` endpoint directly returns `AUTH_TOKEN` (secret exposure), (2) several endpoints use permissive CORS and some may not be protected by `validateAuth`, and (3) the system explicitly enables an agent with allowed tools including `Bash`, making indirect command execution and filesystem access plausible if downstream sandboxing/authorization is insufficient. Additionally, recursive deletion during worktree cleanup could be risky if session/worktree paths are tampered on disk. Requires review of validateAuth, downstream agent/tool execution sandboxing, and whether unauthenticated routes leak sensitive data.

Overall, this fragment does not show explicit classic malware behaviors (no eval/Function, no command execution, no obvious hardcoded malicious endpoints). However, it does implement high-privilege browser behaviors: conditional loading of a Chromium extension from a computed path, persistent Chromium profile usage, and capture/restoration of cookies plus localStorage/sessionStorage. It also records console/network activity and can auto-accept/submit dialog prompts. These features could enable supply-chain risk (malicious extension) or sensitive data exposure depending on the implementation of findExtensionPath() and the add*Entry logging/export functions (not included).

No direct evidence of sabotage or overt malware (no network exfiltration, persistence, or dynamic code execution) is present in this fragment. The code is, however, highly sensitive: it reads local Chromium cookie databases and retrieves decryption keys from macOS Keychain/Linux Secret Service, then returns decrypted cookie values. That combination is consistent with legitimate cookie-import functionality, but it also represents a high-impact capability if misused. Based on the provided code alone, the main security concerns are misuse/privilege implications rather than clear malicious behavior.

This code fragment is a powerful page inspection/automation command handler that includes explicit arbitrary JavaScript execution in the target page ('js') and a local-file-to-in-page execution bridge ('eval' reads a JS file then executes it via target.evaluate). It can also read and return sensitive browser state (cookies, localStorage/sessionStorage with heuristic redaction) and supports writing to localStorage. No direct malware/exfiltration logic is visible in the snippet, but the provided capabilities are high-impact and should be tightly access-controlled; otherwise they could be used for data theft, tampering, or sabotage within the browser context.

This module is best characterized as an agent/orchestration and telemetry component rather than overt malware: it polls a local JSONL queue, invokes the external `claude` CLI with tool access, logs observations into the current git repository, and forwards streamed assistant/tool outputs to a local HTTP server using Bearer authorization. The primary security concern is sensitive data egress and misuse potential: untrusted queue content can drive tool-enabled behavior in the spawned agent, and the agent’s outputs/tool_use inputs are transmitted over HTTP to whatever is listening on the configured SERVER_URL. Classic malicious behaviors (backdoors/credential theft/remotes shells) are not evident in this snippet.

No explicit malware indicators (no obfuscation or direct exfiltration) are present in the shown code. However, the module provides highly sensitive functionality—injecting cookies into a headless browser context and clearing cookies by client-supplied domain strings—through HTTP endpoints and returns operational details. The security posture heavily depends on unseen authorization, how result.cookies is sourced/validated, and whether importedDomains/importedCounts are properly scoped per user/session. If authentication/authorization or isolation is insufficient, the service could be abused for session manipulation or cross-user interference.

This module is a privacy-sensitive telemetry uploader. It collects locally stored CLI/analytics events from a JSONL file, gates transmission on a local consent-file value, and then exfiltrates the event contents to a configurable HTTPS endpoint via an HTTP POST. If present, it also transmits a bearer token read from a local token file as an Authorization header. There are no obvious exploit primitives (no eval/new Function, no process spawning, no reverse shell), and the code is readable (low obfuscation). The main risk is unauthorized or unintended disclosure of local telemetry data and credentials to a remote server, depending on what the events contain and how trustworthy/controlled the endpoint and consent mechanism are.

SUSPICIOUS: the skill’s purpose and capabilities mostly align, and data flow appears directed to the stated Lazyweb service rather than an unrelated exfiltration endpoint. However, the fallback install path is a raw same-vendor curl|bash script from a non-registry source with only partial provenance, so the main concern is supply-chain/install trust rather than clear malicious behavior.

This file is best characterized as a compatibility shim that (1) forwards incoming HTTP requests via a user-supplied fetch after reconstructing a target URL from client-controlled paths and headers, and (2) exposes OS command execution wrappers globally through globalThis.Bun.spawn/spawnSync. While there are no direct signs of intentional malware in this snippet (no hardcoded exfiltration targets, persistence, or obfuscation), it materially increases the potential impact of any upstream misuse because it provides arbitrary command execution and proxy-like request forwarding without input validation or allowlists. It also leaks exception messages to HTTP clients.