Jupyter Security Council Updates
Unless you are a maintainer or vulnerability reporter, you may not hear about security often; in fact security ranked last in the 2026 User Survey. Here is what the Jupyter Security Council is working on in 2026, the tricky bits, and where we’re heading.
Who we are
The Security Council is one of Jupyter’s subprojects. Security triage, fixing and publication have always been handled by maintainers, and they still do much of that work. Since April 2026, I have been supporting their effort especially on triage and long-term initiatives as part of a Jupyter Foundation grant funding me 1 day per week until December 2026. A second grant has extended this capacity and timeline to 2 days a week, plus time from @Carreau to bring expertise and onboard new contributors, until March 2027.
What makes Jupyter Security challenging
Scale: Jupyter is spread across 22 GitHub organizations and more than 400 repositories (counting only the public, non-archived, non-documentation ones). From these repos, Jupyter publishes 228 PyPI packages and 281 npm packages.
Security boundaries: Evaluating security reports is tricky due to the complicated security boundary: Jupyter executes code by design, but in a controlled way. We have to define exactly what is allowed and what is not; this is especially challenging when multiple repos work together.
Releasing fixes: merging fixes has to be coordinated with the publication of releases, which requires maintainers’ time. We do not directly deploy Jupyter; security advisories are a tool to let our users know they need to upgrade through dependabot and similar tools.
2026 in numbers
So far in 2026 we have received 181 GitHub security advisories (GHSA), and September 2026 has hit a record high of 40 reports.
As of 2026-10-16, 88 (49%) were closed as invalid or duplicate, 32 (18%) are being fixed and 32 (18%) have been fixed then published. The rest is in the triage backlog.
We are also catching up on 25 reports opened before 2026 that are waiting for a fix (the rest of the 150 reports opened before 2026 were either closed or published). Therefore this October, Jupyter Foundation approved a funding proposal for additional capacity to keep up with this additional workload.
As this graph shows, our current backlog of reports awaiting triage or fixes almost reaches the total number of advisories we have ever published on GitHub. This is driven primarily by the surge in AI-generated reports. Source
Fighting AI with AI?
This is how many reports we have received each month on GitHub across the whole project. Source
The triage volume had been manageable with manual review until August (20/month), but the 40 reports we received in September leave no doubt: we have to figure out a way to leverage AI to help with triage, at the very least to deal with duplicates.
We also find AI reports are very lengthy and hard to read, with a high false positive rate. The reports routinely overstate their severity, and we sometimes deal with autonomous agents (e.g., if we ask a question an AI will reply to us).
AI can only be effective at triage when the threat model is well documented, otherwise false positives are frequent. Here is an example of Michał Krassowski’s work on JupyterLab where he documented the threat model and strengthened instructions for LLMs.
We are not alone in this effort and I believe we should also federate efforts on tooling with other security communities. For instance the Python Security Response Team is developing their own tool, the PSRT GHSA Bot to work with incoming GHSAs at scale.
What we are working on
In addition to day-to-day work on triage, the Security Council and I are working on several long-term initiatives to increase the security posture of the project.
Supply chain security: CI hardening to prevent a GitHub Actions hijack; trusted publishing to limit the damage of a potential PyPI or npm account incident. This initiative, still being implemented, was started in April.
Prioritization: not all 400+ repositories need the same attention. We need to establish an auditable methodology to find out where to focus our efforts on supply chain security or writing fixes.
Tooling: github-security-overview is an actively developed command-line tool that aggregates GHSAs across multiple GitHub organizations and repositories.
Dealing with maintenance discrepancies: repositories like JupyterLab, JupyterHub and JupyterLite have been mostly handling their own reports and fixes. However the Jupyter ecosystem has a lot of inactive repositories that are still downloaded or depended on a lot. To address this, the Security Council is pursuing two long-term initiatives:
- attribution: what subproject is responsible for what repo;
- tiering system and archiving: identifying less-maintained repos and warning users if they are a security risk
Onboarding more security contributors: the latest Jupyter Foundation-funded proposal includes some time from @Carreau on onboarding new contributors, strengthening documentation, and providing Jupyter expertise.
Jupyter Security is more open than you think: here’s how you can contribute
We are working in public at https://github.com/jupyter/security. You are welcome to suggest initiatives through issues or comment on existing issues. We try to label good first issues for tasks like documentation updates.
For casual chatter, our Zulip channel is @Security[Public] channel. We host open, regular Zoom meetings on Tuesdays.
Feel free to reach us at security-council@jupyter.org, or see https://jupyter.org/security if you have a security issue to report.
Resources
- Public monthly reports with numbers as part of my Jupyter Foundation funding
- More statistics on our public security repo!
- Slides from my Open Source Summit 2026 Prague talk on Jupyter Security
- Other Jupyter blog articles about security
About the author
Yann Pellegrini is an independent software engineer who recently turned to open-source. Since April 2026, he has been working on triage and long-term initiatives for Jupyter Security, currently supported by a Jupyter Foundation grant. Yann also co-maintains the PyData Sphinx Theme.
Acknowledgements
Thanks to the Jupyter Foundation for two rounds of security funding in 2026.
@Carreau, for introducing me to Jupyter security, and help on writing the funding proposals; Jason Grout, for working on governance and reviewing communication material; Michał Krassowski for driving security across JupyterLab, and many security initiatives across the whole project; Min Ragan-Kelley for driving security on JupyterHub, and reviewing many security fixes and PRs and Abhishek Pai for reviewing.