A Debian bug report [1],[2] indicated that feh is vulnerable to an
arbitrary file overwrite flaw.  If a user could guess the PID of the feh
process and create a symlink in /tmp, they could cause the overwrite of any
file that the user running feh has write access to via wget overwriting the file.  In
src/imlib.c we have:

235 char *feh_http_load_image(char *url)
236 {
237     char *tmpname;
238     char *basename;
239     char *path = NULL;
240 
241     if (opt.keep_http) {
242         if (opt.output_dir)
243             path = opt.output_dir;
244         else 
245             path = "";
246     } else
247         path = "/tmp/";
248
249     basename = strrchr(url, '/') + 1;
250     tmpname = feh_unique_filename(path, basename);
...
455             execlp("wget", "wget", "--cache=off", "-O", tmpname, url, quiet, NULL);

and in src/utils.c we have:

162 char *feh_unique_filename(char *path, char *basename)
163 {
...
170 
171     /* Massive paranoia ;) */
172     if (i > 999998)
173         i = 1;
174 
175     ppid = getpid();
176     snprintf(cppid, sizeof(cppid), "%06ld", (long) ppid);
177 
178     /* make sure file doesn't exist */
179     do {
180         snprintf(num, sizeof(num), "%06ld", i++);
181         tmpname = estrjoin("", path, "feh_", cppid, "_", num, "_", basename, NULL);
182     }
18     while (stat(tmpname, &st) == 0);
184     return(tmpname);
185 }

feh_unique_filename() has some attempt at randomness, but I don't think it's enough.  i always starts at 1, so unless the same process is creating multiple temporary files, you're almost guaranteed to have that extra randomness being '1'; it's also just as easy to create a bunch of symlinks to account for the "randomness" provided you know the PID.  Using mkstemp would be a much better solution.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612035
[2] https://bugs.launchpad.net/ubuntu/+source/feh/+bug/607328