Secure your dependencies. Ship with confidence.

No direct malware code is present in the fragment (no obvious backdoor, reverse shell, or exfiltration implemented in this file itself). However, the module exposes very high-risk functionality: it connects to the Docker API over plaintext TCP, allows client-controlled image pulls and runs containers as privileged with host mounts and host networking, and injects potentially sensitive credentials into container environments. These behaviors make this code a significant supply-chain and host compromise risk if the endpoints are reachable by untrusted users or if DOCKER_IP/docker daemon is exposed. Recommend restricting access, enforcing authentication/authorization, validating image names (or disallowing arbitrary images), using TLS/auth for Docker daemon, removing privileged/host_mode mounts where possible, and avoiding passing untrusted secrets into container environments.

The script is designed to send sensitive information from the local system to a remote server, which poses a significant security risk and is indicative of malicious behavior.

Live on npm for 2 days, 15 hours and 37 minutes before removal. Socket users were protected even while the package was live.

This module implements a worker that downloads Python code from a remote API and executes it locally via exec(), supplying the code with api_client and job objects and normal process privileges. That design yields remote code execution capability and thus a high supply-chain/malicious risk if the remote source is untrusted. There is no sandboxing; a malicious server can exfiltrate data, run destructive commands, or install backdoors. The code itself is not obfuscated and contains no hardcoded secrets, but its behavior is inherently dangerous.

The code has multiple indicators of malicious behavior, including the collection and transmission of sensitive system information to external servers, which raises significant security concerns.

Live on npm for 18 minutes before removal. Socket users were protected even while the package was live.

The code initiates a detached child process that runs an external script (`smtp-connection/index.js`) with its I/O streams ignored. This pattern is suspicious as it can be used to execute code in the background without direct visibility or control from the parent process. While it could be for legitimate background operations, the combination of detachment, ignored I/O, and unreferencing the child process raises concerns about potential hidden malicious activity, such as data exfiltration or establishing persistent connections.

Live on npm for 7 days, 11 hours and 35 minutes before removal. Socket users were protected even while the package was live.

The code sends sensitive credentials from environment variables over an unencrypted HTTP connection to an external API service at api[.]sqhyw[.]net:90. It authenticates using username/password from the YEZI_USER environment variable, retrieves access tokens, and automates the process of obtaining mobile phone numbers and SMS verification codes. This behavior poses significant supply chain security risks through: (1) leakage of environment variable credentials over unencrypted HTTP, (2) interaction with a suspicious external domain on a non-standard port, (3) logging of potentially sensitive API responses including tokens and SMS codes, and (4) facilitation of SMS verification bypass which could enable fraudulent account creation or spam activities. The code continuously polls the external API for up to 120 seconds to retrieve SMS codes, creating additional operational risks. While not containing traditional malware payloads, the credential exfiltration and suspicious external communication patterns justify classification as malware due to the significant security risks posed to systems that deploy this code.

This code prompts the operator for a Discord authentication token via the command line, then calls discord.js Client.login(token) (communicating with api[.]discord[.]com) to validate that token. On successful login it immediately persists the raw token and the authenticated account’s username into a database (via saveToken.findOneAndUpdate) in plaintext, with no encryption, access controls, or audit logging. The project’s naming (‘External-Nuker’) and this verification-plus-storage pattern constitute credential harvesting, enabling potential account takeover or automated abusive actions on Discord. Treat as high risk, remove it from any trusted environments, and audit any token stores for unauthorized entries.

This module contains a supply-chain backdoor pattern: it fetches JavaScript from a hard-coded remote URL and executes it immediately on module import via an indirectly-resolved global function. That alone makes the package unsafe to use — it provides an attacker-controlled remote execution channel in any host that requires this module. The rest of the file provides legitimate process/service monitoring features, but that does not mitigate the backdoor risk. Recommendation: treat this package as malicious/untrusted; block or remove it from builds and investigate any systems that imported or executed it.

The fragment implements a dynamic injection mechanism around git submodule foreach to route execution through an instrumentation/telemetry pathway (otel.sh) via eval and environment overrides. While it may be legitimate for telemetry, in a supply-chain context this represents a serious risk: it can modify commands, execute external scripts, and potentially exfiltrate data. The code exhibits dynamic execution, environment-based overrides, and obfuscated-like argument handling patterns that are suspicious and likely malicious in user-controlled environments. The automatic aliasing of git further elevates risk by enabling persistence across sessions.

