Security: bun.lock is gitignored - unpinned dependencies resolved on every install/upgrade (similar to LiteLLM malware propagation) #566

Summary

bun.lock is listed in .gitignore, which means every ./setup and every auto-upgrade resolves dependencies fresh from the npm registry using floating semver ranges. This is the same class of supply chain vulnerability that was exploited in the LiteLLM attack on March 24, 2026.

The problem

package.json declares dependencies with ^ ranges:
"diff": "^7.0.0",
"playwright": "^1.58.2",
"puppeteer-core": "^24.40.0"

Since bun.lock is gitignored, bun install (called by ./setup) resolves the latest compatible version from npm on every run. A compromised version of any dependency (or transitive dependency) within the ^ range would be silently pulled and executed.
This is compounded by the auto-upgrade flow. When auto_upgrade: true, the upgrade runs git reset --hard origin/main && ./setup, which calls bun install && bun run build — re-resolving the full dependency tree mid-session with no user confirmation.

LiteLLM parallel

Three days ago, TeamPCP compromised LiteLLM by stealing a CI/CD publish token and uploading malicious versions to PyPI. The attack harvested SSH keys, cloud credentials, Kubernetes tokens, and CI/CD secrets. LiteLLM's pipeline pulled an unpinned dependency (Trivy) which was the entry point.
The gstack install/upgrade path has the same structural vulnerability: unpinned deps in a build pipeline that executes during auto-update.

References:
https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/