Security scans

Independent, third-party tooling run against this repository and its container image on 2026-09-14. Every finding below is listed with its severity, its file:line, and a one-line triage — true positive, false positive, accepted with reason, or to fix. Nothing here was fixed as part of this pass; fixes are listed, most severe first, in Recommended fixes at the end.

This document is a point-in-time scan result, not a certification. Re-run it before any release that changes dependencies, the Dockerfile, or the code under internal/.

Methodology note on the working tree scanned: this repository had other, unrelated work in progress in the same working directory for part of this scan window — commits landed on public-deploy during the session (HEAD moved from de52025 to 44fe0da), and a bench/ benchmarking harness had uncommitted changes throughout. None of that activity is this document's concern and none of it was touched, reverted, or waited on. The source-level tool runs (gosec, staticcheck, go vet, semgrep) reflect whatever the working tree held at the moment each command ran, which is the correct and only honest thing to scan — "the repository as it stood when the command ran" — but it means a file:line citation here should be treated as accurate as of that moment, not necessarily as of HEAD at the time you read this. Where a scan disagreed with itself about a line number across tools run at different times (see the semgrep server.go line-attribution note in §3), that is the likely explanation. Re-running any tool against the current HEAD is cheap and is how to get a citation that matches today's code exactly.

Tool versions and exact commands

Note on trivy image: trivy image abhed:local initially failed because trivy tried to pull abhed:local from Docker Hub rather than reading it from podman's local store. It was run instead against podman save abhed:local -o abhed-local.tar followed by trivy image --input abhed-local.tar, which is byte-for-byte the same image.

Scans that produce structured output were also captured as JSON (gosec.json, semgrep.json, gitleaks.json) for tooling; this document is built from those plus the plain-text logs.

1. govulncheck — known vulnerabilities in Go deps and stdlib as used

Command: env -u GOROOT go run golang.org/x/vuln/cmd/govulncheck@latest ./...

Counts:

Why govulncheck reports these at all, and why the currently-running image is likely already clean: this source-mode scan ran with the ambient local toolchain, go1.26.0 darwin/arm64 (go.mod pins go 1.26.0, and GOTOOLCHAIN=auto does not fetch a newer patch release just to satisfy that directive). Every one of the 19 "called" findings is fixed somewhere between go1.26.1 and go1.26.6, so against a go1.26.0 toolchain all 19 are real.

However, the actual abhed:local image was not built with go1.26.0. The Dockerfile's build stage uses the floating tag FROM golang:1.26-bookworm, which resolves to whatever the latest 1.26.x point release is on the day of podman build — not a version pinned in this repository. Extracting the binary from the already-built image (podman run ... cat /usr/local/bin/abhed) and inspecting its build info directly (go version -m abhed) shows it was compiled with go1.26.8, five patch releases ahead of what go.mod declares. Re-running govulncheck in -mode binary against that extracted binary confirms zero of the 19 stdlib vulnerabilities are present in the deployed artifact — only the unreachable x/crypto/openpgp advisory remains (see below). In short: the currently-running container is very likely already safe from all 19, but this is incidental to an unpinned base image tag, not a property anyone verified or can rely on for the next build. A future podman build on a day when golang:1.26-bookworm has not moved forward, or a build pinned explicitly to go1.26.0, would reintroduce all 19. This is itself the finding: the safety here is accidental and unpinned, which is worse for a security review than either "vulnerable" or "fixed" on their own — it cannot be relied upon to still be true at the next rebuild.

None of the 19 are third-party dependency bugs; they are stdlib bugs fixed upstream that go.mod's declared go 1.26.0 has not picked up, and that the Dockerfile's floating tag happens to have picked up anyway, today, by accident of when the image was last built.

19 called stdlib vulnerabilities

*Severity as reported by the Go vulnerability database's own classification where given; several (marked DoS vector above) are practically higher risk for Abhed specifically because internal/server/server.go:1448 is the public HTTPS listener.