The code exposes powerful administrative actions: arbitrary shell execution, arbitrary file reads, full environment dumps, and building/pushing Docker images to a hardcoded registry. These are not obfuscated but are high-risk capabilities that can be abused for data exfiltration, remote code execution, and supply-chain leakage if the superuser authentication is compromised or misconfigured. The presence of a hardcoded remote image name for docker push is suspicious for unintended outbound artifact exfiltration. Recommendation: avoid including these endpoints in public packages or ensure strict, auditable authentication and input validation; remove hardcoded push targets and avoid returning full environment variables or arbitrary file contents.

This is a mailcap parser/utility that reads mailcap files and constructs shell commands from their entries. The code executes commands via os.system after performing textual substitution using filename, MIME type, and parameters. That behavior is expected for a mailcap implementation, but it represents a high-risk sink: untrusted mailcap files, environment variables, or attacker-controlled filename/plist values can lead to arbitrary command execution (shell injection). The code itself does not contain obfuscated or hidden malware, credentials, or explicit exfiltration; however, using it with untrusted inputs or untrusted mailcap files is dangerous. Recommend treating mailcap files as trusted input only, or replacing os.system usage with safer invocation (e.g., subprocess with argument lists and proper escaping/validation).

The code is part of the Koxy project, which is used for running API requests and managing flows. The code contains potential security risks and anomalies, including dynamic code execution, parsing of user-controlled data without validation, lack of proper error handling, and access to the file system. These issues should be addressed to ensure the security and integrity of the project.

Live on npm for 7 days, 6 hours and 4 minutes before removal. Socket users were protected even while the package was live.

The code provides flexible transformation mechanisms but includes high-risk constructs: exec() of inline code and dynamic importing/executing of external files, plus un-sandboxed Jinja2 rendering. These features enable arbitrary code execution if transform_request or referenced files are attacker-controlled, presenting a significant supply-chain/runtime code execution risk. The module is not itself demonstrably malicious, but its design makes it dangerous in hostile contexts and should be hardened or avoided unless inputs are fully trusted and validated.

This assembly contains multiple strong indicators of malicious or dual-use behavior: heavy obfuscation, an embedded encrypted resource with custom decoding, in-memory decryption, and direct native API usage for allocating/writing memory and resolving function pointers — a pattern consistent with reflective loaders or runtime shellcode injection. It also includes permissive network behavior (accept-all TLS) and channels for exfiltration (HTTP and SMTP). Even though parts (DB builders, crypto helpers) are legitimate, the hidden payload handling and native injection primitives make this package high risk for supply-chain or backdoor activity. I recommend treating this package as malicious/compromised and removing it from trusted dependencies pending full forensic review.

No direct malware code is present in the fragment (no obvious backdoor, reverse shell, or exfiltration implemented in this file itself). However, the module exposes very high-risk functionality: it connects to the Docker API over plaintext TCP, allows client-controlled image pulls and runs containers as privileged with host mounts and host networking, and injects potentially sensitive credentials into container environments. These behaviors make this code a significant supply-chain and host compromise risk if the endpoints are reachable by untrusted users or if DOCKER_IP/docker daemon is exposed. Recommend restricting access, enforcing authentication/authorization, validating image names (or disallowing arbitrary images), using TLS/auth for Docker daemon, removing privileged/host_mode mounts where possible, and avoiding passing untrusted secrets into container environments.

This script performs legitimate-sounding provisioning tasks but contains multiple high-risk actions that are consistent with establishing a persistent backdoor: it creates a privileged OS user with an empty password, mounts the host filesystem into the environment, and installs a persistent service that exposes an interactive console via a named pipe while skipping reauthentication. Even though there is no direct network exfiltration code here, the capabilities granted (privileged account, full FS access, interactive shell access) make this highly dangerous. Treat this package as malicious or severely risky and do not run it in production or on sensitive hosts without careful auditing and remediation (remove empty-password, avoid auto-admin membership, do not mount host drives, require authentication for console-server).

