Secure your dependencies. Ship with confidence.

The code explicitly harvests highly sensitive authentication/CSRF/session cookies from locally installed browser profiles for multiple platforms and then stores those secrets into application configuration and persists them to local files in the user’s home directory (including plaintext/token material). Although this snippet shows no exfiltration or networking, the credential-harvesting + persistence behavior is characteristic of account/session compromise workflows and represents a high security risk for a dependency in a supply chain. Additionally, exceptions are silently swallowed in persistence helpers, and there is a likely variable-name bug in the return statement, indicating incomplete correctness but not changing the primary secret-access behavior.

This module is highly security-sensitive. It persistently launches a sudo-backed ttyd web terminal running bash and starts code-server with authentication disabled, both on dynamically chosen ports and with services bound to all interfaces. While the fragment does not show explicit data theft/exfiltration, it creates remote interactive execution/control capabilities and reduces auditability via DEVNULL, making it plausibly backdoor-like and extremely dangerous in a supply-chain context unless strictly justified and tightly firewalled.

The most significant finding is a critical supply-chain/runtime compromise vector: this code fetches JavaScript from a public CDN at runtime and executes it via eval to establish globalThis.use, which is then used to obtain the command execution helper ($). That makes all subsequent gh/git command execution and downstream tool behavior contingent on unpinned, unaudited remote code. Additional risks include potentially unsafe command template interpolation (depending on command-stream safety) and forceful recursive deletion under a caller-provided tempDir. No direct malware behaviors (e.g., credential theft) are visible here beyond enabling potential RCE, but the compromise vector is strong and should be treated as a security alert.

This module is extremely high risk due to an explicit runtime supply-chain remote code execution pattern: it downloads JavaScript from a public CDN at runtime and executes it with eval() to bootstrap globalThis.use and the command execution layer. Even though the rest of the code is largely consistent with GitHub repo automation, the initial eval+network bootstrap makes the overall package untrustworthy from a malware/backdoor standpoint and raises the probability of consequential compromise (including exfiltration or sabotage) if the CDN payload is altered. Additionally, destructive git/GitHub mutation actions amplify impact if control is gained. Mitigation: remove runtime CDN fetching + eval, vendor the dependency with lockfile integrity, pin versions, and enforce signed/integrity-verified module loading.

This code performs immediate outbound beaconing/exfiltration on import to a hardcoded external webhook, transmitting identifiable local information (hostname, user, OS) over HTTP. Silent exception handling and top-level execution strongly indicate stealthy telemetry rather than legitimate functionality. Treat this as malicious supply-chain behavior and block/remove the dependency; investigate systems where it may have been imported and consider incident response for potential data exposure.

This module is best characterized as an obfuscated stage-1 loader/packer. It reconstructs runtime strings/keys from embedded data, conditionally triggers execution based on decoded/gated checks, and—most importantly—uses new Function(...) to execute decoded code during initialization. It then wires exports by requiring multiple local modules, including a Socket component. While this fragment does not conclusively prove exfiltration or credential theft by itself, the loader + dynamic evaluation pattern is a major supply-chain red flag and warrants quarantine and full decoded-behavior inspection before use.

This module is explicitly designed to obtain OS-level browser Safe Storage credentials, decrypt targeted Substack authentication/session cookies from Chrome/Brave on macOS, and write the resulting plaintext cookie values to a local JSON file. That workflow is characteristic of credential/session theft and enables account compromise via session replay. No network exfiltration is shown in this fragment, but the produced plaintext cookie artifact is itself highly sensitive. Treat as malicious/credential-stealing code; also note a likely return-variable typo (out_pat) that could cause runtime failure, but the suspicious actions are executed before that point.

This module is explicitly designed to obtain OS-level browser Safe Storage credentials, decrypt targeted Substack authentication/session cookies from Chrome/Brave on macOS, and write the resulting plaintext cookie values to a local JSON file. That workflow is characteristic of credential/session theft and enables account compromise via session replay. No network exfiltration is shown in this fragment, but the produced plaintext cookie artifact is itself highly sensitive. Treat as malicious/credential-stealing code; also note a likely return-variable typo (out_pat) that could cause runtime failure, but the suspicious actions are executed before that point.

This module is highly consistent with a malicious remote access/spy agent: it enrolls a host to a server and provides bidirectional command-and-control to start screen/audio capture, inject mouse/keyboard input, and exfiltrate browser history and filesystem contents (listing and arbitrary reads) over the network. The lack of visible authentication/authorization/validation before executing high-risk actions further increases maliciousness likelihood.

