You didn't mention the magic word, "taint".
Depending on how you open the file, special characters in the filename can do dodgy things.
e.g. if you passed it to a shell script, a filename of: "foo.jpg;rm -rf /" could ruin your day.
As could "../../../../../../../etc/passwd", come to think of it, if someone uploaded their own passwd file. (Oh...so it won't be running as root. In that case "../../../../../home/guest/.rhosts". Whatever. Use your imagination.)
Basically, turn on taint checking and then work out which characters you want to permit (don't try and make a list of bad characters). A reasonable policy might be alphanumeric plus a maximum of one '.' character. Maybe underscores if you feel generous :-)
One other issues you may have (but probably not, if your size limits are small) is the problem of being used as a file exchange. This problem plagues anonymous FTP servers which allow upload. If you aren't careful you end up being an exchange point for the exchange of warez and/or nasty kinds of porn. (I've seen this happen to an FTP site not far from where I am sitting).
Does this damage you? Depends on how well you are believed by your local law authorities when/if someone complains.
Your defence here is to log all transfers and/or personally inspect uploaded content before making it available on your site. Small file size limits also make this unattractive to evil-doers.
Basically this is one area where the urge to genericise your code should be resisited. You have a particular use in mind (sharing text files, uploading jpgs to perlmonks etc). If you can detect mis-use (is this a binary file? If this a valid JPG?) then you should probably try and do so...
In reply to Re: Security issues when allowing file upload via CGI