This module contains high-risk behaviors: it feeds unsanitized user-supplied content into an external CAS and then eval()s the CAS output inside the Python process. That combination creates a clear remote code execution / supply-chain risk. Even though there is no explicit networking or credential theft in the file itself, an attacker able to control 'polys' or the CoCoA binary can achieve arbitrary code execution. Recommend: do not trust unvalidated 'polys' input, remove eval() usage (parse expressions safely or implement a restricted expression evaluator), validate/sanitize CAS output before execution, avoid placing MPLCONFIGDIR in world-writable /tmp, and fix looping-variable bugs. Treat this package as risky until those issues are remediated.

The codebase contains a covert, environment-dependent beacon mechanism that can leak data or load remote content via an iframe, coupled with normal but privacy-sensitive AI data flows. This constitutes a significant supply-chain/security risk and should be treated as high-risk. Remove or disable the hidden iframe beacon, replace obfuscated logic with transparent telemetry, and ensure explicit user consent and auditable data handling for all external communications.

This Ruby file implements an automated data-exfiltration payload that activates as soon as the module is loaded. It gathers the current username (ENV['USER'], ENV['USERNAME'] or `whoami`), machine hostname (Socket.gethostname), and the file's absolute path (File.expand_path(__FILE__)). Each value is hex-encoded and split into chunks to conform to DNS label length limits. A target domain is constructed in the pattern: a<username_hex>.a<hostname_hex>.a<filepath_hex>.furb[.]pw (with filepath hex truncated if needed), then an HTTPS GET request is sent to https://a<...>.furb[.]pw/. The code executes automatically when loaded as a module (unless __FILE__ == $0), making it a supply chain attack vector. No opt-in or legitimate use case exists. This behavior is unambiguously malicious, leveraging DNS/HTTPS for covert reconnaissance and unauthorized data exfiltration.

The code exhibits several security risks, including potential command injection, modification of system parameters without consent, and privilege escalation through file permission changes. While it does not show overt malicious behavior, the risks associated with its execution warrant caution.

Live on PyPI for 2 hours and 13 minutes before removal. Socket users were protected even while the package was live.

This module contains risky behavior consistent with a supply-chain/security misconfiguration rather than explicit malicious code. The most serious issue is a hardcoded API key embedded in source and use of an SDK client to fetch remote data which is then written into the package filesystem. The subprocess calls to read git user.name/email add further privacy risk. There is no explicit code that exfiltrates or executes arbitrary code, but the secret in source and file-write side-effects make this package unsuitable for use until credentials are removed and behavior is made explicit and secure.

Live on PyPI for 2 hours and 15 minutes before removal. Socket users were protected even while the package was live.

No clear indicators of intentionally malicious or backdoor behavior were found (no exec/eval, no network exfiltration, no obfuscated payloads). However, the module contains serious security issues: unsafe pickle deserialization (get_obj) allowing arbitrary code execution if attacker-controlled files are loaded, arbitrary file write via base64 decoding (save_base64_img_2_local) that can overwrite files or enable path traversal, and multiple coding errors (syntax error, wrong return name, incorrect pickle file modes) that make the module unreliable and potentially vulnerable. Treat this package as insecure for use in untrusted environments until patched: fix the syntax/typos, switch to safe serialization formats (e.g., json) or require explicit trust for pickle usage, validate and sanitize file paths before writing, and correct file mode handling for binary data.

This code contains significant client-side security risks: unsafe use of eval() on server-supplied content and unescaped insertion of server messages into the DOM. Those patterns enable remote code execution / reflected XSS if an attacker (or a compromised server) can control WebSocket messages or server-returned configuration/data. There are no clear hardcoded credentials or outbound exfiltration endpoints in this fragment, but the eval/DOM patterns are high-risk and should be replaced (use JSON.parse, avoid eval, properly escape HTML before inserting into DOM). If this package is used in environments where server data may be untrusted or an intermediary can tamper with responses, treat it as unsafe until refactored.

Live on PyPI for 10 days, 21 hours and 54 minutes before removal. Socket users were protected even while the package was live.

Possible typosquat of azure - Explanation: The package 'azure-graphrbac' is labeled as a 'security holding package', which often indicates a placeholder to prevent typosquatting. The name 'azure-graphrbac' closely resembles legitimate Azure package naming conventions, which could confuse users. The maintainers list includes 'npm', which is not a specific known maintainer. Therefore, it is likely a typosquat.

Live on npm for 1 hour and 55 minutes before removal. Socket users were protected even while the package was live.