The code performs environment/package fingerprinting (home directory, username, hostname, DNS resolvers, module path, and package.json metadata) and exfiltrates it via an HTTPS POST to a hardcoded external endpoint. The behavior is strongly indicative of unauthorized tracking/exfiltration rather than legitimate library functionality, with no gating and suppressed error visibility.

Despite being primarily a registry/configuration loader, this module includes credentialed outbound notification behavior to a third-party service with hardcoded secrets. When a symbol is not registered (defaulting to strict behavior unless configured otherwise), it transmits runtime context (symbol and operation) externally. This is a high-risk supply-chain/surveillance style pattern, not typical for a benign dependency.

Highest concern: the module conditionally fetches JavaScript from https://unpkg.com and executes it with eval to create a globalThis.use loader, enabling runtime remote code execution and major supply-chain risk (no integrity/version pinning). Secondary concern: it then parses input and writes derived values directly into process.env without strong allowlisting/validation of keys/values, amplifying impact from malicious or unexpected configuration content.

This package should be treated as high risk. The explicit postinstall script gives arbitrary code execution on install; the declared dependencies provide powerful capabilities (machine ID access, screenshots, input automation, network sockets) that enable data collection, telemetry, remote control, and exfiltration. Until postinstall.js and the package source are audited and verified benign, installing this package in sensitive environments is unsafe.

This module is a high-risk Telegram remote administration/backdoor pattern. The /run command provides arbitrary shell command execution by passing Telegram-provided input directly to child_process.execAsync, and the bot returns command output/errors back to the chat—enabling both host compromise and data exfiltration. Additionally, if TELEGRAM_CHAT_IDS is unset/empty, authorization effectively becomes allow-all, making the RCE endpoint reachable by any Telegram chat that can message the bot. Treat the package as extremely dangerous unless authorization is tightly enforced and the /run functionality is removed or replaced with a strict command allowlist executed without a shell.

This fragment is a high-confidence malicious loader/dropper: it downloads arbitrary Python code from a hardcoded remote IP over unencrypted HTTP, writes it to the local temp directory as launcher.py, and executes it using pythonw.exe with no visible window. The absence of integrity/authenticity checks and the stealthy execution strongly indicate malware staging behavior rather than legitimate functionality.

This module has a critical supply-chain execution vulnerability pattern: it downloads JavaScript from a public CDN at runtime and executes it immediately via eval, then uses the evaluated result to obtain a command execution interface. Without integrity verification, pinning, or sandboxing, the code can be replaced/compromised to run arbitrary attacker-controlled JavaScript and potentially execute unintended commands. The remaining GitHub entity-check logic is conventional and mostly limited to querying and string-matching for not-found responses.

This module contains a critical remote-code-execution-like primitive via exec(code) using self.component.custom_methods (potentially attacker-controlled if configuration is not strictly locked). It also uses string-based method dispatch for timers. Together, these enable arbitrary Python code execution and device/gateway command manipulation. If custom_methods/meta are not strictly admin-only and protected, the security risk is very high.

High risk: the package runs git submodule update --init --remote and then installs/builds code inside lib/demowright during prepare/postinstall, and it changes git hooks path. These actions fetch and execute code from external git remotes and allow repository hooks to run, creating a supply-chain and remote code execution vector. Inspect the .githooks directory, the .gitmodules file, and the contents of lib/demowright (and its package.json and scripts) before installing. If you cannot audit the fetched submodule(s), treat this package as untrusted.

The script contains a high-risk backdoor-like capability: when FMTR_DEV is enabled, it opens root SSH access with a hardcoded password, dumps environment data, and runs SSH in foreground with verbose logging. This undermines container isolation, enables remote compromise, and poses severe supply-chain security risks. It should be removed or replaced with secure, auditable behavior (e.g., disallow root SSH, use proper authentication via keys, avoid dumping environment, and validate inputs).

This module contains a critical remote-code-execution-like primitive via exec(code) using self.component.custom_methods (potentially attacker-controlled if configuration is not strictly locked). It also uses string-based method dispatch for timers. Together, these enable arbitrary Python code execution and device/gateway command manipulation. If custom_methods/meta are not strictly admin-only and protected, the security risk is very high.