Net assessment: none of these are code bugs in Abhed. All 19 are removed by rebuilding with a current go1.26.x point release — no source change required. Three or four (the crypto/tls/crypto/x509 DoS and chain-building issues reachable from server.Server.ListenAndServe) are worth prioritizing since they sit directly on the internet-facing listener.

10 imported-but-not-called stdlib vulnerabilities

All ten disappear with the same toolchain bump as the called findings, at no cost, so there is no reason to leave them un-fixed even though govulncheck did not find a live call path today.

5 required-but-not-called module vulnerabilities

govulncheck total: 34 distinct advisories, 0 requiring a code change, 34 resolved by explicitly pinning the Go toolchain (both Dockerfile and go.mod) to go1.26.6 or later — see the pinning note above; the currently-built image already happens to carry go1.26.8, verified by extracting /usr/local/bin/abhed from abhed:local and running env -u GOROOT go version -m abhed (reports go1.26.8) followed by env -u GOROOT go run golang.org/x/vuln/cmd/govulncheck@latest -mode binary abhed, which finds 0 of the 19 stdlib advisories in that binary — only the x/crypto/openpgp module finding remains, unchanged from the source-mode result and still not called by any Abhed code. This is a point-in-time fact about today's image, not a guarantee about the next one; see Recommended Fixes #1.

2. gosec, staticcheck, go vet

go vet

Command: env -u GOROOT go vet ./...

Result: clean. 0 findings.

staticcheck

Command: env -u GOROOT go run honnef.co/go/tools/cmd/staticcheck@latest ./...

Counts: 15 findings, all informational/style (staticcheck has no severity levels; classified here as LOW for consistency with the rest of this document).

gosec

Command: env -u GOROOT go run github.com/securego/gosec/v2/cmd/gosec@latest ./... (also captured as JSON via -fmt=json -out=gosec.json)

Counts: 138 findings.

Triage counts across all 138:

G304 — potential file inclusion via variable (23 findings)

Abhed is an agentic coding harness: the model is expected to name files to read and write, so a "variable" reaching a file-path call is the product's core function, not automatically a bug. The real question for each finding is whether the variable is model/request-controlled and, if so, whether it passed through tools.Session.Resolve (internal/tools/session.go:157) — the function that makes a model-supplied path absolute and proves it stays inside the configured workspace root(s) — or Server.resolveInWorkspace (internal/server/download.go:99), its HTTP-handler equivalent, before use.

G204 — subprocess launched with a variable (12 findings)

G104 — unchecked errors (61 findings, all LOW)

