Comment 7 for bug 2004580

You're of course correct in principle, but the trouble here is that this is a vulnerability that's very hard to counter using OS limits/profiles or ImageMagick profiles, because you need to write user input to some location on the file system in order to process it, and so at least that file system location is automatically vulnerable to exfiltration, because the ImageMagick process must be allowed to read it to load the uploaded image.

On top of that, I for instance work for a platform provider where we can't even know ahead of time what filesystem location a customer's code (or the library/framework they're using) will use for e.g. uploaded file storage - is it /tmp, is it somewhere else - so it's not feasible to lock down paths using an ImageMagick policy in a way that doesn't break countless existing customers.