Problem
#241 brought fixable CRITICAL/HIGH findings from 91 to 8. The remaining 8 are waived in security/vulnerability-allowlist.txt because a fix exists upstream but we cannot take it — each is capped by a dependency, or has no released fix.
They are waived, not resolved. Each needs revisiting when the upstream constraint lifts. The CI gate passes today because of these waivers, so if a waiver is removed without the underlying fix, the build fails — which is the intended behaviour.
The findings
1. CPython — CVE-2026-15308 (all Python images, 5 of the 8)
2. transformers 4.57.6 — GHSA-29pf-2h5f-8g72, GHSA-fgcw-684q-jj6r (autogluon)
- Fixed in transformers 5.3.0 and 5.5.0.
- Blocked:
autogluon.timeseries 1.5.0 pins transformers[sentencepiece]<4.58.
- Both advisories concern loading untrusted model checkpoints. The worker loads only models we ship, so the affected path is not reachable — this is why it is a waiver rather than a blocker.
- Action: watch for an autogluon release that raises the cap. Track autogluon/autogluon releases.
- Review: 2026-10
3. pyarrow 20.0.0 — GHSA-rgxp-2hwp-jwgg (autogluon)
- Fixed in pyarrow 23.0.1.
- Blocked:
autogluon-common 1.5.0 requires pyarrow<21.0.0. Pinning above the cap was attempted and makes the dependency set unresolvable:
ERROR: Cannot install autogluon.timeseries and pyarrow>=23.0.1 because these
package versions have conflicting dependencies.
autogluon-common 1.5.0 depends on pyarrow<21.0.0 and >=7.0.0
- Action: same as above — gated on an autogluon release.
- Review: 2026-10
Recommended fix
- Set a recurring check against the review dates in
security/vulnerability-allowlist.txt. The SBOM and Vulnerability Scan workflow already runs weekly, so a lifted cap will surface as a newly-fixable finding.
- When a constraint lifts: bump the dependency, delete the waiver line, confirm CI passes without it.
- If autogluon does not raise its caps within a couple of releases, weigh whether
autogluon.timeseries is worth the two capped dependencies — the xgboost and lightgbm workers have no equivalent problem.
Note on severity
These are HIGH, not CRITICAL. All fixable CRITICALs were resolved in #241. The remaining CRITICALs are base-OS findings with no upstream fix, tracked in #243 and #244.
Related: #241, #243, #244
Problem
#241 brought fixable CRITICAL/HIGH findings from 91 to 8. The remaining 8 are waived in
security/vulnerability-allowlist.txtbecause a fix exists upstream but we cannot take it — each is capped by a dependency, or has no released fix.They are waived, not resolved. Each needs revisiting when the upstream constraint lifts. The CI gate passes today because of these waivers, so if a waiver is removed without the underlying fix, the build fails — which is the intended behaviour.
The findings
1. CPython —
CVE-2026-15308(all Python images, 5 of the 8)python3.13.14, our current base.security/DEPENDABOT_TRIAGE.md.python:3.13-alpinescans at 0 CRITICAL / 3 HIGH.2.
transformers4.57.6 —GHSA-29pf-2h5f-8g72,GHSA-fgcw-684q-jj6r(autogluon)autogluon.timeseries1.5.0 pinstransformers[sentencepiece]<4.58.3.
pyarrow20.0.0 —GHSA-rgxp-2hwp-jwgg(autogluon)autogluon-common1.5.0 requirespyarrow<21.0.0. Pinning above the cap was attempted and makes the dependency set unresolvable:Recommended fix
security/vulnerability-allowlist.txt. TheSBOM and Vulnerability Scanworkflow already runs weekly, so a lifted cap will surface as a newly-fixable finding.autogluon.timeseriesis worth the two capped dependencies — the xgboost and lightgbm workers have no equivalent problem.Note on severity
These are HIGH, not CRITICAL. All fixable CRITICALs were resolved in #241. The remaining CRITICALs are base-OS findings with no upstream fix, tracked in #243 and #244.
Related: #241, #243, #244