MOB-53673: CVE fixes - 2026-09-03

[RafaelGuevaraCA]

Jira: MOB-53673

Fixable in taurus, this run: 10 detected → 4 fixed.

Distinct CVEs. Counts only this repo's own Dockerfile changes, each confirmed gone in the branch image scan.

Fixed

CVE	Severity	Package	Old → New
CVE-2026-54371	medium 7.1	libattr1 (attr)	1:2.5.2-1build1.1 → 1:2.5.2-1ubuntu0.1
CVE-2026-18938	medium 6.2	libp11-kit0 (p11-kit)	0.25.3-4ubuntu2.1 → 0.25.3-4ubuntu2.2
CVE-2026-13757	medium 6.2	libp11-kit0 (p11-kit)	0.25.3-4ubuntu2.1 → 0.25.3-4ubuntu2.2
CVE-2025-5278	low 4.4	coreutils	9.4-3ubuntu6.2 → 9.4-3ubuntu6.3

Why these needed a code change (they are not rebuild-clearable)

All three ship in the ubuntu:24.04 base image at exactly the flagged versions, and the image's own /var/log/apt/history.log shows no taurus apt-get install touching them — the only hits are dated 2026-08-10, which is Canonical's rootfs build baked into the base image. An unpinned apt-get install does not upgrade an already-installed base package, so no rebuild would ever have picked these up; an explicit --only-upgrade entry is the only mechanism.

Their fixes were published in noble-updates on 2026-08-27 / 08-31, i.e. before the scanned image's build start (2026-09-03 06:22:52Z) — so the fix existed and simply was not landing. Verified reachable inside the scanned image before building:

libp11-kit0  Installed: 0.25.3-4ubuntu2.1   Candidate: 0.25.3-4ubuntu2.2
libattr1     Installed: 1:2.5.2-1build1.1   Candidate: 1:2.5.2-1ubuntu0.1
coreutils    Installed: 9.4-3ubuntu6.2      Candidate: 9.4-3ubuntu6.3

apt-get install --only-upgrade --dry-run reported 3 upgraded, 0 newly installed, 0 to remove.

Also fixed: two silently dead entries in the same block

Ubuntu's 64-bit-time_t transition renamed these binaries, and --only-upgrade skips names it cannot resolve without erroring, so both entries had been no-ops and the CVE lists their comments claim to enforce were not actually enforced:

Was	Now	apt-cache policy for the old name
libgnutls30	libgnutls30t64	Installed: (none) / Candidate: (none)
libpipewire-0.3-0	libpipewire-0.3-0t64	Installed: (none) / Candidate: (none)

Both are no-ops today (the packages are already pocket-current), so this changes no CVE count now — it restores forward protection for the next gnutls/pipewire security update. All 33 entries in the block now resolve; swept the full list to confirm.

Note this class of bug is invisible to both the build and the scan: apt-get exits 0 either way, and a dead entry looks identical to a working one whenever the package is already current.

Fixable but did NOT land (6, deferred for cause)

CVE	Severity	Package	Why
CVE-2026-73231	high 7.8	@faker-js/faker 5.5.3	postman-collection pins faker at an exact 5.5.3 (its latest, 5.3.1, still does); faker 10.5.0 is ESM-only while postman-collection is CommonJS, so require() would fail; and it calls APIs deleted in v8–v10 (address.*, company.bs*, datatype.number/uuid) that drive Postman dynamic variables. An override breaks Newman at runtime, not just at install.
CVE-2022-36313	medium 5.5	file-type 3.9.0	Same exact-pin situation upstream; fix is a 3 → 16 ESM rewrite. Standing deferral.
CVE-2026-24001	low 2.7	diff 7.0.0	Now reachable only via a mocha 11 → 12 major bump (mocha 12 declares diff: ^9). That changes the runner customers' Mocha/Selenium scenarios execute and touches bzt/modules/javascript.py (codecov exposure) for one CVSS-2.7 low.
CVE-2026-80212, CVE-2026-80213	low 0 (×2)	resolv 0.6.2	See below — the only scan-clearing mechanism would be appeasement that reverts the runtime to vulnerable code. Ruby 3.4.10 ships resolv 0.7.1, short of the 0.7.2 fix.
CVE-2026-59890	low 0	setuptools 80.10.2	Fix is 83.0.0; setuptools ≥82 removed pkg_resources, which setup.py imports in a no-isolation build. Standing deferral.

Not actionable in this repo

301 findings — monitor-only JMeter/Gatling bundled jars, k6 binary internals, Ubuntu Pro ESM, distro pip, and no-released-patch (open/needed/deferred). All 4 criticals are monitor-only JMeter-bundled Apache Tika 1.28.3 (CVE-2025-66516, CVE-2025-54988 in jmeter-taurus/5.5/lib) — verified, not assumed. No scanner-appeasement/.deps.json findings appeared in this scan, so there are no manual-intervention items this run.

Verification

