MOB-53673: CVE fixes + Ruby 3.4.10 (replaces gem appeasement with real fixes) - 2026-09-03 - #2024
Merged
Merged
Conversation
Auto-fixed by prisma-taurus skill. CVEs fixed: CVE-2026-18938, CVE-2026-13757, CVE-2026-54371, CVE-2025-5278 These three packages ship in the ubuntu:24.04 base image at exactly the flagged versions and are not reinstalled by any earlier apt-get install, so no rebuild picks up their fixes -- an explicit --only-upgrade entry is the only mechanism. Fixes were published in noble-updates before the scanned image's build start, confirming they were available but not landing. Also repairs two long-dead entries in the same block that apt was skipping silently after Ubuntu's 64-bit-time_t renames, so the gnutls and pipewire CVE lists those comments claim to enforce are now actually enforced: libgnutls30 -> libgnutls30t64 libpipewire-0.3-0 -> libpipewire-0.3-0t64 Marks the erb/json gem entries as appeasement rather than fixes: both are pure default gems, so the gemspec purge de-registers the gem and the vulnerable stdlib copy still loads (ERB.version 4.0.4, JSON::VERSION 2.9.1 in the published image). Comment-only here; the revert needs its own PR. Records in vulnerability_history.md: the pure-default-gem appeasement trap, the base-image-vs-unpinned OS provenance rule, the silent-skip/t64 dead-entry trap, why unpinned entries must not be pruned, and the stale-image caveat for tag-based Prisma scans. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Comment-only; the package list and build behaviour are unchanged, so the image verified by taurus-branch-builder #590 still applies. - The "unpinned installs don't need an entry" note contradicted the block itself, which does list such packages (wget, python3.12, libnss3). Explain the real distinction: those entries are no-ops in the --no-cache master build but load-bearing in a layer-cached branch build, so they stay. - Reference vulnerability_history.md by its full repo path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The previous recipe installed a patched gem then deleted specifications/default/<gem>-<old>.gemspec. That silenced Prisma but also de-registered the feature, so `require` fell back to Ruby's stdlib copy and the VULNERABLE code kept loading. Measured in the published image: ERB.version 4.0.4 and JSON::VERSION 2.9.1, despite erb 4.0.4.1 and json 2.19.9 being installed. Appeasement, not a fix. Ruby 3.4.9 -> 3.4.10 ships patched net-imap (0.5.15) and erb (4.0.4.1) as its own bundled/default gems, so both force-installs and the entire purge + find-assert block are deleted. json 2.19.9 and resolv 0.7.2 are still installed, but without purging the default gemspec -- keeping it is what lets RubyGems activate the newer gem. Verified on stock ruby:3.4.10 that JSON::VERSION becomes 2.19.9 and resolv resolves to 0.7.2 this way. The assertion now checks runtime activation via Gem.loaded_specs rather than absence of old files; the old check passed while vulnerable code was loading. Accepted: Prisma still reports json 2.9.1 / resolv 0.7.1 from the stale default gemspec while the loaded code is patched. Those findings are left visible rather than silenced, and clear for real once Ruby bundles the patched versions. CVEs genuinely fixed by this change: CVE-2026-41316 (erb), CVE-2026-54696 (json), CVE-2026-80212 and CVE-2026-80213 (resolv). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
mykhaliev1
approved these changes
Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira: MOB-53673
Supersedes #2023 (same 4 OS fixes, plus the Ruby work below).
What this does
1. OS package upgrades — 4 CVEs fixed (unchanged from #2023, verified gone in the branch scan):
libattr11:2.5.2-1build1.1→1:2.5.2-1ubuntu0.1libp11-kit00.25.3-4ubuntu2.1→…2.2libp11-kit00.25.3-4ubuntu2.1→…2.2coreutils9.4-3ubuntu6.2→…6.3These ship in
ubuntu:24.04at exactly the flagged versions and are never reinstalled by the Dockerfile, so only an explicit--only-upgradepicks up their fixes.2. Two silently dead
--only-upgradeentries fixed. Ubuntu's 64-bit-time_trename leftlibgnutls30andlibpipewire-0.3-0matching nothing, and--only-upgradeskips unknown names without erroring — so those CVE lists were never enforced. Nowlibgnutls30t64/libpipewire-0.3-0t64. All 33 entries verified to resolve.3. Ruby 3.4.9 → 3.4.10, and the gem hack replaced.
The previous recipe installed a patched gem then deleted
specifications/default/<gem>-<old>.gemspec. That silenced Prisma but also de-registered the feature, sorequirefell back to Ruby's stdlib copy and the vulnerable code kept loading. Measured in the published image:Fixed properly:
net-imap0.5.15 anderb4.0.4.1 natively → both force-installs and the whole purge/assert block deleted. Genuinely fixes erb (CVE-2026-41316) and keeps net-imap's 8 CVEs (2 critical) fixed without a hack.json2.19.9 +resolv0.7.2 installed without purging. Keeping the gemspec is what lets RubyGems activate the newer gem — verified on stockruby:3.4.10:JSON::VERSION 2.19.9,resolv spec 0.7.2. Real fixes for CVE-2026-54696 and CVE-2026-80212/80213.Gem.loaded_specs) instead of file absence — the old assert passed while vulnerable code loaded. Verified it aborts correctly when a gem isn't patched.Accepted trade-off
Prisma still reports
json 2.9.1/resolv 0.7.1from the stale default gemspec even though the loaded code is patched. These findings are intentionally visible rather than silenced — deleting the gemspec is the bug above. They clear for real when Ruby bundles the patched versions, or via a Prisma suppression. So this branch's raw count sits slightly above #2023 while being materially more secure.Verification
taurus-branch-builder#591 — integration passed, and the new build-time assertion confirms the patched code actually loads in the real image:Unit tests: 1320 pass, 0 errors.
Scan, keyed on
(CVE, package, version)— baseline 311 → 308 (crit 4→4, high 55→55):resolv0.6.2 ×2json 2.9.1×1 andresolv 0.7.1×2 — the stale-gemspec rows described aboveerbCVE-2026-41316 and net-imap's 8 CVEs appear in neither list: fixed by Ruby 3.4.10 itself, so genuinely fixed and not reportedDeferred (unchanged)
@faker-js/faker(high 7.8 — exact upstream pin, ESM-only, deleted APIs),file-type,diff(needs mocha 11→12),setuptools(≥82 dropspkg_resources). All 4 criticals are monitor-only JMeter-bundled Tika.🤖 Generated with Claude Code