Skip to content

A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393

Open
Open
A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target#393
Labels
agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:goGo modulespriority:p2

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Sep 30, 2026

[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).

Summary

In Go workspace mode, a replace in go.work overrides any replace for the same module in a member's go.mod. When the workspace already has a user-authored replace example.com/upstream [v1.0.0] => ../fork in go.work, both agent-mode apply and vendored-mode vendor still write their replace into the root go.mod and report the package patched. That replace is inert: go build links ../fork. apply --check then says "in sync", and vex attests not_affected (with the (vendored) marker in vendored mode).

The same user replace in go.mod is correctly refused ("go.mod already has a user-authored replace example.com/upstream v1.0.0 => ../fork; refusing to overwrite"), and crates/socket-patch-core/src/vex/discover/golang.rs:65-72 notes that "go.work replaces override go.mod replaces in Go", leaving cross-file precedence to the CLI's wiring_conflict gate. That gate never fires for a user (non-Socket) go.work replace.

Impact

The patched bytes aren't in the build, yet every signal (apply exit 0, the apply --check CI gate, and OpenVEX not_affected) says the CVE is mitigated. Committed go.work files with local-fork replaces are common in monorepos.

Repro (Linux, go 1.24.7, hermetic file GOPROXY, GOFLAGS unset because workspace mode rejects -mod=mod)

The fixture has the same shape as tests/e2e_golang_build.rs: example.com/upstream@v1.0.0 is "PRISTINE", and a hand-staged manifest plus blob patch it to "PATCHED", with setup.manual: ["golang"]. ../fork is a local module example.com/upstream returning "FORK".

export GOPROXY=file://$T/proxy GOMODCACHE=$T/modcache GOSUMDB=off GOTOOLCHAIN=local GOFLAGS=
cd consumer                    # go.mod: require example.com/upstream v1.0.0
printf 'go 1.21\n\nuse .\n\nreplace example.com/upstream v1.0.0 => ../fork\n' > go.work
go run .                       # OUT: FORK
socket-patch apply             # exit 0: "pkg:golang/example.com/upstream@v1.0.0 (via blob)" applied
grep replace go.mod            # replace example.com/upstream v1.0.0 => ./.socket/go-patches/example.com/upstream@v1.0.0
go run .                       # OUT: FORK   <- patch not linked
socket-patch apply --check     # exit 0: "Patch redirects are in sync (1 redirect checked)."
socket-patch vex --output v.json   # exit 0: "status": "not_affected"

This reproduced in 3 fresh fixtures on main:

  • a versioned go.work replace (M v1.0.0 => ../fork), agent apply;
  • a version-less go.work replace (M => ../fork), agent apply;
  • a versioned go.work replace with socket-patch vendor (vendored mode). There, vendor exit 0 writes replace … => ./.socket/vendor/golang/<uuid>/…, the build prints FORK, and vex exit 0 gives not_affected (vendored).

For contrast, the same line in go.mod makes apply fail with user-authored replace … refusing to overwrite (exit 1).

Expected vs actual

  • Expected: The user-authored-replace refusal that go.mod gets should also cover go.work, because that is where Go resolves the replace in workspace mode. Failing that, apply, vendor and apply --check should report the redirect as overridden, and vex should omit the patch. README (vex, step 2) says the attestation "only covers patches that are actually applied"; README line 1307 lists go.work among the golang files socket-patch reads.
  • Actual: exit 0 everywhere, not_affected, and the build links the fork.

OS × version

OS go mode go.work replace form reproduces
Linux 1.24.7 agent apply M v1.0.0 => ../fork yes
Linux 1.24.7 agent apply M => ../fork yes
Linux 1.24.7 vendored vendor M v1.0.0 => ../fork yes
Linux 1.24.7 agent apply same line in go.mod instead no (correctly refused)

This is go.mod/go.work text logic, so it doesn't depend on the OS; go.work exists since Go 1.18. Main is f6b7fb9. Hosted mode wasn't exercised (it needs the patch API, which the sandbox blocks).

Suspect code

  • crates/socket-patch-core/src/vendor/go_mod_edit.rs:173 ensure_replace_entry: the user-authored-replace refusal only reads go.mod.
  • crates/socket-patch-core/src/patch/redirect/golang_local.rs:468 verify_go_redirect_state and crates/socket-patch-cli/src/commands/vex.rs:1333 synthesize_go_patches: neither consults go.work replaces.
  • crates/socket-patch-core/src/vex/discover/golang.rs:65-72 defers go.work-over-go.mod precedence to the CLI wiring_conflict gate, which doesn't cover a non-Socket go.work replace.

Related: #392 (an inert replace from a build-graph mismatch), #391 (vex doesn't check the replace version).

Backlog review — 2026-10-08

Priority: P2 → P1. A go.work replacement makes the build use unpatched code while VEX attests the Socket replacement. Supported workspace resolution must be respected.