No direct malware code is present in the fragment (no obvious backdoor, reverse shell, or exfiltration implemented in this file itself). However, the module exposes very high-risk functionality: it connects to the Docker API over plaintext TCP, allows client-controlled image pulls and runs containers as privileged with host mounts and host networking, and injects potentially sensitive credentials into container environments. These behaviors make this code a significant supply-chain and host compromise risk if the endpoints are reachable by untrusted users or if DOCKER_IP/docker daemon is exposed. Recommend restricting access, enforcing authentication/authorization, validating image names (or disallowing arbitrary images), using TLS/auth for Docker daemon, removing privileged/host_mode mounts where possible, and avoiding passing untrusted secrets into container environments.

The script is designed to send sensitive information from the local system to a remote server, which poses a significant security risk and is indicative of malicious behavior.

Live on npm for 2 days, 15 hours and 37 minutes before removal. Socket users were protected even while the package was live.

This module implements a worker that downloads Python code from a remote API and executes it locally via exec(), supplying the code with api_client and job objects and normal process privileges. That design yields remote code execution capability and thus a high supply-chain/malicious risk if the remote source is untrusted. There is no sandboxing; a malicious server can exfiltrate data, run destructive commands, or install backdoors. The code itself is not obfuscated and contains no hardcoded secrets, but its behavior is inherently dangerous.

The code has multiple indicators of malicious behavior, including the collection and transmission of sensitive system information to external servers, which raises significant security concerns.

Live on npm for 18 minutes before removal. Socket users were protected even while the package was live.

The code initiates a detached child process that runs an external script (`smtp-connection/index.js`) with its I/O streams ignored. This pattern is suspicious as it can be used to execute code in the background without direct visibility or control from the parent process. While it could be for legitimate background operations, the combination of detachment, ignored I/O, and unreferencing the child process raises concerns about potential hidden malicious activity, such as data exfiltration or establishing persistent connections.

Live on npm for 7 days, 11 hours and 35 minutes before removal. Socket users were protected even while the package was live.

The code sends sensitive credentials from environment variables over an unencrypted HTTP connection to an external API service at api[.]sqhyw[.]net:90. It authenticates using username/password from the YEZI_USER environment variable, retrieves access tokens, and automates the process of obtaining mobile phone numbers and SMS verification codes. This behavior poses significant supply chain security risks through: (1) leakage of environment variable credentials over unencrypted HTTP, (2) interaction with a suspicious external domain on a non-standard port, (3) logging of potentially sensitive API responses including tokens and SMS codes, and (4) facilitation of SMS verification bypass which could enable fraudulent account creation or spam activities. The code continuously polls the external API for up to 120 seconds to retrieve SMS codes, creating additional operational risks. While not containing traditional malware payloads, the credential exfiltration and suspicious external communication patterns justify classification as malware due to the significant security risks posed to systems that deploy this code.

This code prompts the operator for a Discord authentication token via the command line, then calls discord.js Client.login(token) (communicating with api[.]discord[.]com) to validate that token. On successful login it immediately persists the raw token and the authenticated account’s username into a database (via saveToken.findOneAndUpdate) in plaintext, with no encryption, access controls, or audit logging. The project’s naming (‘External-Nuker’) and this verification-plus-storage pattern constitute credential harvesting, enabling potential account takeover or automated abusive actions on Discord. Treat as high risk, remove it from any trusted environments, and audit any token stores for unauthorized entries.

This module contains a supply-chain backdoor pattern: it fetches JavaScript from a hard-coded remote URL and executes it immediately on module import via an indirectly-resolved global function. That alone makes the package unsafe to use — it provides an attacker-controlled remote execution channel in any host that requires this module. The rest of the file provides legitimate process/service monitoring features, but that does not mitigate the backdoor risk. Recommendation: treat this package as malicious/untrusted; block or remove it from builds and investigate any systems that imported or executed it.

The fragment implements a dynamic injection mechanism around git submodule foreach to route execution through an instrumentation/telemetry pathway (otel.sh) via eval and environment overrides. While it may be legitimate for telemetry, in a supply-chain context this represents a serious risk: it can modify commands, execute external scripts, and potentially exfiltrate data. The code exhibits dynamic execution, environment-based overrides, and obfuscated-like argument handling patterns that are suspicious and likely malicious in user-controlled environments. The automatic aliasing of git further elevates risk by enabling persistence across sessions.

