Limitar com critério post_max_size e upload_max_filesize

Em resumo: O post_max_size limita o tamanho total de um pedido POST, o upload_max_filesize o ficheiro individual; segundo o manual do PHP, os valores por defeito são 8M e 2M. Os valores têm de ser compatíveis com os limites do servidor web e da aplicação; caso contrário, os uploads falham sem uma mensagem clara. Até à atualização do PHP2Shell, o php.net aconselha post_max_size = 8M sem uploads ou 32M com uploads, com upload_max_filesize abaixo, definido de modo que as aplicações não o sobrescrevam.

Quando o formulário de candidatura de repente fica em silêncio

Depois das medidas transitórias para o PHP2Shell, muitos administradores baixaram o post_max_size. Poucos dias depois, o departamento de recursos humanos comunica que as candidaturas já não chegam. O formulário limita-se a voltar a carregar, sem qualquer mensagem de erro. A razão: o pedido com três anexos em PDF era maior do que o novo limite, e o PHP descartou os dados do formulário.

O exemplo mostra o problema de fundo. Os limites de upload atuam em vários pontos em simultâneo, e cada ponto reage de forma diferente quando é excedido. Quem conhece a cadeia consegue definir os valores de modo que protejam sem perturbar a operação. Como o PHP processa uploads internamente é explicado em Como o PHP processa uploads de ficheiros; a programação segura de funções de upload é descrita em Implementar uploads de ficheiros em PHP com segurança.

A cadeia de limites de upload

Um pedido atravessa vários limites antes de a aplicação o ver. As indicações seguintes provêm das documentações do Nginx, do Apache e do PHP:

Daqui resulta uma regra simples: upload_max_filesize menor do que post_max_size, e post_max_size menor do que o limite no servidor web. O manual do PHP recomenda ainda que o memory_limit seja, em geral, maior do que o post_max_size. Durante a medida transitória do PHP2Shell com memory_limit=-1, esse papel é assumido pelo limite através de contentor ou cgroup; mais informação em Definir corretamente o memory_limit.

post_max_size após o PHP2Shell: o que recomenda o php.net

No comunicado de segurança de 21/10/2026, o php.net indica, para servidores sem atualização, limites baixos de pedidos como uma das medidas transitórias. Reduzem o risco de alguns caminhos de ataque, mas expressamente não são uma proteção completa:

1. Sem uploads de ficheiros: post_max_size = 8M.
2. Com uploads de ficheiros: post_max_size = 32M.
3. Em ambos os casos: manter upload_max_filesize abaixo de post_max_size.
4. Considerar adicionalmente: limites no servidor web ou no proxy para o tamanho descodificado do pedido, o número de campos de entrada, o número de partes multipart, o número de linhas de cabeçalho e a profundidade de aninhamento. Segundo o php.net, estes limites têm de abranger também pedidos sem indicação Content-Length utilizável.

Os valores pertencem a um sítio onde as aplicações não os possam sobrescrever. Como o post_max_size e o upload_max_filesize podem, segundo o manual, ser alterados ao nível do diretório, um .user.ini ou, com mod_php, um .htaccess poderiam voltar a aumentá-los:

; Pool FPM do site, com uploads (fase transitória até à atualização)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5

No servidor web, fixe o limite ligeiramente acima, para que os pedidos demasiado grandes nem sequer cheguem ao PHP:

# Nginx, no bloco server ou location
client_max_body_size 32m;

# Apache, no VirtualHost: 32 MiB em bytes
LimitRequestBody 33554432

Depois, recarregue todos os workers PHP e o servidor web. A visão geral de todas as medidas transitórias está em Medidas imediatas, quando ainda não pode aplicar o patch. Se e como os pedidos de upload podem ser filtrados adicionalmente no proxy é analisado em Filtrar pedidos de upload na periferia.

Determinar o valor certo para o seu site

Em vez de valores generalizados, vale a pena fazer um breve levantamento. Liste todos os formulários com uploads e anote o maior ficheiro legítimo e o maior número de ficheiros em simultâneo. Daí resulta a necessidade: o upload_max_filesize cobre o maior ficheiro individual, o post_max_size a soma de todos os ficheiros de um pedido mais alguma reserva para os campos de formulário.

Se a necessidade for superior a 32M, não é compatível com a recomendação transitória do php.net. Isso é mais uma razão para antecipar a atualização. Os uploads grandes podem também ser tratados através de um subdomínio próprio com pool próprio, para que o resto do site mantenha limites estreitos.

Depois da atualização para 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou um backport confirmado, pode voltar a ajustar os valores à necessidade real. Ainda assim, não devem ser mais generosos do que o necessário: cada limite que excede a necessidade aumenta a superfície de ataque sem benefício. Se um site não precisar de uploads, file_uploads = Off é a solução mais limpa.

Interpretar corretamente os padrões de erro

Quando os uploads falham, o comportamento revela que limite está a atuar. Uma página com erro 413 vem do servidor web. Um formulário que volta a carregar sem mensagem ou que comunica «pedido inválido» aponta para dados $_POST vazios, ou seja, o post_max_size. Uma mensagem da aplicação sobre um único ficheiro corresponde ao upload_max_filesize. E campos em falta em formulários muito grandes, por exemplo com variantes de produtos, apontam para o max_input_vars. O registo de erros do PHP contém, em regra, quando o post_max_size é excedido, um aviso com o tamanho do pedido.

Para que os utilizadores não fiquem sem saber o que fazer, a aplicação deve reconhecer o caso. O manual do PHP propõe para isso um caminho simples: o formulário passa um marcador no endereço, por exemplo ?processed=1. Se esse marcador chegar, mas $_POST e $_FILES estiverem vazios, o pedido era demasiado grande e a aplicação pode mostrar uma mensagem compreensível com o tamanho permitido.

Como ajuda concretamente a PHP SOS?

• Registamos todos os caminhos de upload dos seus sites e determinamos os tamanhos realmente necessários.
• Definimos de forma coerente os limites do servidor web, do PHP e dos pools, bloqueados contra sobrescrita, incluindo os valores transitórios do php.net.
• Testamos formulários, importações e uploads após a alteração e ajustamos os valores de forma dirigida.
• No âmbito do reforço de segurança de servidores, repomos os valores, após a atualização, na necessidade permanente.

Perguntas frequentes

Fontes

• php.net: comunicado de segurança de 21/10/2026
• Manual do PHP: definições do núcleo (post_max_size)
• Documentação do Nginx: client_max_body_size
• Documentação do Apache: LimitRequestBody