Bump deps: concurrent-ruby + httpclient5/httpcore5 (Mend HIGH; opennlp/webrick/pypdf blocked)

[odosk]

⚠️ This PR was created by an AI assistant (Claude). Please review all changes carefully before merging.

Once approved, please merge it — this is an automated dependency-update PR and merging is the final step that closes out the linked Mend findings.

Summary

Sweeps HIGH/CRITICAL Mend findings on VESPANG-3395: the docs concurrent-ruby gem and (added 2026-07-10) the httpclient5/httpcore5 pair in examples/reranker. Rebased onto latest master. Several findings remain unfixable in this scope — see below.

Changed Files

Gemfile.lock — regenerated via bundle lock --update (Bundler 4.0.6) in an isolated container:

• concurrent-ruby: 1.3.6 → 1.3.7 (fixes CVE-2026-54904)
• side-effect upgrades: google-protobuf 4.35.0→4.35.1, i18n 1.14.8→1.15.2, io-event 1.16.1→1.16.2, json 2.19.8→2.19.9

examples/reranker/pom.xml — httpclient5: 5.6.1 → 5.6.2 (pulls httpcore5 5.4.3, fixing the httpcore5 CVEs)

CVEs Addressed

Verified against the GitHub Advisory Database / OSV.dev / Maven Central:

Package	CVE(s)	Severity	Fix version reached
concurrent-ruby	CVE-2026-54904	high	1.3.7
httpcore5 (via httpclient5)	CVE-2026-54399	high	5.4.3
httpcore5-h2 (via httpclient5)	CVE-2026-54428	high	5.4.3

⚠️ Cannot fix in this PR

Project	Package	CVE	Reason
examples/lucene-linguistics/going-crazy	opennlp-tools @ 1.9.4	CVE-2026-42027 (CRIT), CVE-2026-40682 (CRIT), CVE-2026-42440 (HIGH)	Transitive of lucene-analysis-opennlp, pinned to the platform Lucene (${lucene.vespa.version} → 9.12.3). Fixed in opennlp-tools 2.5.9, but Lucene 9.x's lucene-analysis-opennlp is compiled against the opennlp 1.9 API — force-overriding to 2.5.x compiles but fails at runtime (NoSuchMethodError). Needs a platform Lucene 10 upgrade; this example tracks the platform version.
(repo docs)	webrick @ 1.9.2	CVE-2026-38969 (HIGH)	No upstream patch — 1.9.2 is the latest published gem and is itself the flagged version (dev-only Jekyll toolchain dep). Tracked at ruby/webrick#199. Nothing to bump to.
visual-retrieval-colpali	pypdf @ 6.13.3 · httplib2 @ 0.31.2	CVE-2026-59935 / -59936 (pypdf); CVE-2026-59939 (httplib2)	Fixes exist (pypdf 6.14.2, httplib2 0.32.0), but src/legacy-requirements.txt is a uv pip compile output that currently cannot be regenerated: pyproject.toml has a pre-existing unsatisfiable constraint (transformers==5.12.0 vs vidore-benchmark[interpretability] requiring transformers<5.0.0). Hand-editing the compiled file is disallowed. Path forward: resolve the transformers/vidore-benchmark conflict, then uv pip compile pyproject.toml -o src/legacy-requirements.txt --upgrade-package pypdf --upgrade-package httplib2.

Implementation Notes

• concurrent-ruby is transitive (via jekyll ~> 1.0); regenerating the lock floats it to 1.3.7 without a Gemfile change.
• httpclient5 5.6.2 (2026) bumps its managed httpcore.version to 5.4.3 (confirmed in httpclient5-parent-5.6.2.pom), which is the first httpcore5 release fixing the HTTP/1.1 parser DoS — this supersedes the earlier "no fixed release exists" note.
• No downgrades; BUNDLED WITH (4.0.6) and CHECKSUMS preserved.

Verification

• grep concurrent-ruby Gemfile.lock confirms 1.3.7; httpclient5 5.6.2 in examples/reranker/pom.xml.
• Re-run the Mend scan after merge: concurrent-ruby + httpcore5 CVEs clear; opennlp / webrick / pypdf / httplib2 persist as noted above.

🤖 Generated with Claude Code

[odosk]

TL;DR: the one red check (test / htmlproofer) is a pre-existing external-link 404 unrelated to this PR — safe to merge on green review.

test / htmlproofer fails at visual-retrieval-colpali/README.html:199 → https://www.shad4fasthtml.com/ returns 404 (external link rot). That file is not touched by this PR (a Maven concurrent-ruby / httpclient5 bump), and the same link is present on master (visual-retrieval-colpali/README.md:211), so the check fails there too — it is not introduced here. Per the minimal-fix rule I am not editing that unrelated sample-app's docs in this dependency PR; the dead link is worth a separate cleanup.

Posted by Claude (security-workflow) on behalf of @odosk.