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
Raw error objects leaked in 500 responses across several controllers #3898
Multiple catch blocks in server controllers send the raw err object
straight into res.json(). This means stack traces, mongoose internals,
and whatever else lives on the error can end up in the response body.
server/controllers/user.controller/userPreferences.ts L36, L64 → same
server/controllers/user.controller/authManagement.ts L204 → same
server/controllers/user.controller/helpers.ts L70 → res.status(500).json({ error }) (shared saveUser helper, so this one fans out)
server/controllers/project.controller.js L349 → res.status(500).json(error) — the error is the response body, no wrapping at all
Why the global error handler doesn't help here:
The fallback at server.js L199 sends a safe generic string, but it
only fires for errors passed through next(). All the spots above call res.json() directly and never hit next(),..so the middleware is
completely bypassed.
Expected Behavior
500s should return something like { error: "Internal Server Error" }
and the real error should just be console.error'd
Steps to reproduce
Trigger any DB error in the affected routes (e.g., kill mongo mid-request, send malformed data to /preferences, etc). Check the network tab, you'll see the full error object with stack trace in the response body instead of a sanitized message
@Iron-56 anything that triggers a mongoose validation error. Send { preferences: "garbage" } to /preferences, or just throw an error before user.save() in any of those catch blocks and curl the endpoint. You'll see the stack in the response
Hi, I looked at this against the current develop branch. Most of the spots listed here already return a generic message now, the one that still sends the raw error straight back is changeProjectVisibility in project.controller.js. Since it has been a while since the last update, I am going to open a small PR for that one with a test, unless @avinxshKD already has something in progress.
Activity
avinxshKD commentedon Feb 16, 2026
@raclim hey can I take a crack at this? pls assign
kitlord commentedon Feb 18, 2026
May I know what property did you change in preferences to reproduce it?
avinxshKD commentedon Feb 18, 2026
@Iron-56 anything that triggers a mongoose validation error. Send { preferences: "garbage" } to /preferences, or just throw an error before user.save() in any of those catch blocks and curl the endpoint. You'll see the stack in the response
ksen0 commentedon Sep 18, 2026
Thanks for reporting, sorry it took a while to get to this one! @avinxshKD if you want to take it on, please feel free to make a PR.
(If @avinxshKD doesn't claim this in the next week, it's open to volunteers. Thanks in advance!)
boluwatifeajayi commentedon Oct 19, 2026
Hi, I looked at this against the current develop branch. Most of the spots listed here already return a generic message now, the one that still sends the raw error straight back is
changeProjectVisibilityinproject.controller.js. Since it has been a while since the last update, I am going to open a small PR for that one with a test, unless @avinxshKD already has something in progress.Do not send the raw error from changeProjectVisibility