zero-to-jupyterhub-k8s icon indicating copy to clipboard operation
zero-to-jupyterhub-k8s copied to clipboard

Snyk vulnerabilities in jupyterhub/k8s-hub – outdated icu, libxml2, and tornado packages

Open ronak-sirwani opened this issue 5 months ago • 3 comments

Bug description

Security vulnerabilities reported by Snyk in the image jupyterhub/k8s-hub:4.2.0 due to outdated base packages:

Package Current Version Fixed In Version
icu / libicu72 72.1-3 72.1-3+deb12u1
libxml2 2.9.14+dfsg-1.3~deb12u1 2.9.14+dfsg-1.3~deb12u2
tornado 6.4.2 6.5

Vulnerability 1

CVE: CVE-2025-5222 Package: icu/libicu72 Version installed through docker image: 72.1-3 Fixed in version: 72.1-2+deb12u1 Severity: High

Vulnerability 2

CVE: CVE-2025-27113, CVE-2025-32415, CVE-2025-32414, CVE-2024-25062 Package: libxml2 Version installed through docker image: 2.9.14+dfsg-1.3~deb12u1 Fixed in version: 2.9.14+dfsg-1.3~deb12u2 Severity: High

Vulnerability 3

CVE: CVE-2025-47287 Package: tornado Version installed through docker image: 6.4.2 Fixed in version: 6.5 Severity: High

i can see tornado package has already been updated in the main branch, but latest release tag does not includes this fix yet. Similarly, the image is based on Debian Bookworm, and these system-level packages are not hard-pinned, so rebuilding the image with an updated base could resolve the issues.

How to reproduce

  1. Deploy jupyterhub/k8s-hub:4.2.0 using a Kubernetes-based deployment (e.g., via the JupyterHub Helm chart)
  2. Run a container image scan using Snyk or any vulnerability scanner
  3. Observe reported vulnerabilities in the packages mentioned above

Expected behaviour

The official image should contain patched versions of all known vulnerable packages and should pass security scanning tools like Snyk.

Actual behaviour

Outdated versions of system and Python packages are bundled in the released image. These versions have known vulnerabilities that have already been addressed in upstream packages or in main, but are not yet released in any image tag.

Your personal set up

  • OS: Debian Bookworm (inside container)
  • Image: jupyterhub/k8s-hub:4.2.0
  • Deployment: Kubernetes using zero-to-jupyterhub
  • JupyterHub Version: 4.2.0
Full environment N/A – issue originates in the container image base packages
Configuration Deployed using default Helm values from zero-to-jupyterhub with `jupyterhub/k8s-hub:4.2.0`
Logs N/A – this issue is observable via image scan rather than runtime behavior.

Suggested Fix

  • Rebuild the image with an updated Debian Bookworm base
  • Release a new tag (e.g., 4.2.1) to include:
    • Patched versions of icu, libxml2
    • Upgraded tornado==6.5 (already present in main)

ronak-sirwani avatar Jul 08 '25 12:07 ronak-sirwani

any update on above issue ?

ronak-sirwani avatar Jul 29 '25 04:07 ronak-sirwani

As you've pointed out the image is updated on the main branch. There are no significant changes https://github.com/jupyterhub/zero-to-jupyterhub-k8s/compare/4.2.0..HEAD

so it's fine to override your hub image to use the latest build from https://quay.io/repository/jupyterhub/k8s-hub?tab=tags&tag=latest

A release won't have any additional testing beyond what's already done for the main branch, so doesn't guarantee any additional stability.

manics avatar Jul 30 '25 09:07 manics

@manics Thank you for the clarification!

I understand that the fixes are already available on main and reflected in the latest image. That definitely helps as a temporary solution.

That said, for production environments and CI pipelines, it's often preferable to rely on a properly versioned and tagged release (e.g., 4.2.1) rather than using a floating latest tag — mainly for stability, traceability, and compliance purposes.

Is there an estimated timeline for when a new tagged release (such as 4.2.1) might be published to include these security updates?

Thanks again for your support!

ronak-sirwani avatar Aug 05 '25 05:08 ronak-sirwani