Superglobais: $_GET, $_POST, $_FILES e outras

Em resumo: As superglobais são arrays predefinidos que o PHP preenche automaticamente a cada pedido e que estão disponíveis em todo o código. O $_GET contém os parâmetros do endereço, o $_POST os dados do formulário, o $_FILES os ficheiros carregados, o $_COOKIE os cookies e o $_SERVER indicações sobre o pedido e o servidor. O PHP cria estes arrays antes de o código da sua aplicação arrancar. Por isso, as falhas precisamente neste processamento, como no PHP2Shell, não podem ser travadas por verificações na aplicação.

O que são superglobais?

No PHP, uma variável normalmente só vale na função em que foi criada. As superglobais são a exceção: estão disponíveis em qualquer âmbito, sem ser preciso obtê-las com global. O manual do PHP refere nove.

Para quem não é técnico, pode descrever-se assim: as superglobais são a caixa de correio da aplicação. Tudo o que um visitante envia vai parar lá antes de a aplicação o ler. E tudo o que está na caixa de correio provém potencialmente de um desconhecido.

As superglobais em resumo

Particularmente traiçoeiro é o $_SERVER. Segundo o manual, o PHP cria para cada cabeçalho do pedido uma entrada que começa por HTTP_, por exemplo HTTP_USER_AGENT. Estes valores são definidos pelo próprio cliente. Também o SERVER_NAME pode, segundo o manual, conter o nome de anfitrião fornecido pelo cliente e não é fiável para decisões de segurança.

Como o PHP preenche as superglobais

Antes de o primeiro carácter do seu script ser executado, o PHP já trabalhou. Lê o endereço, os cabeçalhos e o conteúdo do pedido, decompõe-os e guarda os resultados nos arrays. Várias definições controlam este passo:

1. variables_order (por defeito EGPCS) determina que superglobais são sequer criadas: Environment, GET, POST, Cookie, Server.
2. request_order (por defeito vazio) determina de onde é formado o $_REQUEST. Se estiver vazio, vale variables_order. Os ficheiros php.ini fornecidos omitem os cookies, segundo o manual, por razões de segurança.
3. max_input_vars (por defeito 1000) e max_input_nesting_level (por defeito 64) limitam o número e o encadeamento das variáveis de entrada.
4. post_max_size (por defeito 8M) limita o conteúdo do pedido. Se um pedido for maior, $_POST e $_FILES ficam vazios.
5. enable_post_data_reading (por defeito ligado) controla se o PHP avalia sequer automaticamente o conteúdo dos pedidos POST.

Se enable_post_data_reading estiver desligado, a aplicação lê ela própria o conteúdo bruto através de php://input. Desde o PHP 8.4.0 existe ainda o request_parse_body(), que avalia dados de formulário e de upload também para outros métodos que não o POST e permite valores-limite próprios. Como decorre em pormenor a parte dos uploads explica-o a página Como o PHP processa os uploads de ficheiros.

Lidar com segurança com os dados do pedido

O princípio é simples: cada valor de $_GET, $_POST, $_COOKIE, $_FILES e das entradas HTTP_ de $_SERVER é uma entrada alheia. É verificado na receção e escapado de forma adequada na saída.

<?php
declare(strict_types=1);

// Espera-se um número inteiro: verificar em vez de converter às cegas
$seite = filter_var($_GET['seite'] ?? '1', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 500],
]);
if ($seite === false) {
    http_response_code(400);
    exit('Ungültige Seitenzahl');
}

// Permitir apenas valores autorizados
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Escapar sempre a saída
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Um obstáculo frequente são as indicações sobre a origem de um pedido. Se à frente do servidor web estiver um reverse proxy, um load balancer ou uma CDN, o $_SERVER['REMOTE_ADDR'] contém o endereço desse intermediário, não o do visitante. O endereço real consta então de um cabeçalho como X-Forwarded-For, que, no entanto, qualquer cliente pode definir. A aplicação só pode avaliar esses cabeçalhos se o pedido vier comprovadamente de um proxy próprio e conhecido. Caso contrário, os bloqueios por endereço IP ou os registos podem ser facilmente enganados. O mesmo vale para HTTPS: se a cifragem termina no proxy, a aplicação tem de saber expressamente que a ligação original era cifrada.

Outros modelos de validação e filtragem mostra-os o artigo Validar e filtrar entradas em PHP. Para os dados de sessão em $_SESSION valem regras próprias; constam da página Sessões e cookies em PHP.

Superglobais e PHP2Shell: o que acontece antes do seu código

Aqui está a ligação à situação atual. O CVE-2026-109618 descreve que uma condição de falta de memória pode interromper o PHP enquanto os dados do pedido estão apenas parcialmente inicializados; na limpeza do pedido, dados inválidos podem então ser tratados como válidos. No CVE-2026-109619, o estado interno de um pedido pode persistir depois de a memória ser libertada e ser utilizado por um pedido posterior no mesmo worker.

Ambas as vulnerabilidades estão, assim, no processamento que o próprio PHP faz em torno do pedido, não no código da aplicação. A equipa do PHP classifica o risco como o mais elevado no mod_php; aí foi demonstrado um exploit antes de qualquer código de aplicação correr. Nenhum filter_var() e nenhuma verificação na aplicação o pode impedir.

Como ajuda concretamente a PHP SOS?

• Verificamos os valores-limite efetivos para os dados do pedido por site e definimo-los de forma adequada à aplicação.
• Aplicamos a atualização do PHP, reiniciamos todos os workers e comprovamos o nível de patches no âmbito do nosso serviço de patches PHP.
• Verificamos nos desenvolvimentos próprios se valores de superglobais chegam sem verificação à base de dados, ao sistema de ficheiros ou à saída.
• Guardamos os logs do servidor web a partir de 20/10/2026, para que uma análise posterior continue a ser possível.

Perguntas frequentes

Fontes

• Manual do PHP: superglobais
• Manual do PHP: $_SERVER
• Manual do PHP: diretivas do php.ini
• Manual do PHP: request_parse_body