This module contains a clear supply-chain risk: it performs covert install-time network exfiltration of host/user/runtime context to a hardcoded external webhook endpoint. The behavior is automatic (no user consent), includes potentially sensitive environment details, and suppresses errors to reduce detectability. Treat this package/module as malicious or unauthorized telemetry and do not install without remediation.

The code explicitly harvests highly sensitive authentication/CSRF/session cookies from locally installed browser profiles for multiple platforms and then stores those secrets into application configuration and persists them to local files in the user’s home directory (including plaintext/token material). Although this snippet shows no exfiltration or networking, the credential-harvesting + persistence behavior is characteristic of account/session compromise workflows and represents a high security risk for a dependency in a supply chain. Additionally, exceptions are silently swallowed in persistence helpers, and there is a likely variable-name bug in the return statement, indicating incomplete correctness but not changing the primary secret-access behavior.

This module’s primary security issue is a critical supply-chain pattern: it fetches executable JavaScript from a public CDN at runtime and executes it via eval() to initialize globalThis.use. That yields immediate, full process RCE capability before any of the program’s other logic runs. Additional secondary risk exists around logging (timestamped log file creation and a feature warning that logs may contain secrets and could be uploaded elsewhere) and potential filesystem write-to-arbitrary-directory if logDir is untrusted. Overall, the code should be treated as high risk unless the remote loader is removed, pinned, and verified (e.g., integrity-checked and version-pinned) and the log upload path is carefully controlled/redacted.

This fragment implements a high-impact remote execution capability: a Socket.IO server can command the client to run arbitrary shell commands (interactive via PTY/spawn and remote stdin) and run embedded code via execSync (python -c shown), with configurable working directory and environment inheritance. Command output is streamed back to the remote server, enabling data exfiltration. No robust allowlisting or authorization controls are visible in the fragment. Treat this as extremely sensitive and potentially backdoor-like behavior unless the surrounding product context enforces strong authentication, authorization, and strict command constraints.

This code fragment is extremely unsafe. It contains direct arbitrary Python execution (eval/exec) and multiple forms of OS command execution (subprocess/os.system with a shell=True pattern), plus unrestricted filesystem read/write, outbound HTTP request capabilities, and explicitly unsafe SQL string construction. If this appears in a dependency, it should be treated as a high-confidence malicious or backdoor/exploit-support component pending broader repository and usage-site review.

The code explicitly harvests highly sensitive authentication/CSRF/session cookies from locally installed browser profiles for multiple platforms and then stores those secrets into application configuration and persists them to local files in the user’s home directory (including plaintext/token material). Although this snippet shows no exfiltration or networking, the credential-harvesting + persistence behavior is characteristic of account/session compromise workflows and represents a high security risk for a dependency in a supply chain. Additionally, exceptions are silently swallowed in persistence helpers, and there is a likely variable-name bug in the return statement, indicating incomplete correctness but not changing the primary secret-access behavior.

This module is highly security-sensitive. It persistently launches a sudo-backed ttyd web terminal running bash and starts code-server with authentication disabled, both on dynamically chosen ports and with services bound to all interfaces. While the fragment does not show explicit data theft/exfiltration, it creates remote interactive execution/control capabilities and reduces auditability via DEVNULL, making it plausibly backdoor-like and extremely dangerous in a supply-chain context unless strictly justified and tightly firewalled.

The most significant finding is a critical supply-chain/runtime compromise vector: this code fetches JavaScript from a public CDN at runtime and executes it via eval to establish globalThis.use, which is then used to obtain the command execution helper ($). That makes all subsequent gh/git command execution and downstream tool behavior contingent on unpinned, unaudited remote code. Additional risks include potentially unsafe command template interpolation (depending on command-stream safety) and forceful recursive deletion under a caller-provided tempDir. No direct malware behaviors (e.g., credential theft) are visible here beyond enabling potential RCE, but the compromise vector is strong and should be treated as a security alert.

This module is extremely high risk due to an explicit runtime supply-chain remote code execution pattern: it downloads JavaScript from a public CDN at runtime and executes it with eval() to bootstrap globalThis.use and the command execution layer. Even though the rest of the code is largely consistent with GitHub repo automation, the initial eval+network bootstrap makes the overall package untrustworthy from a malware/backdoor standpoint and raises the probability of consequential compromise (including exfiltration or sabotage) if the CDN payload is altered. Additionally, destructive git/GitHub mutation actions amplify impact if control is gained. Mitigation: remove runtime CDN fetching + eval, vendor the dependency with lockfile integrity, pin versions, and enforce signed/integrity-verified module loading.