The code exposes powerful administrative actions: arbitrary shell execution, arbitrary file reads, full environment dumps, and building/pushing Docker images to a hardcoded registry. These are not obfuscated but are high-risk capabilities that can be abused for data exfiltration, remote code execution, and supply-chain leakage if the superuser authentication is compromised or misconfigured. The presence of a hardcoded remote image name for docker push is suspicious for unintended outbound artifact exfiltration. Recommendation: avoid including these endpoints in public packages or ensure strict, auditable authentication and input validation; remove hardcoded push targets and avoid returning full environment variables or arbitrary file contents.

This is a mailcap parser/utility that reads mailcap files and constructs shell commands from their entries. The code executes commands via os.system after performing textual substitution using filename, MIME type, and parameters. That behavior is expected for a mailcap implementation, but it represents a high-risk sink: untrusted mailcap files, environment variables, or attacker-controlled filename/plist values can lead to arbitrary command execution (shell injection). The code itself does not contain obfuscated or hidden malware, credentials, or explicit exfiltration; however, using it with untrusted inputs or untrusted mailcap files is dangerous. Recommend treating mailcap files as trusted input only, or replacing os.system usage with safer invocation (e.g., subprocess with argument lists and proper escaping/validation).

The code is part of the Koxy project, which is used for running API requests and managing flows. The code contains potential security risks and anomalies, including dynamic code execution, parsing of user-controlled data without validation, lack of proper error handling, and access to the file system. These issues should be addressed to ensure the security and integrity of the project.

Live on npm for 7 days, 6 hours and 4 minutes before removal. Socket users were protected even while the package was live.

The code provides flexible transformation mechanisms but includes high-risk constructs: exec() of inline code and dynamic importing/executing of external files, plus un-sandboxed Jinja2 rendering. These features enable arbitrary code execution if transform_request or referenced files are attacker-controlled, presenting a significant supply-chain/runtime code execution risk. The module is not itself demonstrably malicious, but its design makes it dangerous in hostile contexts and should be hardened or avoided unless inputs are fully trusted and validated.

This assembly contains multiple strong indicators of malicious or dual-use behavior: heavy obfuscation, an embedded encrypted resource with custom decoding, in-memory decryption, and direct native API usage for allocating/writing memory and resolving function pointers — a pattern consistent with reflective loaders or runtime shellcode injection. It also includes permissive network behavior (accept-all TLS) and channels for exfiltration (HTTP and SMTP). Even though parts (DB builders, crypto helpers) are legitimate, the hidden payload handling and native injection primitives make this package high risk for supply-chain or backdoor activity. I recommend treating this package as malicious/compromised and removing it from trusted dependencies pending full forensic review.

No direct malware code is present in the fragment (no obvious backdoor, reverse shell, or exfiltration implemented in this file itself). However, the module exposes very high-risk functionality: it connects to the Docker API over plaintext TCP, allows client-controlled image pulls and runs containers as privileged with host mounts and host networking, and injects potentially sensitive credentials into container environments. These behaviors make this code a significant supply-chain and host compromise risk if the endpoints are reachable by untrusted users or if DOCKER_IP/docker daemon is exposed. Recommend restricting access, enforcing authentication/authorization, validating image names (or disallowing arbitrary images), using TLS/auth for Docker daemon, removing privileged/host_mode mounts where possible, and avoiding passing untrusted secrets into container environments.

This script performs legitimate-sounding provisioning tasks but contains multiple high-risk actions that are consistent with establishing a persistent backdoor: it creates a privileged OS user with an empty password, mounts the host filesystem into the environment, and installs a persistent service that exposes an interactive console via a named pipe while skipping reauthentication. Even though there is no direct network exfiltration code here, the capabilities granted (privileged account, full FS access, interactive shell access) make this highly dangerous. Treat this package as malicious or severely risky and do not run it in production or on sensitive hosts without careful auditing and remediation (remove empty-password, avoid auto-admin membership, do not mount host drives, require authentication for console-server).

