openresearch-cli

The fragment is a purpose-specific macOS browser-cookie importer. It accesses and decrypts session credentials, which is inherently high-impact, but it does not send them externally, install persistence, execute attacker-controlled commands, or contain obfuscation. The main risks are exposure of temporary database copies and reliance on higher-level authorization for the host argument. No clear malicious behavior is present in this fragment.

This is recognizable release automation, not evidence of intentional malware. However, direct shell interpolation of the user-controlled release tag creates a command-injection risk in a workflow with release permissions. Restrict dispatch access and pass the tag through a safely quoted environment variable or validated argument.

No clear evidence of classic malware (exfiltration, persistence, shells, or direct credential theft) exists in this module. However, it contains a deliberately implemented dynamic execution feature: it extracts an expression from model-generated tokens and runs it through Python eval() using heuristic filters rather than a robust sandbox/AST whitelist, then injects the result into the generated output. This creates a significant security risk (unexpected execution and/or DoS), even if the intent is “calculator arithmetic.” Refactoring to remove eval() (or to implement a strict arithmetic parser/AST evaluator) is strongly recommended.

No explicit evidence of intentional malware (no direct exec/eval, credential theft, exfiltration, or shell behavior) is present in the shown fragment. However, the downloader function provides a high-impact supply-chain capability: it fetches arbitrary remote content from a caller-provided URL and writes it to disk using an unsanitized caller-provided filename (path traversal risk), and then optionally calls a caller-provided postprocess_fn on the downloaded file path (which could enable downstream execution depending on usage elsewhere). Separately, the fragment appears syntactically incomplete, reducing confidence that no additional behavior exists beyond this excerpt.

No overt backdoor, credential theft, or network exfiltration behavior is visible in this module. However, it contains high-impact supply-chain/host-compromise risk due to unsafe deserialization: it uses pickle.load() to load tokenizer.pkl and torch.load() to load token_bytes.pt without integrity/provenance validation. If an attacker can tamper with these artifacts (e.g., via artifact compromise or writable base_dir), arbitrary code execution is plausible. Tokenization/prompt-shaping from caller-controlled conversation data is also present but is not itself code execution within this snippet.

No direct evidence of intentional malware (no subprocess execution, no credential theft, no outbound exfiltration beyond downloading the evaluation bundle). The main supply-chain/security risks are (1) unpacking a remotely downloaded zip using extractall without explicit path sanitization safeguards, (2) lack of integrity/signature verification for the downloaded artifact, and (3) using untrusted bundle configuration (dataset_uri/task definitions) to select files to read and drive evaluation. These are primarily integrity/abuse-of-filesystem risks typical for untrusted artifact handling in supply chains, rather than clear malicious payload behavior in this module.

The fragment is a readable implementation of an intentionally local run-observability daemon and shows no clear malicious behavior. It exposes potentially sensitive run data to unauthenticated local clients and should rely on strict validation inside log_path; otherwise the client-controlled run ID could enable path traversal. The hand-rolled HTTP parser and unlimited SSE connections also create moderate availability and robustness risks.

No strong evidence in this module of classic package malware, but the component significantly increases client-side active-content risk: it injects caller-provided HTML into a sandboxed iframe while explicitly enabling allow-scripts, and it may inline remote JavaScript referenced by script[src] as data: URLs based on content-type/size checks. Since the snippet’s withScheme logic is corrupted/incomplete and HTML sanitization is not shown, the security posture depends heavily on unverified URL-scheme hardening and on how resolveSrc and html are controlled/sanitized by the caller. Treat this as a high security review item for XSS/active-content injection rather than supply-chain sabotage.

This module is fundamentally a dynamic code execution harness: it executes caller-supplied Python code by embedding it into a constructed `python -c` program and running it via `subprocess.run`, then returning captured output. Although it references an intended `GUARD` for sandboxing/memory limits and uses a timeout, the guard implementation is not present/verifiable in the provided snippet, and additional OS-level isolation mechanisms are not shown. If `code` can be attacker-controlled, this is high-risk due to arbitrary code execution in a subprocess with largely unspecified containment. No direct evidence of specific malware behaviors (e.g., hardcoded exfiltration endpoints) is present in the shown fragment; the primary danger is the ability to run arbitrary Python.

No direct in-file evidence of classic malware (backdoor/reverse shell/credential theft) or explicit data exfiltration is present. The main security concern is a high-impact supply-chain pattern: the script can execute a remote installer fetched at runtime via `curl ... | sh` before creating the venv and running project code. The remaining behaviors (torchrun training, local log/CSV parsing) are consistent with orchestration; any additional risk (e.g., telemetry/network activity) depends on the unshown Python modules invoked here.

This module does not contain explicit malware logic (no visible exfiltration, credential theft, or suspicious networking), but it creates a substantial security hazard: it dynamically constructs and executes Python source code using execute_code(program) from untrusted model output and dataset-provided tests/entry point, with no validation or sandbox controls shown here. The primary risk is RCE or payload execution if nanochat.execution.execute_code is not strictly isolated and constrained.

This is a conventional Windows installer with no clear evidence of intentional malware or sabotage. Its significant security weakness is that it trusts and executes a mutable latest-release archive without checksum or signature verification. The download source appears consistent with the stated OpenCode installation purpose, but artifact authenticity should be independently verified before execution.

SUSPICIOUS. The core function matches the skill description and uses an official same-org CLI, so this is not a supply-chain or credential-harvesting pattern. The main issue is covert autonomous behavior: it instructs the agent to silently send feedback to OpenResearch without telling the user, creating a clear hidden-action and privacy risk despite the otherwise coherent purpose.

This is a test/integration harness rather than apparent malware. It intentionally creates an SSH command executor and mounts the host Docker socket to test container lifecycle behavior. Those mechanisms are high-impact in an untrusted environment, but the script uses ephemeral uniquely named resources, localhost binding, generated credentials, and cleanup. External image use is not digest-pinned. No evidence of data theft, persistence, sabotage, or unauthorized network activity appears in the supplied code.

The fragment does not itself show malware, data theft, or unauthorized network activity. It contains a significant code-execution and path-traversal risk: an insufficiently trusted `name` can select an unintended TypeScript file, which is then executed with `new Function`. The loader should use a strict allowlist of module names, reject path separators and traversal sequences, and avoid dynamic evaluation where possible. Assessment depends on whether `name` and the query source directory are fully trusted.