Verified against the taurus-branch-builder image scan (build #590) before opening — integration passed. Diffing the branch scan against the baseline keyed on (CVE, package, version):

• Gone: exactly 4 — the four fixed above
• New: 0

	Baseline (scan #222)	Branch (#590)
Findings	311	307
Distinct CVEs	286	282
critical / high	4 / 55	4 / 55
medium / low	187 / 50	184 / 49

Unit tests: 1320 passed, 0 errors (3 skipped). Five pre-existing environmental errors were confirmed identical on clean master and then cleared entirely by running the suite's tests/resources/httpserver/start.py helper and xvfb-run.

_{Raw totals are for reconciliation only — X/Y count distinct CVEs while the raw total counts per-occurrence, so they do not sum arithmetically.}

Local code review

An independent reviewer ran on the diff pre-push and verified it empirically in the real image (applied the exact apt line, dpkg --audit clean, HTTPS/bzt --help smoke tests passed). Verdict: ready to merge. Outcome of its findings:

Applied (4):

• Marked the erb/json gem entries as appeasement rather than fixes (see below)
• Rewrote the block's "remove each when the base image ships the fixed version natively" instruction, which contradicted a decision recorded in this same commit
• Replaced the positional "The last three" comment with explicit package names, so it cannot rot when a fourth is appended
• Corrected the dead libgnutls30 name (which then led me to sweep all 33 entries and find libpipewire-0.3-0 too)

Declined (1): adding the other 7 base-shipped upgradable packages (diffutils, libpam*, libproc2-0, procps). Checked the baseline CSV: none of them are flagged, so no fix was missed by the criterion above. Adding unflagged packages would be speculative churn, and every entry is a maintenance liability — as the two dead entries just demonstrated.

Two findings that need separate follow-up

1. The existing erb and json gem "fixes" are scanner appeasement. In the currently published image:

net-imap: Gem.loaded_specs -> 0.5.15   (no stdlib copy left)   => REAL fix
erb:      Gem.loaded_specs -> NONE     ERB.version   == 4.0.4  => vulnerable code runs
json:     Gem.loaded_specs -> NONE     JSON::VERSION == 2.9.1  => vulnerable code runs

For a pure default gem the code lives in Ruby's stdlib dir, not the gem dir. Deleting specifications/default/<gem>-<old>.gemspec de-registers the feature as gem-upgradable, so require stops consulting RubyGems and loads the old stdlib copy — Prisma goes quiet while the vulnerable code still executes. net-imap is unaffected because its code really does live in the gem dir.

Only the comments are corrected here. Reverting the mechanism re-adds 2+ findings to the scan, which would fail this run's decision gate, so it needs its own PR. Ruby 3.4.10 bundles erb 4.0.4.1 (would make erb genuinely fixed) but still json 2.9.1, so a ARG RUBY_VERSION bump solves only half.

2. The baseline scan can silently scan a stale image. prisma-cloud-ondemand-scan on the mutable unstable tag reused a previously-pulled copy: scans #220 and #221 both reported Image ID 9a200d22… (the 09-01 image) even after master #14904 republished the tag mid-run. The tell was that several flagged packages were already at their fixed versions on disk. Re-baselined by digest (IMAGE_URL=blazemeter/taurus@sha256:…; note the artifact is then named taurus@sha256.csv). Without this, 7 findings would have been misclassified as needing fixes.

Also in this PR

vulnerability_history.md updates so future runs don't re-derive any of the above: the pure-default-gem appeasement trap and its decision test, the base-image-vs-unpinned OS provenance rule (the mirror of the earlier openssl case), the silent-skip/t64 dead-entry trap with a sweep command, why unpinned --only-upgrade entries must not be pruned when the base catches up, the stale-image scan caveat, and refreshed re-check conditions for the faker / file-type / diff / resolv deferrals.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

A couple of newly added/edited Dockerfile comments are internally inconsistent/ambiguous and should be clarified to avoid misleading future maintenance of the CVE upgrade block.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the Taurus Docker image build to explicitly --only-upgrade a few Ubuntu 24.04 base-image–shipped packages so patched versions land during image build (and fixes two silently-skipped package names due to t64 renames), alongside documenting the rationale/decision traps in the Prisma skill history.

Changes:

• Fix two dead apt-get install --only-upgrade entries by switching to libgnutls30t64 and libpipewire-0.3-0t64.
• Add explicit --only-upgrade entries for libp11-kit0, libattr1, and coreutils to pick up patched pocket versions even when they are already present in the base image.
• Expand documentation in both the Dockerfile and vulnerability_history.md around provenance, silent skips, and “appeasement vs real fix” pitfalls.

File summaries

File	Description
Dockerfile	Adjusts OS --only-upgrade package list (incl. t64 renames) and adds base-shipped package upgrades; updates inline CVE/provenance commentary.
.claude/skills/prisma-taurus/vulnerability_history.md	Adds/refreshes operational guidance on default-gem appeasement traps, OS provenance rules, dead --only-upgrade entries, and stale-scan pitfalls.

Review details

Suppressed comments (1)

Dockerfile:248

• Same as above: this reference to vulnerability_history.md is ambiguous without the repo path; use the full path so readers can jump to the right document quickly.

#     Revert in a DEDICATED PR (reverting alone re-adds scan findings, so it cannot ride inside a CVE
#     run whose gate requires the total to drop). See vulnerability_history.md, "When a Ruby gem has a
#     CVE" step 3 (pure-default-gem trap) for the decision test and options.

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.19%. Comparing base (c9c3d17) to head (88f7eae).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2023   +/-   ##
=======================================
  Coverage   88.19%   88.19%           
=======================================
  Files          75       75           
  Lines       21164    21164           
=======================================
  Hits        18663    18663           
  Misses       2501     2501           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RafaelGuevaraCA]

Superseded by #2024, which is merged.

#2024 contains both commits from this PR unchanged (feb19c44, 88f7eae5) plus the Ruby 3.4.10 work, so nothing here is lost:

• the same 4 OS CVE fixes (libp11-kit0 x2, libattr1, coreutils)
• the two dead --only-upgrade entries (libgnutls30t64, libpipewire-0.3-0t64)

#2024 additionally replaces the erb/json gem appeasement with real fixes, so closing this one in favour of a single merge to master.