v2.8.0 CVE's (CVE-2025-68121, CVE-2025-22871, CVE-2025-15467)

[hero-david]

Multiple CVE's are present in the latest release of the TUSD docker image. We detected these via AWS Inspector, which runs on our container regitry, where we cache TUSD in a pull-through configuration from Dockerhub.

This can be verified independently with the Docker scout tool if Docker Desktop is installed:

➜  ~ docker scout cves tusproject/tusd:v2.8.0
    ✓ Pulled
    ✓ Image stored for indexing
    ✓ Indexed 151 packages
    ✓ Provenance obtained from attestation
    ✗ Detected 6 vulnerable packages with a total of 47 vulnerabilities


## Overview

                   │                              Analyzed Image
───────────────────┼──────────────────────────────────────────────────────────────────────────
 Target            │  tusproject/tusd:v2.8.0
   digest          │  2047eda72f63
   platform        │ linux/arm64
   provenance      │ https://github.com/tus/tusd.git#0e52ad650abed02ec961353bb0c3c8bc36650d2c
                   │  0e52ad650abed02ec961353bb0c3c8bc36650d2c
   vulnerabilities │    3C    14H    27M     3L
   size            │ 30 MB
   packages        │ 151

The critical CVSS scores are found amongst the Golang stdlib:

   2C     7H    12M     1L  stdlib 1.24.1
pkg:golang/stdlib@1.24.1

As well as the openssl version for alpine 3.21:

   1C     4H     8M     0L  openssl 3.3.3-r0
pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.21

The head commit of the main branch currently specifies FROM --platform=$BUILDPLATFORM golang:1.25.6-alpine AS builder, and I can see that dependabot PR's have been merged regularly, they just havent been published to Dockerhub outside of the per commit SHA-xyz images, which aren't a preferable version to deploy to production.

A recent issue was opened in October, asking for a new release to be published, but it was closed as completed without action (#1321) and 2.8.0 was cut last year in April, which is a long time in the world of security!

Would it be possible to have a patch release built and published to Dockerhub (v2.8.1 ?) to mitigate these underlying build chain and OS vulnerabilities?

Many thanks!

[drakkan]

I have no affiliation with the tusd project, but I’d like to share my perspective as a fellow open-source maintainer.

It’s crucial to distinguish between vulnerabilities in the application's source code and those in upstream dependencies (like the Go stdlib or base OS). If a security scanner warning can be resolved by a simple recompile with the latest toolchain, it is an environment issue rather than a bug in the software itself.

Requesting ad-hoc releases for every upstream CVE places a significant burden on maintainers. Given that we already receive such high-quality software for free, the 'open-source way' to handle immediate compliance needs is to simply rebuild the image locally. It’s the most sustainable approach for everyone.

Just my two cents. Thank you to the tusd maintainers for this library

[hero-david]

Hi @drakkan , absolutely, I definitely hear that. Though in this case the goland net/cryto vulnerabilities in the stdlib may genuinely affect the server if there is a crypto component that uses the affected libraried (I've not verified due to time constraints unfortunately)

There is an argument to be made that if you offer a distributable package for a bit of software, it should probably be fit for purpose and secure by default too. If consumers building themselves is the way to go, I'd respect the choice being more obvious, with no docker artifact support, and maybe instructions for creating a self-maintained image in it's place.

The devils advocate around sustainability is that we don't know this project, we dont know if main is stable, we cant afford time spent scouring commits to ensure we're happy bring in changes as end users. it effectively turns all downstream users of the product into maintainers themselves, which I imagine is not something many people could justify.
Ad-hoc release requests is a bit misplaced here, a years worth of missing security updates in an artifact is a valid thing worth discussing, I hope this issue ddn't come across as flippant.

Anywhom, this probably isnt the place for a moral quandry, I'm just trying to gauge the maintainers appetite for passing on the automated security upgrades to the end users of the code 👍

[Acconut]

Thanks for bringing this up, @hero-david, and thank you, @drakkan, for joining the discussion as a fellow OSS maintainer 👋

AFAIK, this will be resolved by cutting a new release, which I've just done and was overdue anyway: https://github.com/tus/tusd/releases/tag/v2.9.0. Let me know if that's not sufficient.

[ferhatelmas]

@Acconut I put #1343 which would help maintenance by dropping huge dependencies

[hero-david]

Thanks @Acconut! Yeah a new release with the latest Go versions and dependabot updates is stellar, appreciate it!

[m7kvqbe1]

Can you guys please build this again with Go 1.25.7+?

It looks like CVE-2025-68121 is still in the image when I do a grype scan.

[Acconut]

Release v2.9.2 should be built with Go 1.26.1. Does that work for you?

[m7kvqbe1]

That's great thank you! All sorted!