website-rebuild

SUSPICIOUS. The skill’s footprint is internally consistent with its stated purpose of website rebuilding, and its install paths are mostly official and pinned. However, the purpose itself is inherently high-risk from an IP/data-handling standpoint because it automates high-fidelity cloning, large-scale crawling, reverse engineering, and local serving of third-party sites. I found no confirmed credential theft, covert exfiltration, pre-execution malware, or deceptive third-party credential routing, so this is not malicious; the main risk is broad dual-use cloning capability rather than hidden compromise behavior.

This is a readable site-mirroring CLI, not evidence of malware. It fetches URLs supplied in a seed file and asset redirect targets without restricting their hosts, which can enable SSRF, including requests to local or internal services, if those inputs or remote responses are untrusted. It also writes URL-derived files, whose path containment depends on the unprovided localRelPath helper. Severity is moderate and contextual; no suspicious domain, credential target, or environment-variable access appears in this file.

This is a payload comparison and optional dump utility, not apparent malware. Its main security risk is executing Nuxt 2 JavaScript extracted from fetched HTML via new Function; a malicious or compromised endpoint could execute code with the Node.js process's permissions. Network targets and the dump directory are selected by CLI arguments, and no credentials or environment variables are collected. Severity is moderate when endpoints are untrusted; otherwise this behavior is consistent with the tool's stated parsing purpose.

No direct evidence of malware (e.g., hardcoded secrets, explicit network exfiltration, or destructive actions) is present in this fragment alone. However, the module is explicitly designed to execute arbitrary JavaScript supplied by an imported config (via eval(s.js) and inlined cfg.setup()) and to run that executable payload in a spawned probe process through a '--eval' argument. This creates a high supply-chain/control-plane risk: if an attacker can influence the config path/content or the probe script, they can run arbitrary code and exfiltrate or manipulate whatever the probe/config collects and writes to the output JSON/logs.

This module is a downloader/mirroring utility for HLS playlists and referenced segments, with no clear indicators of covert malware (no eval/new Function, no process spawning, no persistence, no credential theft or exfiltration mechanisms beyond expected mirroring behavior). The primary security concerns are (1) potential path traversal/arbitrary file write because filesystem destinations are derived from decoded remote URL pathnames without containment checks, and (2) unrestricted fetching of any URLs discovered inside untrusted playlist contents (SSRF-like tool behavior). Even if intentional malware is unlikely, these weaknesses make the module unsafe to run against untrusted playlists without hardening (path normalization/containment enforcement and URL allowlisting).

This code is a client-side “probe” shim that, when enabled via ?__probe, aggressively monkey-patches global browser APIs (time, RNG, timers/RAF, visibility/focus, and IntersectionObserver) and provides external control via window.__pump/__pumpTime and reseeding via window.__reseed. There is no direct evidence of data theft or network exfiltration in this snippet, but it is security-relevant because it makes time and randomness deterministic/predictable, which can undermine security logic if the host application relies on Math.random or timing for nonces/tokens/fingerprinting. Recommend auditing how/when this code is loaded and ensuring it cannot be triggered in production or used by untrusted actors.

This module is a verification harness with a notable supply-chain/behavioral risk: it dynamically imports a runtime-specified config and injects cfg.build(cases) into an expression string that is executed by an external probe via a '--eval' mechanism against remote target pages. While there is no direct malware behavior (e.g., exfiltration/system damage) evidenced in this fragment, the dynamic execution pipeline makes the security of --config and the probe critical. Treat the config and probe as high-trust and add provenance/allowlisting to reduce risk.

No explicit malware payload is evident in this module, but it strongly matches client-side telemetry/fingerprinting behavior: it harvests private animation metadata from the DOM (_animInfo), evaluates easing functions at fixed timestamps to create deterministic curve fingerprints, and derives identities via additional processing. It also includes a high-uncertainty integration point (window.__req with a hardcoded identifier) and returns executable code strings intended for later evaluation. The primary security concern is privacy/tracking and potential exfiltration/side effects handled outside this fragment by the runtime orchestration and window.__req implementation.