Se o nome do arquivo não depender da entrada do usuário, haverá pouco risco. Se estiver, você precisa ter certeza de que a parte dependente do usuário está bem higienizada, removendo todos os caracteres potencialmente perigosos, como., Ou.
Outros mencionaram um possível DOS preenchendo o disco; mas você também corre esse risco com um banco de dados.
Existe então outro risco, que não é uma vulnerabilidade em si, mas poderia servir como um. O invasor pode usar esse método para criar conteúdo de sua escolha no servidor e usá-lo para explorar uma vulnerabilidade executando-a. Mais comumente, o problema se apresenta se você permitir que o usuário crie um arquivo .php e permita que ele seja acessado pelo servidor. O usuário só precisa abrir o link para fazer o que quiser.
A maneira mais segura de evitar esse problema é colocar todos os arquivos enviados fora do diretório do servidor. Isso significa que você deve servir os arquivos através de um script próprio, não diretamente para o exterior. Geralmente no Unix você tem seus scripts php sob / var / www / html. Basta você escrever um script em / var / www / uploads, por exemplo, e não há como o servidor web ir até lá, a menos que você tenha feito algo estúpido com o seu httpd.conf.
Se você não puder controlar isso, use um .htaccess para limitar o acesso a esse diretório específico e / ou certifique-se de que os arquivos não possam ser executados como PHP ou inclusões do lado do servidor (.shtml) sempre anexando um extensão segura, como .html ou .txt.