This code performs immediate outbound beaconing/exfiltration on import to a hardcoded external webhook, transmitting identifiable local information (hostname, user, OS) over HTTP. Silent exception handling and top-level execution strongly indicate stealthy telemetry rather than legitimate functionality. Treat this as malicious supply-chain behavior and block/remove the dependency; investigate systems where it may have been imported and consider incident response for potential data exposure.

This module is best characterized as an obfuscated stage-1 loader/packer. It reconstructs runtime strings/keys from embedded data, conditionally triggers execution based on decoded/gated checks, and—most importantly—uses new Function(...) to execute decoded code during initialization. It then wires exports by requiring multiple local modules, including a Socket component. While this fragment does not conclusively prove exfiltration or credential theft by itself, the loader + dynamic evaluation pattern is a major supply-chain red flag and warrants quarantine and full decoded-behavior inspection before use.

This module is explicitly designed to obtain OS-level browser Safe Storage credentials, decrypt targeted Substack authentication/session cookies from Chrome/Brave on macOS, and write the resulting plaintext cookie values to a local JSON file. That workflow is characteristic of credential/session theft and enables account compromise via session replay. No network exfiltration is shown in this fragment, but the produced plaintext cookie artifact is itself highly sensitive. Treat as malicious/credential-stealing code; also note a likely return-variable typo (out_pat) that could cause runtime failure, but the suspicious actions are executed before that point.

This module is explicitly designed to obtain OS-level browser Safe Storage credentials, decrypt targeted Substack authentication/session cookies from Chrome/Brave on macOS, and write the resulting plaintext cookie values to a local JSON file. That workflow is characteristic of credential/session theft and enables account compromise via session replay. No network exfiltration is shown in this fragment, but the produced plaintext cookie artifact is itself highly sensitive. Treat as malicious/credential-stealing code; also note a likely return-variable typo (out_pat) that could cause runtime failure, but the suspicious actions are executed before that point.

This module is highly consistent with a malicious remote access/spy agent: it enrolls a host to a server and provides bidirectional command-and-control to start screen/audio capture, inject mouse/keyboard input, and exfiltrate browser history and filesystem contents (listing and arbitrary reads) over the network. The lack of visible authentication/authorization/validation before executing high-risk actions further increases maliciousness likelihood.

The code performs environment/package fingerprinting (home directory, username, hostname, DNS resolvers, module path, and package.json metadata) and exfiltrates it via an HTTPS POST to a hardcoded external endpoint. The behavior is strongly indicative of unauthorized tracking/exfiltration rather than legitimate library functionality, with no gating and suppressed error visibility.

Despite being primarily a registry/configuration loader, this module includes credentialed outbound notification behavior to a third-party service with hardcoded secrets. When a symbol is not registered (defaulting to strict behavior unless configured otherwise), it transmits runtime context (symbol and operation) externally. This is a high-risk supply-chain/surveillance style pattern, not typical for a benign dependency.

Highest concern: the module conditionally fetches JavaScript from https://unpkg.com and executes it with eval to create a globalThis.use loader, enabling runtime remote code execution and major supply-chain risk (no integrity/version pinning). Secondary concern: it then parses input and writes derived values directly into process.env without strong allowlisting/validation of keys/values, amplifying impact from malicious or unexpected configuration content.

This package should be treated as high risk. The explicit postinstall script gives arbitrary code execution on install; the declared dependencies provide powerful capabilities (machine ID access, screenshots, input automation, network sockets) that enable data collection, telemetry, remote control, and exfiltration. Until postinstall.js and the package source are audited and verified benign, installing this package in sensitive environments is unsafe.

This module is a high-risk Telegram remote administration/backdoor pattern. The /run command provides arbitrary shell command execution by passing Telegram-provided input directly to child_process.execAsync, and the bot returns command output/errors back to the chat—enabling both host compromise and data exfiltration. Additionally, if TELEGRAM_CHAT_IDS is unset/empty, authorization effectively becomes allow-all, making the RCE endpoint reachable by any Telegram chat that can message the bot. Treat the package as extremely dangerous unless authorization is tightly enforced and the /run functionality is removed or replaced with a strict command allowlist executed without a shell.

This fragment is a high-confidence malicious loader/dropper: it downloads arbitrary Python code from a hardcoded remote IP over unencrypted HTTP, writes it to the local temp directory as launcher.py, and executes it using pythonw.exe with no visible window. The absence of integrity/authenticity checks and the stealthy execution strongly indicate malware staging behavior rather than legitimate functionality.

