obelisk-installer

Overall, this module appears to be a local GUI benchmark/automation harness rather than a typical data-stealing malware package. However, it does implement high-impact behaviors: it enables Electron remote debugging and runs Electron with `--no-sandbox`, and it uses CDP `Runtime.evaluate` to execute JavaScript in the renderer. In a hostile environment (e.g., if localhost/port were accessible to other processes/users or if expressions became user-controlled), these patterns could be abused for code execution. Given the expressions are internally generated and targeting localhost, malware probability is low, but the security risk is non-trivial due to the sandbox bypass and active renderer code execution.

This module itself does not show overt malware indicators (e.g., hardcoded secrets, exfiltration, or explicit backdoors), but it exposes two major high-risk boundaries: (1) it reads arbitrary user-supplied file contents and passes them directly into executeQuery/executeAttune (potential script/DSL interpretation or execution depending on core.ts), and (2) it provides an installer path that shells out to npx to add third-party code while forwarding user-controlled arguments. Treat this wrapper as security-sensitive and require review/hardening of core.ts implementations (executeQuery/executeAttune) and installer behavior/argument handling.

This workflow is a CI/CD publish pipeline that builds a Node.js workspace package and force-pushes staged changes into an external repository using an SSH deploy key. The snippet does not show direct malicious payload behavior (exfiltration, backdoor, or shell), but it has meaningful supply-chain risk: it executes an opaque staging script whose output becomes the published artifact, uses git push --force (high blast radius), and disables SSH host key checking (weakened transport authenticity). A compromise of build dependencies or the staging script could propagate tampered content into the published plugin repository.

No direct malicious code indicators are visible in this workflow fragment. However, it introduces meaningful security and supply-chain risk by disabling SSH host key verification and using git push --force to update an external repository’s main branch, while executing an unseen staging script that controls the published contents. Review and lock down packaging/stage-skill-repo.sh and tighten SSH/commit/publish controls to reduce blast radius and prevent tampered artifacts from being published.