xhs

This Bash wrapper is a high-risk launcher: while the wrapper itself contains no explicit exfiltration or backdoor code, it executes many unverified Node.js scripts with user/root privileges, includes language suggesting concealment ('stealth patches'), suppresses at least one error output, and writes a persistent marker file. These operational behaviors are consistent with potential malicious persistence or unauthorized tampering. Final determination requires auditing the invoked patch-*.js files. Treat as potentially dangerous until those scripts are reviewed.

This script performs an in-place patch of a globally installed module to add cross-process timing controls (via /tmp/xhs-interaction.lock) and to alter an existing delay method to use that global coordination. The code itself does not perform network exfiltration, spawn shells, or harvest credentials, but it does modify installed package code on disk — a supply-chain/tampering behavior that can be abused. If this modification was applied without explicit consent or package maintainer review it should be treated as suspicious and potentially malicious. Recommend verifying intent, restoring original files from a trusted source, and preventing unauthorized write access to global module directories.

[Skill Scanner] Installation of third-party script detected This Skill's documented capabilities are plausible and consistent with its stated purpose (XHS research). The primary security concerns are supply-chain and operational: it depends on an external CLI (rednote-mcp) and unspecified local patches, requires authenticated session cookies/xsec_token, and instructs global installs and xvfb-run interactions. Those elements are necessary for scraping an authenticated site but increase risk — a malicious or compromised rednote-mcp or hidden patches could harvest cookies or exfiltrate data. I do not see direct evidence of malware in the skill text itself, but the trust boundary (third-party CLI and patches) and use of root paths make this suspicious from a supply-chain perspective. Recommend: only run in an isolated, ephemeral environment; inspect apply-all.sh and rednote-mcp sources before installing; protect and rotate cookies; avoid running as host root. LLM verification: This skill appears functionally coherent with the stated purpose (XHS post research) and most capabilities make sense for that job (searching, fetching posts, images, writing per-post files, checkpointing). However, several red flags require further review before trusting it: use of cookies/session tokens, an explicit reference to "stealth patches" (evasion), and execution of third-party tooling (rednote-mcp) with an npm install pattern but no documented trusted source. Because the actual CLI sc

This script is a local patcher that replaces a processing routine inside an installed package to implement a scroll-and-click approach. It does not itself exhibit explicit data exfiltration, shell execution, or dynamic code-evaluation in the provided fragment. The primary security concern is supply-chain/tampering risk: destructive in-place modification of a globally installed module without backups or integrity checks, combined with requiring elevated filesystem privileges. Review the resulting patched file before use, prefer repository-level patches or contributing upstream, and avoid running such scripts with unnecessary privileges.

The code is a local 'patcher' that modifies an installed package file to add proxy-loading capability and inject proxy configuration into Playwright browser launches. It does not itself perform network exfiltration or remote control, but it overwrites files in global node_modules without backups or integrity checks, and it handles potentially sensitive proxy credentials (server, username, password) from a local JSON file and passes them into the browser process. The script is brittle (string-based replacements) and the provided snippet contains a syntactic anomaly that may indicate corruption or incompleteness. While likely intended for legitimate convenience, the technique of in-place patching is a notable supply-chain risk and could be repurposed maliciously. Recommend: do not run such a patcher without auditing the exact modifications, create backups, and prefer contributing upstream or using supported extension/config mechanisms instead of modifying installed package files directly.

The script performs an in-place modification of a globally installed package file to replace a scrolling implementation with a mouse-wheel-driven, randomized, human-like scrolling routine intended for a Puppeteer-like runtime. There is no explicit data exfiltration, remote communication, or credential theft in the fragment. The main security concerns are: (1) in-place alteration of node_modules without backup or verification (supply-chain persistence risk), (2) use of a hardcoded global path requiring elevated privileges, and (3) behavioral change introducing anti-detection techniques that can be abused for scraping or evasion. Treat this as a moderate supply-chain/security risk: inspect the provenance of the patch, create backups, and avoid running with elevated privileges on production systems.

This script performs an unauthorized-appearing in-place patch of a globally installed npm package by injecting a new method that will cause outbound navigation to an external domain when executed. That behavior is characteristic of supply-chain tampering and is high-risk: even though the injected code does not show immediate data exfiltration, the ability to persistently modify dependency source and add network-capable code is dangerous. If this change was not intentionally applied by a trusted maintainer, treat it as a potential compromise: revert the package to a known-good copy, investigate how the script was introduced/executed, and audit other global packages/files for unexpected modifications.

The code is a targeted in-place patcher that injects stealth-driven Chromium launch arguments into a vendored module. While not executing external network activity or directly exfiltrating data, it weakens security controls (no-sandbox) and enables automation evasion. This pattern poses supply-chain and operational risks and warrants review of provenance, authorization, and potential unintended consequences in production environments.

The fragment patches a local module to inject stealth browser automation evasion logic, enabling the code to appear less like an automated entity. This is a non-negligible supply-chain risk because it alters a published dependency at runtime, potentially persisting beyond the immediate scope of the app. While there is no direct data exfiltration or system compromise, the stealth injection could be misused for automated scraping or abuse. Recommend reviewing for legitimate use, avoiding in-place patching of dependencies, and considering alternative approaches (feature flags, wrapper scripts, or upstream configuration) to achieve legitimate automation without modifying package code.

This is a local patcher that replaces a function inside an installed Node.js package file to change browser-scrolling behavior. The replacement code itself resembles benign Puppeteer/Playwright automation logic (human-like scrolling and wait heuristics) and contains no direct exfiltration/network operations or obfuscated code. The primary security concerns are: (1) it performs an in-place persistent modification of a globally installed package (supply-chain persistence risk), (2) it requires elevated permissions to write into /usr/lib/node_modules, and (3) it makes no backups or integrity checks before overwriting. Only run such scripts when you fully trust their origin; otherwise treat this as a risky supply-chain modification mechanism that could be repurposed to introduce backdoors or data-stealing behavior later.

This script is a risky local patcher that modifies a globally installed npm package file to add cookie-age checks and logging. It does not show direct exfiltration or remote control, but it performs high-impact filesystem mutations in /usr/lib/node_modules and inspects root-owned cookie metadata. The implementation is buggy (cookieHelpers unset) and dangerous: running it can corrupt the target module or introduce supply-chain persistence if repaired to insert arbitrary code. Treat as moderate-to-high integrity risk; do not run with elevated privileges, audit the target file and create backups before any modifications.

The fragment patches an installed tool to switch from an in-memory rate limiter to a file-based rate limiter persisted under the user home directory. While not inherently malicious (no exfiltration, no network activity, no hardcoded secrets), runtime modification of dependencies and persistent state via filesystem presents supply-chain and persistence risks. The code appears to be designed to ensure rate-limiting across restarts, but its method (modifying installed modules) is unusual and could be abused if tampered. Treat as a potential risk: review the need for such patching, ensure integrity of the module, and consider signing/verifying patches to prevent supply-chain abuse.

This script is a filesystem patcher that injects new executable JavaScript into a globally installed package. That pattern is high-risk: it constitutes supply-chain or local tampering/persistence. While the injected content shown appears to implement a benign automation utility (scroll_test), the act of silently modifying node_modules without backup, integrity checks, or clear authorization is a dangerous behavior and can be leveraged to persist backdoors or exfiltrate data later. Treat occurrences of this pattern as suspicious: verify provenance, restore original package from a trusted source, and audit the modified file and any associated package-lock or installation logs.