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
While testing Keystone for a production website, we noticed that multer is used to parse uploaded files in POST data on all requests, saving the file(s) to /tmp. Depending on where /tmp is located on the system, this could result in a denial of service. This happens on all requests, even if file data isn't expected by the application.
Preferably, configuring the multer middleware (or, better yet, busboy) would be left to the application.
Looking at this more closely, I see that this is an old issue, #3597. We don't use any of the local file or image types, so my temporary solution is to simply comment out the initialization of multer.
What work is remaining to fix this properly? Would a stopgap solution (eg. only calling multer on pre-authenticated admin API requests) be acceptable?
@zzxc Our last look into multer yielded the results of #3175, which isn't ideal. Essentially, the rearchitecting necessary to resolve this is beyond our current scope. If you find a stopgap method that helps you and want to contribute it back, that would be great.
While testing Keystone for a production website, we noticed that multer is used to parse uploaded files in POST data on all requests, saving the file(s) to /tmp. Depending on where /tmp is located on the system, this could result in a denial of service. This happens on all requests, even if file data isn't expected by the application.
Preferably, configuring the multer middleware (or, better yet, busboy) would be left to the application.
Steps to reproduce:
I tested with Keystone v0.3.22.
The text was updated successfully, but these errors were encountered: