Skip to content

Raw error objects leaked in 500 responses across several controllers #3898

Closed

Description

@avinxshKD

p5.js version

No response

What is your operating system?

None

Web browser and version

No response

Actual Behavior

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.

Affected spots:

  • server/controllers/user.controller/signup.ts L79, L161 → res.status(500).json({ error: err })
  • 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

Activity

  1. avinxshKD commented on Feb 16, 2026

    @avinxshKD
    ContributorAuthor

    @raclim hey can I take a crack at this? pls assign

  2. kitlord commented on Feb 18, 2026

    @kitlord
    Contributor

    May I know what property did you change in preferences to reproduce it?

  3. avinxshKD commented on Feb 18, 2026

    @avinxshKD
    ContributorAuthor

    @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

  4. added
    Help WantedWould love additional input or contributions!
    and removed on Sep 18, 2026
  5. ksen0 commented on Sep 18, 2026

    @ksen0
    Member

    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!)

  6. boluwatifeajayi commented on Oct 19, 2026

    @boluwatifeajayi
    Contributor

    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.

  7. added a commit that references this issue on Nov 1, 2026
    92b7719
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugError or unexpected behaviorsHelp WantedWould love additional input or contributions!

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions