In jupyterhub 5.2.1 there seems to be the following vulnerability:
npm ip Version1.1.5
CVE-2023-42282
File location in the container: /usr/share/nodejs/ip/package.json
This is currently fixed in versions1.1.9, 2.0.1
Has anyone else come across this?
If so, how did you fix it?
Note: I fixed it by upgrading nodejs to 20.x.
That said, I am curious if others have noticed this and how they have solved it.
My fix:
I rebuilt the container removing nodejs and installing version 20.
Steps: (From my Dockerfile)
RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
RUN apt remove nodejs -y
RUN apt update
RUN apt autoremove -y
RUN apt install nodejs -y
RUN npm ls -g
This appears to not be an issue in JupyterHub codebase, nor in JupyterHub dependency. The only connection with JupyterHub I could think of is that for (an unknown to me) reason this package was included in a container image that you used. There is to little information to make this actionable. In future, please mind that there are dedicated ways to report security vulnerabilities if you come by any.
1 Like
Thanks. Yes, this is limited to the image I pulled from Docker hub:
https://hub.docker.com/r/jupyterhub/jupyterhub (Tag 5.2.1)
Question: Are you able to direct me to the correct way to report security vulnerabilities Jupyterhub?
manics
January 20, 2025, 4:06pm
4
You can report secvulns at Security Overview · jupyterhub/jupyterhub · GitHub
However we wouldn’t class an out-of-date NPM package as a secvuln unless there’s a way to exploit it. A lot of packages are only partially used, or are brought in as dependencies of other packages without being used at runtime.
We’ve got some ongoing work to build our Docker images independently of JupyterHub releases:
opened 01:50PM - 19 Nov 24 UTC
maintenance
breaking
### Proposed change
Related to https://github.com/jupyterhub/team-compass/iss… ues/474 I think maybe we should stop publishing jupyterhub images altogether.
We currently publish these images from this repo:
- jupyterhub/demo - a toy complete environment for quickstart/testing purposes (not useful for any deployment) where users are run in the container
- jupyterhub/jupyterhub - includes hub and proxy, no Spawner cannot run users - not useful for production
- jupyterhub/jupyterhub-onbuild (adds a single `ONBUILD ADD` to jupyterhub/jupyterhub) for a minor convenience as a base image
- jupyterhub/singleuser - shouldn't be used, offers nothing over docker-stacks
Production deployments do not generally use these images because:
- they do not include a Spawner, so can't be used on their own, they can only be a _base_ image for other custom images
- the base image part can be fully replaced with a single `pip install` or `conda install` in a more nontrivial base image
- jupyterhub/jupyterhub includes CHP, which should not generally be run in the same image, and we shouldn't be implicitly encouraging it
Maintaining these images on this repo causes maintenance problems like #4953 and the various motivations for https://github.com/jupyterhub/team-compass/issues/474
I propose that we stop publishing these images altogether until/unless we get image-building going from its own repo. I wish I had proposed this before 5.0, since a major version is a nice cutoff for a change in practice, but the second best time is now.
The only image I think we _might_ keep is `demo`, since it serves a unique purpose and is clearly not for production use. The others may give the _impression_ of being appropriate for something they shouldn't really be used for.
Stopping publishing from here does not _preclude_ us from publishing images (even these same images) from another repo. But it does mean that we need to set up infrastructure _dedicated to building and maintaining images_ before we start building these images again, which I think will help us be thoughtful about it.
### Alternative options
- Keep publishing from this repo (I don't think we should do this, but it will keep happening if we don't change something)
- Move image-building to its own repo in a more thoughtful way _before_ we stop building here, focused on building images that address real use cases
### Who would use this feature?
The real question is: is anyone really using `jupyterhub/jupyterhub` who would be inconvenienced by this? `jupyterhub/singleuser` is an empty layer on top of `base-notebook`. `quay.io/jupyterhub/jupyterhub` is pulled over 1000 times every day, but looking at the logs quay.io gives us, about 80% of all worldwide pulls of jupyterhub/jupyterhub come from a single instance of [watchtower](https://containrrr.dev/watchtower/) in the Netherlands, which has pulled it over 10,000 times in the last week.
1 Like