You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: Minimal reproduction for router.use() sub-app prototype corruption (#7427) #7490
This is a minimal, runnable reproduction for issue #7427.
When an express() sub-app is mounted via router.use() instead of app.use(), the req and res prototypes are swapped by app.handle but never restored when the sub-app calls next().
As a result, any middleware that runs after the sub-app finishes will silently inherit the sub-app's configuration (like trust proxy) instead of the parent app's configuration.
Expected Behavior
After a sub-app mounted on a router calls next(), the req prototype should be restored so subsequent middleware uses the parent app's settings.
Reproduction Script
constexpress=require('express');constapp=express();constrouter=express.Router();constsubApp=express();// Parent app does NOT trust proxyapp.set('trust proxy',false);// Sub app DOES trust proxysubApp.set('trust proxy',true);subApp.use((req,res,next)=>{// Do nothing, just pass back to the parent routernext();});// BUG TRIGGER: Mounting subApp via router instead of app.userouter.use('/test',subApp);app.use(router);app.use('/test',(req,res)=>{// Expected: false (Parent app setting)// Actual: true (Leaked sub-app setting!)res.json({isProxyTrusted: req.app.get('trust proxy')});});app.listen(3000,()=>{console.log('Listening on 3000. Run: curl http://localhost:3000/test');});SystemInfo
Express version: 4.21.2Node.js version: 20.x
OS: MacOS
Hi! I'd like to work on this issue. I understand the bug: when a sub-app is mounted via router.use() instead of app.use(), the req and res prototypes are swapped by app.handle but never restored when the sub-app calls next(), causing the parent's settings (like trust proxy) to leak.
I'll investigate app.handle and add a test to verify the fix. Could I be assigned to this issue? Thanks!
Thanks for the reproducer @garv-sanveria. Usually when you have something to add that is related to an existing issue (such as a minimised reproducer) this should be done in that issue to make it easier to find. There is (at least) one reproducer that is not public (it was reported in a rejected security advisory), but this may be useful to others.
I'll close this as a duplicate, but feel free to add a comment with your reproducer to #7427. That being said, my personal opinion is that #7427 is not a bug, because such configuration is simply not supported.
@dimitrimbesseu-arch in general, we don't assign people to issues. If you see an issue that you can solve, please check if there are no related PRs and then open yours (if solving such issue requires code changes). In this case there already is one (and another that was closed as a duplicate) and the issue may not be something that we consider an issue (this is still open for discussion).
Activity
dimitrimbesseu-arch commentedon Sep 27, 2026
Hi! I'd like to work on this issue. I understand the bug: when a sub-app is mounted via router.use() instead of app.use(), the req and res prototypes are swapped by app.handle but never restored when the sub-app calls next(), causing the parent's settings (like trust proxy) to leak.
I'll investigate app.handle and add a test to verify the fix. Could I be assigned to this issue? Thanks!
krzysdz commentedon Sep 27, 2026
Thanks for the reproducer @garv-sanveria. Usually when you have something to add that is related to an existing issue (such as a minimised reproducer) this should be done in that issue to make it easier to find. There is (at least) one reproducer that is not public (it was reported in a rejected security advisory), but this may be useful to others.
I'll close this as a duplicate, but feel free to add a comment with your reproducer to #7427. That being said, my personal opinion is that #7427 is not a bug, because such configuration is simply not supported.
@dimitrimbesseu-arch in general, we don't assign people to issues. If you see an issue that you can solve, please check if there are no related PRs and then open yours (if solving such issue requires code changes). In this case there already is one (and another that was closed as a duplicate) and the issue may not be something that we consider an issue (this is still open for discussion).