illinois
NPM package security
Coming from an advisory and noticing that we are using this project
ADVISORY: Next.js – Critical Authentication Bypass Vulnerability – CVE-2025-29927
Summary
A critical security vulnerability (CVE-2025-29927) in Next.js middleware allows attackers to bypass authorization checks in affected versions.
This issue impacts all versions of Next.js, with patches now available. Users of self-hosted deployments should update immediately. Affected Versions
11.1.4 through and including 13.5.6 14.0 up to 14.2.25 15.0 up to 15.2.3Fixed Versions
12.3.5 13.5.9 14.2.25 15.2.3Details Impact:
Authorization checks in Next.js middleware can be bypassed, allowing unauthorized access. Exploitability:
No preconditions required – all affected versions are vulnerable.
Checking NPM's audit resulted in quite a few. Of course some are build/dev dependencies and would never see the light of day (public web path).
❯ npm audit
...
187 vulnerabilities (7 low, 64 moderate, 72 high, 44 critical)
Proposed Solution: Try to bring the critical and high NPM security issues down to 0 by upgrading some of the dependencies to newer releases.
I'm not sure if anyone else with write access will chime in here, but I should point out this repo isn't actively maintained in its current state, and our university doesn't have this exact version deployed any more either. I have made some small backports here for documentation recently, but we have a private fork to address some of the specific issues or add specific features requested by our course staff. The versions of React and Next are out of date enough, with many breaking changes, that pretty massive rewrites are needed to bring it fully up to date, and I've personally not had the time to devote to that yet, and although we might eventually commit patches back here for the community, I personally can't offer you support for deploying it. In the meantime, unless you're running this in a controlled setting like an office hours lobby, I would discourage you from using it. I will note that the version of Next in use here is actually older than the affected versions in the advisory, although there are other issues with the legacy code of course.
@echuber2 Thanks for chiming in. I’m in the process of absorbing this application into our group’s maintenance and trying to shore up the Next.js dependency because of the CVE. I hadn’t realized it wasn’t actively maintained, though I did notice your recent doc updates.
Really appreciate all the work that’s gone into this project — I know firsthand how much time and energy open source contributions can take. Even if your team has moved on, this repo has clearly been valuable to others.
It might be a good time to consider marking it as archived? I’ll check how much usage it’s getting on our end and figure out how we’ll proceed from there. I am sure it's being used in UBC CS, but just not sure how much.
I can try to make a cautionary note in the readme but I'd need to leave it to the repo's original owners to think of archiving it. I've only informally assumed maintenance of deploying a fork of it here so I'm trying to tread lightly around what was a legacy project from some talented students. Six months ago I did take a stab at overhauling the dependencies and there were enough snags in the process that I decided to apply mitigations and pivot to more pressing tasks. Coincidentally, I've been looking at the code a lot again recently because of some feature requests we received and other bugs we uncovered, so our fork will have diverged from here a bit more before that's finished. This repo also has some never-deployed features from the original student developers (e.g. the starred queues), so there may be other undiscovered issues in what you can see here.
I was hoping to find time to finish the features I was already working on, look at whether that can be reintegrated with this upstream, and then try again to update the framework dependencies and rewrite as necessary. Now if you'd like to fork the whole project under the (apparently, NCSA) license and run with it, you probably may with or without my permission. Some other staff also expressed interest in reimplementing the functionality in a new codebase, so it is good to know that others are still interested in this version. I wasn't sure if I'd request time to work on this just to have a rug pull situation with another team replacing the whole thing.
(Also, not to diminish this project at all, but as an alternative, I've often thought it would be possible to use the "private posts" feature available on many LMS forum software platforms, as I remember doing as a TA before Queue. This is still basically taking a queue of student issues and marking them resolved/deleted in the same way.)
:wave: I was one of the primary developers of this project back in undergrad, it's neat to hear that this is being used by folks at UBC! I work a lot with other faculty and staff there in my role at PrairieLearn.
Thanks for reporting this potential vulnerability. This project indeed may be old enough to not be impacted. Sadly, I don't have the bandwidth to continue maintaining this project for free. If you/UBC (or Eric/Illinois) is interested and able, I'm open to sponsored work/consulting to do things like update dependencies or add features.
Eric, you mentioned others had thought about reimplementing the queue from scratch yet again. That's exactly what I did when I wrote this one 😂 there was a previous implementation that we probably should have just kept maintaining, but the allure of building something from scratch won over. I get it if the current batch of undergrads want to do the same: it's fun, and a great learning experience! But even though it's not quite as fun to maintain existing things, it's be great if Illinois didn't have to rewrite services like this every 5-6 years.
The Queue@Illinois still gets 10k+ pageviews /month last time I checked, so it's still a foundational piece of technology we use at Illinois and it's awesome to hear it's used other places! 🎉
Nathan and Genna did a lot of the original work on it, along with significant contributions for others (James, Jackie, James, Rittika, Shreyas, all while on CS 225 course staff), but once left my role in teaching CS 225 it was not a tool I used anymore and the new instructor of CS 225 was only interested in using it (though not maintaining it). There was a sunset plan in 2020-2021, but the department heard a number of users wanted to continue to use it and it was transferred over to the CSID team to continue maintaining it to avoid it sunsetting.
When we moved from Chara to Queue@Illinois, a number of lessons that we learned from using Chara was applied in the design of Queue and it made for a much more useful Queue. Now, 6+ years later, there's a lot of things about Queue that a new group would be able to innovate on and make it much more useful for students enrolled today (ex: there's much more hybrid learning going on post-COVID, and there's several things about the Queue that is less-than-ideal when in a hybrid office-hour setup). I think there's certainly innovations that can be applied by a new team, or could be added to the current Queue codebase. All that said, I trust Eric and his team's assessment on the best path forward since they know the resources and needs better than I have now that I'm not involved with it at all -- they've done great in keeping it running and highly available for the past 4+ years now! :)
Would it be possible for me, other UBC CS tech staff, or a co-op student to get write access to this repo? Or would it make more sense for us to just fork it? Still weighing the options.
My preference would be for you to fork it if you're in a hurry, but I think Nathan and Wade have more say over this repo than I do, although it seems I'm responsible for maintaining the fork we actually have deployed on our end right now. The maintenance fixes/features I've been working on have diverged from this repo for a while now since we'd been debating internally whether to make a big PR back here once things are all in order again. (Coincidentally, after having been too busy with other things for quite a while, I'd been spending quite a bit of time over the past two months dealing with Queue-related things. There's a good chance that whatever direction you take will conflict with what we were planning to do; which is okay, especially if you have the capacity to bring everything fully up to date in a hurry, but I don't know that we'd have enough capacity to re-integrate our fork with your work here later on in that case.)
If Eric's up for reviewing PRs, I'd encourage you to contribute back to this repository using the normal GitHub flow: fork, make a branch, PR back to this repo, rinse and repeat. Though if there's no appetite to review external contributions in this repo, a hard fork would a reasonable choice for you. It sounds like Illinois is already using a private fork; I'd just hate for development efforts to be further splintered.
I no longer have maintainer permissions for this repository, so all I can do is offer my opinions. It's a shame that Illinois folks weren't able to continue developing in the open, though I'm sure they have their valid reasons for that.
I'll give it a try, failed first try because node-sass is gone(or won't compile on my m1), and some of the typescript stuff changed, so it won't install, I'll figure it out.
For what it's worth, I do believe that the specific CVE you highlighted does not affect the old version of Next in use here, or for affected Next versions, there are some specific mitigations that have been published for that CVE that you can implement in either/both the Next app or your proxy server. But naturally there may be other risks with deploying this code. I think you'll find that bringing the versions of everything up to date will require significant rewriting (we did spend some time working towards that end already).
I spent some time looking at this. The biggest hold up (for an M1 Apple Silicon specifically) is node-sass. Once that is removed it, it will build again locally. Next.js 8 to 9 is a HUGE pain, they did away with routing in one spot, in favour of file structure implicit routing and seemingly forced ES6 imports (all not bad inherently — but tedious). I got it kinda working but it's in "a state"... Dart sass is taken care of in 9+ so that starts working eventually. Probably better use of my time to rewrite in Laravel (I know well), but it's an opportunity to learn a foreign language/framework.
Thanks for your efforts! Sounds similar to what we went through last summer. Another aspect is that the tests might need to be migrated to another library, and there were a few Illinois-made libraries being used that are no longer in development, so these are all things we intended to try to iron out. If you want to continue experimenting with it you're welcome to, but if you want to attempt a Laravel-based fork that you would feel more comfortable deploying, that might be a good option also. Some of my teammates had discussed rewriting the UI in another framework but I feel there may be unexpected issues trying a drop-in replacement. If we did attempt a full rewrite at Illinois, we'd probably deploy the new version side-by-side in beta with the old one, and ask faculty to migrate when comfortable.
In June and July I intend to try to take another stab at the legacy upgrades myself and hopefully also merge the private-fork changes we've made. (I'm not 100% certain how successful this will be but I'll make my best effort.)