We are using AppCheck to run security scanning on our Jupyterhub deployment. However, there are some sensitive packages which are getting flagged up by the system, albeit low impact but they have a high CVSS score. Files such as “https://example-url/user/username/static/lab/package.json” are cropping up. These sit behind authentication wall but they are publicly accessible. The message attached to the finding was: A known sensitive file was found to be published within a publicly accessible web directory. Depending on the file it could disclose sensitive data such as user credentials and configuration data.
How can these package.json files be removed from the image build safely without affecting the deployment? I believe this is a Jupyterlab Image issue, but I cannot seem to figure out how to remove these dir and files. I have tried the googling route, senior engineer also.
This is a security issue as there is a CWE being flagged in the code.
We have used the z2jh guide to deploy the service on our EKS for reference.
How to reproduce
Follow the Z2JH guide to deploy the application on EKS.
Expected behaviour
Once scanned, these CWE/CVEs around sensitive packages do not get flagged by a security scan.
Your personal set up
We have followed the Z2JH guide for setting up this deployment on EKS. We are using the latest stable release of the Docker image for quay.io/jupyter/datascience-notebook:2025-08-11 and have added further tools in the build process.
Interesting discussion to follow! I think to be more specific, being able to safely remove these package.json files - as they are flagged by security scanning is the desired outcome for us, unless stated otherwise.
You can safely remove package.json and yarn.lock files if you are not rebuilding lab, but this is the same as ignoring false positives. What worse, if there was a real issue flagged later based on the contents of the file you would not receive an alert. It’s a trade-off between silencing a broad false-positive warning vs not getting more detailed warnings in the future.
if I wanted to remove this package or make it inaccessible 404, how would I do this? I am using the docker image stated in my initial post for Jupyterlabs.
If this scanner thinks all package.json are “sensitive,” likely they should be blocked with an application-level firewall rule, which would run outside the container.
This may reveal runtime browser dependencies on that file. Won’t know until you try.
These are all opensource packages, and the versions are easily discoverable in a running application, so it’s trivial for an attacker to lookup the package.json (and all other language dependencies) from the original source. This applies to JupyterHub too. There’s probably no harm in deleting those files from a deployed site, but I don’t think it provides additional security.
Regarding a separate application-level firewall rule Rizwan and I have been hosting Jupyterhub in AWS so tried using AWS WAF. Jupyterlab uses websockets to return the output of a running cell and AWS WAF is not compatible with websockets, so the output is dropped. There may be another firewalling solution.
Regarding security posture deleting these files does feel like security through obscurity. Unfortunately our standards are clear and inflexible so the false positives must be squashed.
Currently we’re building new container images based on the public Lab images then removing unwanted files. Is there a better way to do this? Perhaps if we built the base lab image ourselves there’s an argument to npm that would clean up non-essential files?
You’ll only know if it’s non-essential… if it breaks. For example, deleting PREFIX/share/jupyter/lab/extensions/**/package.json might well break many APIs, as these are consulted as a source of truth for identification information, but also served to, and sometimes used by, the browser.
One could attempt to write a jupyter_server extension/monkeypatch that prevented patterns of files from being served from by tornado, but this is, once again, security theater that might well break things without actually preventing any disclosure of “sensitive” information.
Otherwise: in general in a production setting, always be building your own container from the lowest level you can manage (e.g. an official OS distro), with your own chosen packages, and actually scan it.
that might well break things without actually preventing any disclosure of “sensitive” information.