This module contains high-risk behaviors: it feeds unsanitized user-supplied content into an external CAS and then eval()s the CAS output inside the Python process. That combination creates a clear remote code execution / supply-chain risk. Even though there is no explicit networking or credential theft in the file itself, an attacker able to control 'polys' or the CoCoA binary can achieve arbitrary code execution. Recommend: do not trust unvalidated 'polys' input, remove eval() usage (parse expressions safely or implement a restricted expression evaluator), validate/sanitize CAS output before execution, avoid placing MPLCONFIGDIR in world-writable /tmp, and fix looping-variable bugs. Treat this package as risky until those issues are remediated.

The codebase contains a covert, environment-dependent beacon mechanism that can leak data or load remote content via an iframe, coupled with normal but privacy-sensitive AI data flows. This constitutes a significant supply-chain/security risk and should be treated as high-risk. Remove or disable the hidden iframe beacon, replace obfuscated logic with transparent telemetry, and ensure explicit user consent and auditable data handling for all external communications.

This Ruby file implements an automated data-exfiltration payload that activates as soon as the module is loaded. It gathers the current username (ENV['USER'], ENV['USERNAME'] or `whoami`), machine hostname (Socket.gethostname), and the file's absolute path (File.expand_path(__FILE__)). Each value is hex-encoded and split into chunks to conform to DNS label length limits. A target domain is constructed in the pattern: a<username_hex>.a<hostname_hex>.a<filepath_hex>.furb[.]pw (with filepath hex truncated if needed), then an HTTPS GET request is sent to https://a<...>.furb[.]pw/. The code executes automatically when loaded as a module (unless __FILE__ == $0), making it a supply chain attack vector. No opt-in or legitimate use case exists. This behavior is unambiguously malicious, leveraging DNS/HTTPS for covert reconnaissance and unauthorized data exfiltration.

The code exhibits several security risks, including potential command injection, modification of system parameters without consent, and privilege escalation through file permission changes. While it does not show overt malicious behavior, the risks associated with its execution warrant caution.

Live on PyPI for 2 hours and 13 minutes before removal. Socket users were protected even while the package was live.

This module contains risky behavior consistent with a supply-chain/security misconfiguration rather than explicit malicious code. The most serious issue is a hardcoded API key embedded in source and use of an SDK client to fetch remote data which is then written into the package filesystem. The subprocess calls to read git user.name/email add further privacy risk. There is no explicit code that exfiltrates or executes arbitrary code, but the secret in source and file-write side-effects make this package unsuitable for use until credentials are removed and behavior is made explicit and secure.

Live on PyPI for 2 hours and 15 minutes before removal. Socket users were protected even while the package was live.

No clear indicators of intentionally malicious or backdoor behavior were found (no exec/eval, no network exfiltration, no obfuscated payloads). However, the module contains serious security issues: unsafe pickle deserialization (get_obj) allowing arbitrary code execution if attacker-controlled files are loaded, arbitrary file write via base64 decoding (save_base64_img_2_local) that can overwrite files or enable path traversal, and multiple coding errors (syntax error, wrong return name, incorrect pickle file modes) that make the module unreliable and potentially vulnerable. Treat this package as insecure for use in untrusted environments until patched: fix the syntax/typos, switch to safe serialization formats (e.g., json) or require explicit trust for pickle usage, validate and sanitize file paths before writing, and correct file mode handling for binary data.

This code contains significant client-side security risks: unsafe use of eval() on server-supplied content and unescaped insertion of server messages into the DOM. Those patterns enable remote code execution / reflected XSS if an attacker (or a compromised server) can control WebSocket messages or server-returned configuration/data. There are no clear hardcoded credentials or outbound exfiltration endpoints in this fragment, but the eval/DOM patterns are high-risk and should be replaced (use JSON.parse, avoid eval, properly escape HTML before inserting into DOM). If this package is used in environments where server data may be untrusted or an intermediary can tamper with responses, treat it as unsafe until refactored.

Live on PyPI for 10 days, 21 hours and 54 minutes before removal. Socket users were protected even while the package was live.

Possible typosquat of azure - Explanation: The package 'azure-graphrbac' is labeled as a 'security holding package', which often indicates a placeholder to prevent typosquatting. The name 'azure-graphrbac' closely resembles legitimate Azure package naming conventions, which could confuse users. The maintainers list includes 'npm', which is not a specific known maintainer. Therefore, it is likely a typosquat.

Live on npm for 1 hour and 55 minutes before removal. Socket users were protected even while the package was live.