This module has a critical supply-chain execution vulnerability pattern: it downloads JavaScript from a public CDN at runtime and executes it immediately via eval, then uses the evaluated result to obtain a command execution interface. Without integrity verification, pinning, or sandboxing, the code can be replaced/compromised to run arbitrary attacker-controlled JavaScript and potentially execute unintended commands. The remaining GitHub entity-check logic is conventional and mostly limited to querying and string-matching for not-found responses.

This module contains a critical remote-code-execution-like primitive via exec(code) using self.component.custom_methods (potentially attacker-controlled if configuration is not strictly locked). It also uses string-based method dispatch for timers. Together, these enable arbitrary Python code execution and device/gateway command manipulation. If custom_methods/meta are not strictly admin-only and protected, the security risk is very high.

High risk: the package runs git submodule update --init --remote and then installs/builds code inside lib/demowright during prepare/postinstall, and it changes git hooks path. These actions fetch and execute code from external git remotes and allow repository hooks to run, creating a supply-chain and remote code execution vector. Inspect the .githooks directory, the .gitmodules file, and the contents of lib/demowright (and its package.json and scripts) before installing. If you cannot audit the fetched submodule(s), treat this package as untrusted.

The script contains a high-risk backdoor-like capability: when FMTR_DEV is enabled, it opens root SSH access with a hardcoded password, dumps environment data, and runs SSH in foreground with verbose logging. This undermines container isolation, enables remote compromise, and poses severe supply-chain security risks. It should be removed or replaced with secure, auditable behavior (e.g., disallow root SSH, use proper authentication via keys, avoid dumping environment, and validate inputs).

This module contains a critical remote-code-execution-like primitive via exec(code) using self.component.custom_methods (potentially attacker-controlled if configuration is not strictly locked). It also uses string-based method dispatch for timers. Together, these enable arbitrary Python code execution and device/gateway command manipulation. If custom_methods/meta are not strictly admin-only and protected, the security risk is very high.

This module contains a clear supply-chain risk: it performs covert install-time network exfiltration of host/user/runtime context to a hardcoded external webhook endpoint. The behavior is automatic (no user consent), includes potentially sensitive environment details, and suppresses errors to reduce detectability. Treat this package/module as malicious or unauthorized telemetry and do not install without remediation.

The code explicitly harvests highly sensitive authentication/CSRF/session cookies from locally installed browser profiles for multiple platforms and then stores those secrets into application configuration and persists them to local files in the user’s home directory (including plaintext/token material). Although this snippet shows no exfiltration or networking, the credential-harvesting + persistence behavior is characteristic of account/session compromise workflows and represents a high security risk for a dependency in a supply chain. Additionally, exceptions are silently swallowed in persistence helpers, and there is a likely variable-name bug in the return statement, indicating incomplete correctness but not changing the primary secret-access behavior.

This module’s primary security issue is a critical supply-chain pattern: it fetches executable JavaScript from a public CDN at runtime and executes it via eval() to initialize globalThis.use. That yields immediate, full process RCE capability before any of the program’s other logic runs. Additional secondary risk exists around logging (timestamped log file creation and a feature warning that logs may contain secrets and could be uploaded elsewhere) and potential filesystem write-to-arbitrary-directory if logDir is untrusted. Overall, the code should be treated as high risk unless the remote loader is removed, pinned, and verified (e.g., integrity-checked and version-pinned) and the log upload path is carefully controlled/redacted.

This fragment implements a high-impact remote execution capability: a Socket.IO server can command the client to run arbitrary shell commands (interactive via PTY/spawn and remote stdin) and run embedded code via execSync (python -c shown), with configurable working directory and environment inheritance. Command output is streamed back to the remote server, enabling data exfiltration. No robust allowlisting or authorization controls are visible in the fragment. Treat this as extremely sensitive and potentially backdoor-like behavior unless the surrounding product context enforces strong authentication, authorization, and strict command constraints.

This code fragment is extremely unsafe. It contains direct arbitrary Python execution (eval/exec) and multiple forms of OS command execution (subprocess/os.system with a shell=True pattern), plus unrestricted filesystem read/write, outbound HTTP request capabilities, and explicitly unsafe SQL string construction. If this appears in a dependency, it should be treated as a high-confidence malicious or backdoor/exploit-support component pending broader repository and usage-site review.