Activity

  1. Mikola Lysenko (mikolalysenko)
    added
    bugSomething isn't working
    bughuntFound by a scheduled package-manager bug-hunt agent
    pm:goGo modules
    agent:triaged
    priority:p2
    on Sep 30, 2026

  2. mikolalysenko commented on Sep 30, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Sep 30, 2026
    CollaboratorAuthor

    [agent] Triaged as priority:p2 (Go). Related to #391/#392 (Socket's go.mod replace isn't the one the build uses), but this covers vendored mode and a user go.work replace, which the wiring_conflict gate ignores; not clustered until the fix for #391/#392 shows whether a go list -m effective-replace check covers it.

    Generated by Claude Code

  3. mikolalysenko commented on Oct 1, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 1, 2026
    CollaboratorAuthor

    [agent] Re-triage on main 2463257 (v5 consolidation, #277): still reproduces. The setup is a go.work with use . and replace example.com/upstream v1.0.0 => ../fork. Agent apply exits 0, go run . prints FORK, apply --check says "in sync", and vex gives not_affected.

    Generated by Claude Code

  4. mikolalysenko commented on Oct 1, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 1, 2026
    CollaboratorAuthor

    [agent] Shares root cause with #458: the agent-mode Go redirect (patch/redirect/golang_local.rs) never reads go.work, so a go.work replace (here) or a go.work that doesn't use the root (#458) makes Socket's root go.mod replace inert while apply, apply --check and VEX still report it patched. Will be fixed together.

    Generated by Claude Code

  5. mikolalysenko commented on Oct 1, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 1, 2026
    CollaboratorAuthor

    [agent] New information: hosted mode is affected too. Reproduced 2× on main 61cfb9b (Linux, go 1.24.7), with both the versioned (M v1.0.0 => ../fork) and the version-less (M => ../fork) go.work replace.

    The fixture is the shape of e2e_golang_hosted_build.rs (get <uuid> --mode hosted against a local mock of view/<uuid> + /patches/package with a goproxy override). go.work is use . plus replace example.com/upstream => ../fork.

    go run .                                             # OUT: FORK
socket-patch get $UUID --mode hosted --yes --json …  # exit 0, "redirected": 1, "warnings": []
grep replace go.mod                                  # replace example.com/upstream v1.0.0 => patch.socket.dev/gopatch/<uuid> v1.0.0-socketpatch.1
go run .                                             # OUT: FORK   (also FORK on a fresh day-2 machine)
socket-patch vex … --product pkg:golang/example.com/consumer   # exit 0, "status": "not_affected" (redirected)

    The hosted rewriter refuses a user-authored replace in go.mod ("User-authored conflicting replacements are preserved and the patch is refused", docs/ecosystems.md). It doesn't look at go.work, though, where the user's replace wins.

    Also re-checked on 61cfb9b: the agent apply variant still reproduces (apply 0, build FORK, --check 0, vex not_affected).

    Generated by Claude Code

  6. mikolalysenko commented on Oct 2, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 2, 2026
    CollaboratorAuthor

    [agent] Shares root cause with #458, #531: the Go redirect never reads the enclosing go.work. #531 adds a third symptom: applying in a second workspace member writes a conflicting per-member replace, which breaks the workspace build. Will be fixed together.

    Generated by Claude Code

  7. mikolalysenko commented on Oct 2, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 2, 2026
    CollaboratorAuthor

    [agent] New variant from the Go modules bug-hunt routine (ledger #317), on main 61cfb9b, go 1.24.7, agent mode.

    The same override happens when the workspace file lives outside the project and is selected with GOWORK=<path>. socket-patch never reads GOWORK, so even the go.work-aware VEX discovery can't see it:

    # consumer at $C patched with `socket-patch apply` (go.mod replace => ./.socket/go-patches/...)
printf 'go 1.21\n\nuse %s\n\nreplace example.com/upstream v1.0.0 => %s\n' $C /some/other/upstream > $W/ws/go.work
GOWORK=$W/ws/go.work go run .                       # OUT: PRISTINE
GOWORK=$W/ws/go.work socket-patch apply --check     # exit 0, "in sync"
GOWORK=$W/ws/go.work socket-patch vex --product …   # status not_affected

    Without the user replace in the external go.work, GOWORK=<path> builds PATCHED (pass). GOWORK=off with a root go.work that doesn't use . also builds PATCHED, and apply and --check pass.

    Generated by Claude Code

  8. mikolalysenko commented on Oct 3, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 3, 2026
    CollaboratorAuthor

    [agent] Re-triage from the Go modules bug-hunt routine (ledger #317): this still reproduces on main 045d7ec in agent mode, and it now also reproduces on go 1.21.13 and 1.26.8 as well as 1.24.7. With replace example.com/upstream v1.0.0 => ../fork in go.work, apply exits 0, the build prints FORK, apply --check exits 0, and vex writes not_affected.

    Generated by Claude Code

  9. Mikola Lysenko (mikolalysenko)
    added
    priority:p1
    priority:p2
    and removed
    priority:p2
    priority:p1
    on Oct 8, 2026

  10. mikolalysenko commented on Oct 9, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 9, 2026
    CollaboratorAuthor

    v5 triage: P2, not a release blocker. Retain Go workspace override handling at P2; resolve it as source-selection work after the basic release path.

    This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:goGo modulespriority:p2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions