By giving the file an automatically generated name that the user can't influence, you have already avoided the worst issues.
Theoretically, it should not be possible to hack your server this way, since your server should not run any code in PNG files. Unfortunately, it is really easy to misconfigure nginx to do so. The correct solution to this is to configure nginx correctly, of course. You could attempt to do some filtering (e.g. detect <?php, but that risks false positives, i.e. legitimate images being rejected). I would maybe put a note into the documentation that people installing your software on nginx should really follow the instructions provided with the server and check for this issue, and wouldn't worry about it further. Note that it is possible to create a perfectly valid PNG file that does contain PHP code, so simply checking that the file is a valid image does not help here.
Now, to attacks against clients. Your server will (hopefully) serve the files with the correct MIME type. This should keep browsers from running it as code. Unfortunately, certain browsers (also known as "Internet Explorer") are dumb and try to guess the file type anyways. This will not hurt your server directly, but can cause user accounts of users using these browsers to get compromised. Thus, you may want to check the file type. If you can, serve all files with nosniff headers (e.g. by setting a corresponding htaccess or by serving them through fpassthru after setting the headers).
By loading and re-saving the image, you can make (more or less) sure that anything "nasty" in the image is gone. On the other hand, if someone finds an exploitable bug in your image library, they can hack your server, so it isn't without risk.