Agions fixed taskflow-ai security issues 48 hours after we flagged them

What we found

On April 20, 2026 our monitor scanned taskflow-ai@3.0.1. The package is a feature-rich AI task-management CLI published to npm by maintainer Agions. The scan returned score 45 of 100, risk level HIGH, with four findings:

• HIGH install_script: postinstall ran node -e "console.log(...)", which routes through the shell and carries an interpretation surface even for a cosmetic banner.
• HIGH command_injection: a shell_exec tool called with a template literal argument, one of the classic shell-injection patterns.
• MEDIUM excessive_dependencies: 31 runtime dependencies, large attack surface.
• LOW no_provenance: not published with npm provenance attestations.

We opened Agions/taskflow-ai#6 with the scan report, the specific source locations, and recommended fixes.

What Agions did

“We have addressed the following issues in version 3.0.2. postinstall script: changed from node -e "console.log(...)" to simple echo command. This eliminates the potential for any shell interpretation during install. command injection: added command validation to shell_exec tool in built-in.ts. Now uses the same validateCommand security validator as our other shell execution tools. The validator checks against dangerous patterns and maintains a whitelist of allowed commands.”

taskflow-ai@3.0.2 went live on npm the same day. Our watch cron picked up the publish within minutes. On the rescan, the install_script finding correctly dropped from HIGH to LOW (plain echo has no interpretation surface). Score moved 45 to 60. Issue closed.

What the score did not change, and why it is still useful

The command_injection finding still flags HIGH on 3.0.2. That is not a bug in Agions' fix — the scanner correctly detected a separate unguarded shell-exec in the marketplace installer that Agions' shell_exec patch did not touch. The fix was real and material; the package just has another pattern of the same class in a different file. A useful trust tool tells the truth even when it is awkward.

Our scanner v2.1 (shipped April 22) adds context-aware severity downgrade: if a known sanitizer wrapper like validateCommand is detected near a flagged call, the finding is downgraded. In Agions' case the wrapper is in shell.js, the remaining flagged call is indownloader.js — different scope, no downgrade. If the next release brings validateCommand coverage to the installer too, the score will catch up automatically.

What this pattern demonstrates

Redis (see case study) closed their exposure by pinning MCP dependencies. Agions closed theirs by writing fixes. Two different postures, same ecosystem hygiene result: a package that was HIGH is now ELEVATED, and the path to LOW is clear and documented. Both cases happened because a regex scanner, a monitoring feed, and a willingness to open the issue did the work that no one was being paid to do.

The AgentScore Policy Gate makes this loop run automatically for any repo that installs MCP dependencies. Version bumps become deliberate decisions. Score drops block merge until someone looks. Capability changes surface before they ship.