[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).

Summary

The hosted gem stale-install guard (CLI_CONTRACT.md, "Gem stale-install guard") looks for the committed bundle cache archive only at <cwd>/vendor/cache/<name>-<version>.gem. Bundler's cache directory is configurable: bundle config set --local cache_path vendor/gems writes BUNDLE_CACHE_PATH into the committed .bundle/config, and BUNDLE_CACHE_PATH can also come from the environment. When a project commits its cache at that configured path:

• scan --mode hosted emits no redirect_gem_stale_install warning.
• The stale purl is therefore not added to stale_purls, so the same run's --vex attests not_affected … (redirected).
• A fresh checkout's bundle install installs from the stale cached .gem:
  • Bundler 2.4.22 does this silently: exit 0, unpatched bytes.
  • Bundler 2.6.9 and 4.0.17 exit 37 ("mismatched checksums"), and the scan has given no remedy.

Impact

On Bundler ≤ 2.5, the vulnerable upstream code is installed and runs, while the scan reported a successful redirect and its VEX says not_affected. On newer bundlers every fresh install fails, and nothing points at the cause. The folded flavor has the same gap: when there's a stale installed dir, the delete-list remedy leaves the configured cache archive behind, which reinstates the stale bytes.

Repro

This uses the hermetic fixture from e2e_redirect_gem_build.rs (mock upstream + patch registry + API), which I kept running so I could drive the steps by hand.

mkdir proj && cd proj
bundle config set --local path vendor/bundle
bundle config set --local cache_path vendor/gems        # committed in .bundle/config
printf 'source "%s/upstream"\n\ngem "vuln-gem"\n' "$MOCK" > Gemfile
bundle install && bundle cache                          # vendor/gems/vuln-gem-1.0.0.gem (upstream bytes)
# fresh checkout: Gemfile, Gemfile.lock, .bundle/config, vendor/gems/ only
socket-patch scan --mode hosted --json --yes --cwd "$PWD" --api-url "$MOCK" \
  --org test-org --api-token fake --vex out.vex.json --vex-product pkg:gem/[email protected]
#   exit 0; redirect.warnings has no redirect_gem_stale_install
#   out.vex.json: GHSA-… not_affected "Patched via Socket patch <uuid> (redirected)"
bundle install    # (another fresh copy of the committed files)
#   Bundler 2.4.22: "Bundle complete!" exit 0; vendor/bundle/.../vuln-gem-1.0.0/lib/vuln_gem.rb == UPSTREAM bytes
#   Bundler 2.6.9 / 4.0.17: exit 37 "Bundler found mismatched checksums"

Control: the same steps with the default vendor/cache produce the documented redirect_gem_stale_install ("the project's committed bundler cache still holds an UNPATCHED archive at …/vendor/cache/vuln-gem-1.0.0.gem"), and the in-run VEX withholds the attestation.

Expected vs actual

• Expected (CLI_CONTRACT.md "Gem stale-install guard"): "a committed vendor/cache archive whose sha256 differs from the patched artifact's warns standalone even with no installed dir at all", and "A stale-flagged purl is additionally excluded from the same run's --vex assume_applied set — the envelope must never attest a CVE its own warning says is live." The archive bundler actually installs from is the one at its configured cache path (Bundler.app_cache = settings.app_cache_path, which defaults to vendor/cache). The guard should resolve that path from BUNDLE_CACHE_PATH in .bundle/config or the environment.
• Actual: the guard is silent, the VEX attests, and the unpatched gem is installed.

Matrix (Linux, Ruby 3.3.6, main 6e7ef74; fresh checkout with the committed cache, no installed dir)

I reproduced each failing cell at least twice. The path logic doesn't depend on the OS, so macOS and Windows weren't probed.

Suspect code

• crates/socket-patch-cli/src/commands/scan/hosted.rs:422: the folded flavor, cwd.join("vendor").join("cache").
• crates/socket-patch-cli/src/commands/scan/hosted.rs:471: the standalone flavor (pass 3), with the same hard-coded path.

No probe runs.