Pattern: roughly 50 of the 61 are best-effort cleanup or informational writes: deferred/explicit Close() on sockets, pipes, HTTP response bodies, and SSH sessions during teardown (internal/mcp/*.go, internal/remote/*.go, internal/model/retry.go, internal/telemetry/otlp.go, internal/ui/lineedit.go); json.NewEncoder(w).Encode(...) on already-committed HTTP responses, where a write failure only truncates what the client already started receiving (internal/auth/*.go, internal/server/*.go); bcrypt.CompareHashAndPassword called deliberately as dummy work for username-enumeration timing safety (internal/auth/local.go:182-184, intentionally discarded); and l.Recorder.Record(...) calls across internal/agent/loop.go and subagent.go where the returned error is a best-effort audit-event-append failure — a drop affects transcript completeness, not access control. Two findings are genuine, if minor, misses.

G115 — integer overflow on conversion (8 findings, all HIGH by gosec default)

G703 — path traversal via taint analysis (6 findings, all HIGH by gosec default)

G306 — WriteFile permissions looser than 0600 (6 findings, MEDIUM)

G301 — directory permissions looser than 0750 (5 findings, MEDIUM)

All five (internal/agent/parallel.go:225,255, internal/config/config.go:655, internal/eval/eval.go:139,447) create directories at 0755 for a git worktree, .git/info, a config directory, and eval output. Triage: accepted with reason for all — the directory listing being world-readable is low risk as long as the files inside are correctly permissioned, which is the G306 finding above (the one that actually matters for the config-directory case).

G118 — goroutine uses context.Background/TODO (5 findings, HIGH by gosec default)

All five are false positives: each is a deliberately detached background task with its own independent timeout, and three of the five carry an explicit comment saying so — internal/mcp/client.go:104's connection-lifetime read loop, internal/mcp/http.go:293's SSE reader ("a slow tool call [should not be] aborted when the triggering request context ends"), internal/server/admin.go:399's best-effort revocation email ("a bounced notice must not leave the account still working"), internal/server/server.go:1570's shutdown-trigger goroutine (which by definition runs after the request/server context is already done), and internal/server/settings.go:267's reindex goroutine ("client disconnecting must not abandon a half-built index").

G124 — cookie missing Secure/HttpOnly/SameSite (4 findings, MEDIUM)

G122 — filesystem op in Walk/WalkDir callback is TOCTOU-prone (2 findings, HIGH by gosec default)

internal/index/index.go:165 and internal/tools/search.go:317 both read a file mid-walk without os.Root-scoped APIs. Triage: accepted with reason for both — a TOCTOU race here requires local filesystem race access to a directory the operator (index.go) or the resolved session workspace (search.go) already controls; closing it with os.Root is a reasonable future hardening step but not urgent.

Single-instance rules

3. semgrep (--config auto)

Command: semgrep --config auto --exclude web/zybuu --exclude docs --exclude internal/docsite/site --exclude node_modules --exclude .abhed-workspace .

Counts: 27 findings — 9 ERROR, 18 WARNING (semgrep's own severity labels; "Ran 551 rules on 187 files").

Net: 27 findings, 0 exploitable, 0 true positives. Every one was checked against source, including the 4 that this triage initially flagged for follow-up verification; that follow-up is done and closes them as false positive/accepted with reason. Three of those four (server.go:1145, :1164, :1410) turned out to be a line-number attribution issue in this semgrep run: cross-checking the JSON result's own byte offsets against the current file shows they do not land on any w.Write/fmt.Fprintf call at all — offset 40821 lands mid-select statement in approveAction, offset 41702 lands in a doc comment above signOut, and offset 50797 lands in an unrelated if s.localAuth()... block. The real w.Write/fmt.Fprintf call sites in server.go are a few lines away, at 1277 (authDisabledHTML, a fixed constant), 1296 (landingHTML via the same withHome() HTML-escaping helper used by admin_page.go/console.go, already accepted above), and 1542 (writeSSE, writing an integer sequence number plus JSON-marshaled event data — JSON escaping neutralizes HTML-significant characters for this use). All three are false positives once matched to their actual code; recorded rather than silently dropped in case a different semgrep version reproduces the mismatch differently. Everything else is either a documented, deliberate design choice (the sandbox/exec findings, the SSH/TLS opt-outs) or a genuine false positive (the bcrypt/HMAC "secrets" that are test fixtures, the open-redirect findings that are already gated, and the two now-closed Fprintf/HasPrefix items above).

4. trivy

trivy image abhed:local

Command: podman save abhed:local -o abhed-local.tar && trivy image --input abhed-local.tar (see note in the tool-versions table on why the tarball route was needed)

Base image: debian:bookworm-slim (Debian 12.15) at build time, golang:1.26-bookworm build stage.

Why the OS count is large: the runtime stage installs ca-certificates, git, ripgrep, curl, python3/python3-pip, zip, unzip, graphviz, and bubblewrap (Dockerfile, documented per-package). graphviz and the pip3 install matplotlib step in particular pull in a large transitive chain of image/codec libraries (libaom3, libde265-0, libheif-adjacent packages, etc.) that a pure Go HTTP service would not otherwise need — this is the direct cause of the CVE count being much higher than the size of Abhed's own code would suggest.

8 distinct CRITICAL-severity OS packages (16 rows because perl, perl-base, and perl-modules-5.36 share one CVE):

Assessment: none of the 8 CRITICAL packages are exercised by Abhed's own code paths (video codecs, D-Bus, Perl, SQLite are all incidental to the apt/pip package set, not things cmd/abhed calls). They are real vulnerabilities in the image an attacker who achieved code execution inside the container could potentially pivot on, which is exactly the scenario the container hardening in §6 is designed to contain — but they should not be shipped if they can be trimmed. See Recommended fixes.

Python packages — the one library that matters: all 41 Python findings are in pypdf 5.1.0 (pinned in the Dockerfile), which has roughly 30 known denial-of-service CVEs (crafted PDFs causing infinite loops, unbounded memory allocation via LZW/RunLength/FlateDecode streams, malformed trailers, etc.), fixed progressively up through pypdf 6.14.2. This is not incidental baggage — internal/tools/document.go's extractPDFViaPython (document.go:264) shells out to python3 running pypdf specifically to parse PDFs the agent is given (uploaded files, per internal/server/upload.go), so a malicious PDF is a real, reachable input to this exact vulnerable library.

Go binary (usr/local/bin/abhed): 1 UNKNOWN-severity finding — golang.org/x/crypto GO-2026-5932, the same "openpgp is unmaintained" advisory already covered under govulncheck §1 above (no call path to the affected subpackage). Not double-counted as a new issue.

trivy fs --scanners vuln,secret,misconfig /Users/yuvrajsingh/titan

Result:

The one go.mod finding is golang.org/x/crypto GO-2026-5932 (UNKNOWN severity) — the same openpgp advisory as above, not a new issue.

Secret scanning found 0 secrets in the working tree. This is expected: deploy/.db-password, deploy/.db-admin-password, and deploy/.demo-secret are real, intentional secret files, but they are .gitignored and were present on disk during this scan — trivy fs scans the working tree including untracked files, so their absence from the report confirms trivy's secret detector did not flag their contents, only that they exist as files trivy chose not to pattern-match (short, high entropy but no recognizable "password:"-style key=value shape in the exact format its rules look for). Their presence as gitignored, intentional secret material is confirmed directly by listing them — contents are not reproduced here or anywhere in this document.

Misconfiguration scanning found 0 issues in the Dockerfile — consistent with the hardening choices already documented in Dockerfile's own comments (non-root user, no baked-in host paths, minimal package set relative to its job).

5. gitleaks — full git history

Command: gitleaks detect --source /Users/yuvrajsingh/titan (report saved as JSON with -v)

Result: 1 finding, across 160 commits scanned (~2.94 MB).

The expected historical secret was not what gitleaks' pattern rules caught, but it is confirmed present in history by direct commit inspection: deploy/.db-password was tracked in git until commit 0cff60f3aa82d27b614db64341f0d302dee03328 ("Delete a chat from the console, and stop connecting to Postgres as a superuser"), whose message states directly: "deploy/.db-password was tracked in git; it is untracked, ignored, and the password rotated." git log --all --full-history confirms this is the only commit touching that path, and the password has since been rotated per that commit's own message. Gitleaks' generic secret-pattern rules did not flag the historical password value itself in this run (it may not match any of gitleaks' built-in regexes for its format), but the fact and the commit are independently confirmed by history rather than by pattern-matching. Recorded here as fact and commit hash only — the value itself is not reproduced, consistent with it being rotated but still git history that should not be casually re-surfaced.

Net: gitleaks found nothing that represents a live credential today. The one pattern match is documentation prose; the one real historical secret is already rotated and confirmed by the commit trail rather than by a pattern-match hit.

6. Container posture

Commands: podman inspect abhed, podman exec abhed id, podman exec abhed cat /proc/1/status | grep -i cap

Assessment: this is a well-hardened container configuration. Non-root UID with nothing in the image owned by it, every Linux capability dropped and confirmed empty at the kernel level (not just requested), read-only rootfs, no-new-privileges, resource limits on memory/PIDs/CPU, the HTTP port bound to loopback rather than all interfaces, and both writable volumes mounted nosuid,nodev. No findings here.

7. Repo's own hardening tests

Command: env -u GOROOT go test ./internal/sandbox/ ./internal/deploycheck/ ./internal/sitecheck/ -count=1

Result: all pass. 0 failures.

These tests are notable because several of them (TestSelectRefusesToDowngrade, TestResourceLimitsRejectForkBomb, TestDeployedDenyRulesMatchRealPaths) are exactly the kind of check that would have caught some of the risk classes this scan looked for by hand — e.g. TestDeployedDenyRulesMatchRealPaths independently asserts the deployed policy denies SSH keys, cloud credentials, .env files, and the Abhed config itself. Their passing is evidence the repo tests its own security claims, not just a green CI badge.

Recommended fixes

Ordered most severe first. None of these were applied as part of this scan.

1. Pin the Go build image and go.mod's toolchain directive to an explicit go1.26.x patch release, rather than relying on a floating tag. Dockerfile's FROM golang:1.26-bookworm and go.mod's go 1.26.0 currently disagree — the floating Dockerfile tag happened to resolve to go1.26.8 on the day this image was last built (confirmed by extracting the binary and running go version -m and govulncheck -mode binary against it: 0 of the 19 stdlib vulnerabilities are present in today's image), while go.mod's pinned 1.26.0 is fully vulnerable to all 19. That is not a fix, it is luck that will not survive every future build. Change both to name the same explicit, current patch release (e.g. FROM golang:1.26.8-bookworm and go 1.26.8 in go.mod), and re-pin both together as new patches ship, so the image's safety no longer depends on which day docker/podman build happened to run. This resolves all 34 govulncheck advisories (19 actively called, including several DoS and crash vectors reachable from the public HTTPS listener in internal/server/server.go:1448 and the k8s client) at zero code-change cost, and makes the fix durable instead of incidental. Highest value, lowest effort item in this report.

1. Upgrade or replace pypdf in the Dockerfile (currently pinned at 5.1.0; ~30 known DoS CVEs, 2 HIGH, fixed progressively through 6.14.2). This library parses PDFs supplied by whoever can reach the upload endpoint or hand the agent a file — a genuinely reachable, internet-facing attack surface, not incidental image baggage. Bump the pin to a current pypdf release and re-run trivy image to confirm the CVE count drops to near zero for this package.

1. Make CookieSecure default to safe (internal/config/config.go:196, used by internal/auth/local.go:225 and internal/auth/login.go:283). The field is a plain bool that defaults to false unless an operator explicitly sets "cookie_secure": true — meaning the safe configuration is opt-in. Either default it to true and require an explicit false for local HTTP development, or have internal/deploycheck (which already asserts other security-relevant config invariants) fail the build when auth is enabled, cookie_secure is false, and the bind address is not loopback.

1. Tighten internal/agent/undo.go:122's os.WriteFile from 0644 to 0600. Undo-log snapshots capture the full content of any file the agent has touched, which can include secrets; the same repo already sets 0600 for exactly this reason in internal/auth/filestore.go:87. Verify and apply the same fix to internal/config/config.go:662 and cmd/abhed/main.go:845 if those paths can ever contain credential material.

1. Give internal/index/index.go:191's exported Index.Update(ctx, path) its own containment check rather than relying on every current and future caller to have already resolved the path through Session.Resolve. Low cost, closes a latent trust-boundary gap that gosec correctly flagged even though no current caller exploits it.

1. Low priority, verified safe but worth a defensive assertion: internal/tools/bash.go:151's Sandbox == nil fallback runs the agent's shell command directly on the host with no isolation at all when no sandbox function is configured. Traced all production wiring (cmd/abhed/main.go:188,895,1138, all three via buildSandbox at line 154, which calls fail(err) and exits on any error before tools.Bash{Sandbox: sb.Command} is ever constructed): the nil-sandbox branch is unreachable from the shipped CLI today, only reachable by a library caller outside cmd/abhed that constructs tools.Bash{} directly without setting Sandbox. Consider making tools.Bash's zero-value refuse to run rather than silently falling back to unsandboxed exec.Command, so a future integration cannot reintroduce this by omission.

1. Migrate internal/auth/oidc.go:235-236 off the deprecated ecdsa.PublicKey.X/.Y accessors (staticcheck SA1019) to PublicKey.Bytes()/ParseUncompressedPublicKey or x509.MarshalPKIXPublicKey/ParsePKIXPublicKey, per the Go 1.26 deprecation notice. This is cryptographic code; worth doing before the accessors are removed in a future Go release, not just before they start producing warnings.

1. Trim the Dockerfile's package set to reduce the OS CVE surface (currently 646 CVEs across the Debian base, including 8 distinct CRITICAL packages: libaom3, libglib2.0-0, perl/perl-base/perl-modules, libsqlite3-0, zlib1g). None of these are directly exercised by Abhed's own code, but graphviz and matplotlib (installed for document generation) pull in a large transitive chain of image/codec libraries Abhed never uses. Consider whether matplotlib's chart-generation use case can be served by a lighter plotting path, or accept the current trade-off explicitly in docs/trust/security-posture.md rather than leaving it implicit.

1. Clean up dead code flagged by staticcheck (U1000): unused functions/fields in internal/agent/compact.go:55, loop.go:502, subagent.go:28-29, internal/jsonschema/schema.go:26, internal/sandbox/process.go:23, internal/ui/lineedit.go:213, and internal/server/admin.go:60 ((*Server).isAdmin, worth a specific check that no authorization path was meant to call this and silently doesn't). No security impact from the dead code itself; housekeeping.

1. Style only, no urgency: internal/model/anthropic.go:552 (error string ends in punctuation, ST1005) and internal/server/server.go:1021 (struct-literal-instead-of-conversion, S1016).

(internal/mcp/http.go:190's SA4017 and the four semgrep raw-ResponseWriter-write findings flagged for follow-up above have since been verified by reading the source in each case and are closed as false positives — see §2 and §3 for the specifics. No fix required.)

Fixes applied — 14 September 2026

Applied the same day, in commit order after this report was written:

1. Toolchain pinned. go.mod now declares go 1.26.8 and the Dockerfile builds FROM golang:1.26.8-bookworm; the two can no longer disagree, and the 34 govulncheck advisories against 1.26.0 do not apply to what is built. Re-pin both together when the next patch ships.
2. pypdf upgraded from 5.1.0 to 6.18.1 in the image.
3. cookie_secure defaults to true (internal/config/config.go, Default()); plain-HTTP development now has to ask for the insecure setting explicitly.
4. Owner-only files: undo snapshots (internal/agent/undo.go), the written config (internal/config/config.go) and abhed init's output (cmd/abhed/main.go) are created 0600.
5. Index.Update refuses paths outside its root (internal/index/index.go), independent of what the caller resolved.
6. OIDC EC keys are parsed with ecdsa.ParseUncompressedPublicKey, which validates the point is on the curve; the deprecated X/Y construction is gone (internal/auth/oidc.go).
7. Image surface: the runtime stage applies Debian security upgrades and removes python3-pip after the document libraries are installed.

Not applied, on purpose: tools.Bash{} with no sandbox still runs on the host. That is the SDK's documented contract — the embedding program owns isolation, and the site and sdk/abhed.go say so — and a guard in internal/sitecheck keeps the two statements consistent. Changing it is a product decision about the SDK, not a scan finding.

Image rescanned after the fixes

Same tool (trivy, vuln scanner) against the image as rebuilt and deployed on 14 September 2026, now on debian:trixie-slim with the pinned Go 1.26.8 toolchain, pypdf 6.18.1 and pip removed:

What remains is the Debian base's own backlog in packages Abhed does not call (graphics and codec libraries pulled in by graphviz and matplotlib for the document tools). The next reduction is to move document generation out of the runtime image into a separate, optional one; that is on the list, not done. In-container checks after the rebuild: the document libraries import, bubblewrap 0.12 runs a command under the process tier, and abhed doctor reports the sandbox exec check as ok.