Glossário: PHP e segurança informática

125 termos técnicos em linguagem clara, cada um com ligação à página especializada correspondente.

#A B C D E F G H I J K L M N O P R S T U V W X Z

#

2FA: A 2FA (autenticação de dois fatores) exige, além da palavra-passe, uma segunda prova no início de sessão, por exemplo um código de uma aplicação ou uma chave de segurança. Uma palavra-passe roubada deixa de bastar. Para todos os acessos de administração a CMS, painéis de alojamento e servidores, a 2FA deve ser a norma. Configurar a autenticação de dois fatores para acessos de administração →
3-2-1-Backup: A regra 3-2-1 recomenda três cópias dos dados em dois suportes de armazenamento diferentes, uma delas num local distinto. Pelo menos uma cópia deve ser imutável a partir do servidor, para que os atacantes não a possam apagar nem cifrar. Uma cópia de segurança só conta quando a recuperação foi testada. Estratégia de backup para servidores: backups segundo a regra 3-2-1 →

A

Apache: O Apache HTTP Server é um dos servidores web mais antigos e mais difundidos. O PHP corre nele como módulo (mod_php) ou através do PHP-FPM por FastCGI. Com ficheiros .htaccess, a configuração pode ser ajustada por diretório. Proteger o Apache com mod_php →
AVV: Um AVV (contrato de subcontratação do tratamento de dados, Auftragsverarbeitungsvertrag) nos termos do Art. 28 do RGPD é necessário quando um prestador de serviços trata dados pessoais por conta de outrem ou pode aceder a eles. Isto aplica-se muitas vezes também a fornecedores de alojamento, agências e prestadores de TI com acesso ao servidor. O contrato regula, entre outros aspetos, instruções, medidas de proteção e vias de notificação. Subcontratação de dados quando prestadores acedem a servidores →

B

Backdoor: Um backdoor (porta dos fundos) é um acesso oculto através do qual os atacantes podem regressar depois de uma intrusão. Pode ser um ficheiro, uma conta de administrador, um cronjob ou uma chave SSH. Por isso, qualquer limpeza inclui a procura de todos os tipos de acessos, e não apenas de ficheiros. Encontrar backdoor no WordPress: detetar backdoors de forma sistemática →
Backport: Um backport transfere uma correção de segurança para uma versão mais antiga de um programa, sem mudar para a versão nova. As distribuições Linux e os fornecedores de alojamento fazem-no com frequência; o número de versão apresentado mantém-se então igual. Se um backport está instalado, demonstram-no o changelog do pacote e a confirmação do fornecedor, não o número. Atualização do PHP ou backport? A decisão para sistemas antigos →
Beweissicherung: A preservação de provas significa assegurar os vestígios de um incidente antes de se perderem por limpeza, reinício ou reinstalação. Incluem-se ficheiros de registo, imagens de suportes de dados e, conforme o caso, a memória. Depois do PHP2Shell, a imprensa especializada aconselha a conservar os registos do servidor desde 20/10/2026. Preservar provas antes de reinstalar o servidor →
Brute Force: Num ataque de força bruta (brute force), o atacante experimenta de forma automatizada muitas palavras-passe para uma conta. Os alvos são muitas vezes inícios de sessão de administração de CMS, SSH ou FTP. A proteção está em palavras-passe fortes, autenticação de dois fatores e bloqueios automáticos como o Fail2ban. Proteger logins de administração contra brute force: proteção para qualquer login →
BSI: O BSI (Bundesamt für Sicherheit in der Informationstechnik, Gabinete Federal Alemão para a Segurança da Informação) é a autoridade federal alemã de cibersegurança. Publica avisos, recomendações e normas como o IT-Grundschutz. Sobre o PHP2Shell, o BSI declarou o nível de alerta 3 (laranja) e recomendou a atualização imediata. O que o BSI recomenda sobre o PHP2Shell →

C

CDN: Uma CDN (Content Delivery Network) entrega conteúdos através de muitos servidores distribuídos e fica, assim, à frente do site propriamente dito. Muitas CDNs oferecem também regras de WAF, por exemplo a Cloudflare contra o PHP2Shell. A proteção só atua sobre o tráfego que passa pela CDN e não substitui uma atualização do PHP. Regras de proteção da Cloudflare contra o PHP2Shell: o que conseguem e o que não →
CERT-Bund: O CERT-Bund é a equipa de resposta a emergências informáticas (CERT) da administração federal alemã, integrada no BSI. Publica serviços de aviso e de informação sobre vulnerabilidades e notifica os operadores de redes sobre sistemas vulneráveis. Também sobre o PHP2Shell o CERT-Bund emitiu um aviso. O que o CERT-EU e o CERT-Bund recomendam sobre o PHP2Shell →
CERT-EU: O CERT-EU é a equipa de cibersegurança para as instituições, órgãos e agências da União Europeia. Segundo relatórios, o CERT-EU considera possível que, no caso do PHP2Shell, estejam afetadas versões a partir do PHP 5. Aconselha a isolar as aplicações acessíveis publicamente se não puderem receber o patch em tempo útil. O que o CERT-EU e o CERT-Bund recomendam sobre o PHP2Shell →
CGI: O CGI (Common Gateway Interface) é uma interface antiga em que o servidor web inicia um programa externo para cada pedido e devolve o seu resultado. É simples, mas lento, e foi em grande parte substituído pelo FastCGI no caso do PHP. Ainda se encontram configurações CGI antigas em alguns sistemas de alojamento e em Windows. CGI e FastCGI: os fundamentos →
cgroups: Os cgroups (Control Groups) são uma funcionalidade do kernel Linux que permite limitar memória, CPU e outros recursos para grupos de processos. Os contentores e o systemd utilizam-nos, por exemplo com MemoryMax. Como medida provisória contra o PHP2Shell, o php.net recomenda um limite de memória através de contentor ou cgroup, em vez de RLIMIT_AS ou RLIMIT_DATA. Definir limites de memória com systemd e cgroups →
Chain of Custody: A cadeia de custódia documenta sem lacunas quem preservou, entregou e tratou um meio de prova e quando. Complementada por somas de verificação, demonstra que os dados não foram alterados. Sem esta documentação, os vestígios perdem valor em tribunal ou perante as seguradoras. Perícia forense informática após um ataque a um servidor web →
Changelog: Um changelog lista as alterações de uma versão de um programa ou pacote, no caso das correções de segurança normalmente com o número CVE. No Debian e no Ubuntu, apt-get changelog mostra o changelog do pacote; na família RHEL, rpm -q --changelog. Assim é possível comprovar um backport mesmo com o mesmo número de versão. Comprovar números CVE no changelog do pacote →
CLI: CLI (Command Line Interface) é o PHP na linha de comandos, por exemplo para cronjobs, comandos de consola de CMS e o Composer. O PHP da CLI pode ser uma versão diferente da que serve as páginas web. O comando php -v mostra por isso apenas a versão da linha de comandos; ambas as vias têm de ter o patch aplicado. O PHP na linha de comandos (CLI) →
CloudLinux: O CloudLinux é uma distribuição Linux para alojamento partilhado que separa os clientes em ambientes limitados. Com o alt-php, disponibiliza lado a lado muitas versões do PHP, incluindo mais antigas. Cada uma dessas versões tem de ter o patch aplicado individualmente. CloudLinux e alt-php: o que os clientes de alojamento devem saber →
Command Injection: Na command injection, entradas chegam sem validação a um comando de sistema que a aplicação executa. O atacante pode assim iniciar comandos próprios com os direitos do servidor web. A proteção está em evitar chamadas à shell sempre que possível e em escapar de forma consistente com escapeshellarg(). Evitar Command Injection em PHP →
Composer: O Composer é o gestor de pacotes do PHP. Instala bibliotecas de acordo com as indicações em composer.json e regista as versões exatas em composer.lock. Com composer audit é possível verificar os pacotes instalados quanto a vulnerabilidades conhecidas; as vulnerabilidades no próprio PHP, o comando não as encontra. Composer: o gestor de pacotes do PHP →
Container: Um contentor é um ambiente de execução isolado que inicia uma aplicação com todas as dependências a partir de uma imagem, por exemplo com Docker. O PHP no contentor vem da imagem, não do sistema anfitrião. Uma atualização no anfitrião não lhe aplica por isso o patch; a imagem tem de ser reconstruída e o contentor reiniciado. Operar PHP em contentores →
cPanel: O cPanel é um painel de gestão para alojamento web, com o WHM como interface para o administrador do servidor. As versões do PHP são aí normalmente disponibilizadas através de pacotes próprios (EasyApache). Quais as compilações com patch, confirmam-no o estado do pacote e o fornecedor. cPanel e WHM: proteger o PHP →
Credential Stuffing: No credential stuffing, os atacantes experimentam credenciais de fugas de dados anteriores noutros serviços. Funciona porque muitas pessoas reutilizam palavras-passe. A proteção está em palavras-passe únicas por serviço e na autenticação de dois fatores. Configurar a autenticação de dois fatores para acessos de administração →
CSP: A CSP (Content Security Policy) é um cabeçalho que define de que origens uma página pode carregar scripts, imagens e outros conteúdos. Dificulta o XSS e a introdução de scripts alheios, por exemplo no skimming. Uma CSP rigorosa tem de ser testada com cuidado para que o site continue a funcionar. Security headers para sites: definir corretamente os cabeçalhos de segurança →
CSRF: O CSRF (Cross-Site Request Forgery) leva o navegador de um utilizador autenticado a desencadear, sem querer, uma ação noutro site. São típicas as alterações em áreas de administração. A proteção está nos tokens aleatórios em formulários e nos cookies com o atributo SameSite. Proteção CSRF em aplicações PHP →
CVE: O CVE (Common Vulnerabilities and Exposures) é um catálogo de uso mundial que atribui um número único a cada vulnerabilidade de segurança conhecida, por exemplo CVE-2026-109618. O número torna comparáveis os avisos de fabricantes, autoridades e distribuições. Através do número CVE é também possível verificar no changelog do pacote se uma correção foi instalada. Comprovar números CVE no changelog do pacote →
CVSS: O CVSS (Common Vulnerability Scoring System) avalia a gravidade de uma vulnerabilidade numa escala de 0 a 10. A avaliação considera, por exemplo, se um ataque é possível através da rede e sem autenticação. As vulnerabilidades do PHP2Shell têm, cada uma, CVSS v4.0 de 9,2; o valor, por si só, nada diz sobre o risco concreto no seu ambiente.
Cyberversicherung: Um ciberseguro cobre, consoante o contrato, custos após um ataque, por exemplo de perícia forense, recuperação ou interrupção de atividade. Muitos contratos contêm obrigações, como atualizações em tempo útil e comunicação imediata do sinistro. O que se aplica em cada caso, esclareça-o com a sua seguradora. Seguro ciber: o que conta em caso de sinistro →

D

DDoS: Um ataque DDoS (Distributed Denial of Service) sobrecarrega um serviço com pedidos de muitas origens até deixar de estar acessível. Em regra, os dados não são roubados. Um DDoS deve distinguir-se de um exploit, que explora especificamente uma vulnerabilidade. DDoS ou ataque informático? Classificar bem os ataques →
Defacement: No defacement, os atacantes alteram de forma visível a página inicial ou os conteúdos de um site, por exemplo com mensagens ou imagens. É chamativo, mas muitas vezes é apenas o sinal visível de uma intrusão mais profunda. O site deve ser tratado como comprometido até esclarecimento. Site comprometido, o que fazer? Assistência de emergência remota →
Deserialisierung: A desserialização converte dados guardados de volta em objetos, no PHP por exemplo com unserialize(). Se os dados provêm de utilizadores, os atacantes podem construir objetos de tal forma que, ao serem carregados, corre código indesejado. Para dados de utilizadores, o JSON é a escolha mais segura. Desserialização insegura em PHP: unserialize e segurança →
disable_functions: O disable_functions é uma definição do php.ini com a qual se desativam funções PHP individuais, normalmente as que executam comandos do sistema. Só pode ser definida no php.ini, não no código da aplicação. Dificulta a vida aos atacantes, mas não substitui nem as atualizações nem permissões bem configuradas. Usar corretamente o PHP disable_functions →
display_errors: O display_errors define se o PHP mostra as mensagens de erro diretamente no navegador. Em produção, o valor deve estar em Off; os erros são, em vez disso, escritos num registo com log_errors. As mensagens visíveis revelam, de outro modo, caminhos, versões e excertos de código. display_errors off: desativar a saída de erros em produção →
DSGVO Art. 33: O Art. 33 do RGPD obriga os responsáveis pelo tratamento a notificar uma violação da proteção de dados pessoais à autoridade de controlo competente, se possível no prazo de 72 horas após o conhecimento. A obrigação só não se aplica se for improvável que a violação resulte num risco para os titulares dos dados. Em cada caso concreto, aconselham os encarregados da proteção de dados ou os advogados. Dever de notificação segundo o RGPD: 72 horas após o incidente →
DSGVO Art. 34: O Art. 34 do RGPD regula a comunicação aos próprios titulares dos dados afetados. É necessária quando é provável que uma violação de dados resulte num elevado risco para os seus direitos e liberdades. Se tal se verifica, deve ser avaliado com encarregados da proteção de dados ou advogados. Dever de notificação segundo o RGPD: 72 horas após o incidente →

E

EDR: O EDR (Endpoint Detection and Response) é software em servidores e postos de trabalho que observa processos, acessos a ficheiros e ligações de rede e comunica ou interrompe comportamentos suspeitos. Em servidores web, pode reconhecer, por exemplo, que o PHP-FPM inicia uma shell. Como para o PHP2Shell não existem IOCs confirmados, esta análise de comportamento é particularmente importante. Sinal de alerta: o servidor web inicia uma shell →
Embargo: Um embargo é o prazo acordado durante o qual os detalhes de uma vulnerabilidade permanecem confidenciais até haver patches disponíveis. Assim, fabricantes e distribuições podem preparar atualizações. No caso do PHP2Shell, segundo vários relatórios, os detalhes tornaram-se públicos antes do fim do embargo; por isso o php.net anunciou os patches a 20/10/2026. Porque é que a vulnerabilidade PHP foi conhecida antes do patch →
End of Life: End of Life (EOL) significa que uma versão de software deixou de receber atualizações do fabricante, incluindo correções de segurança. O PHP 8.1 e anteriores já não recebem atualizações oficiais do projeto PHP; para 7.4, 8.0 e 8.1 existem apenas backports mínimos do código-fonte. Os sistemas com software EOL precisam de um plano de atualização. PHP End of Life: riscos de versões desatualizadas →
Exploit: Um exploit é código ou um procedimento que explora efetivamente uma vulnerabilidade concreta. Assim que surge um patch, os atacantes podem analisá-lo e derivar exploits. Por isso, depois da publicação de um patch, o tempo até aos ataques encurta-se muitas vezes de forma considerável. A janela de tempo entre o patch e o ataque →
expose_php: O expose_php controla se o PHP revela a sua versão no cabeçalho HTTP X-Powered-By. Em produção, a definição deve estar em Off, para que os atacantes não vejam de imediato que versão do PHP está a correr. É proteção de informação, não substitui uma atualização. expose_php e cabeçalhos Server: ocultar a versão →
Extension: Uma extensão acrescenta funções ao PHP, por exemplo para bases de dados, imagens ou cifragem. As extensões correm no mesmo processo que o PHP e têm os mesmos direitos. Desativar as extensões desnecessárias reduz a superfície de ataque. Compreender as extensões PHP (Extensions) →

F

Fail2ban: O Fail2ban lê ficheiros de registo e bloqueia temporariamente na firewall os endereços IP após tentativas falhadas repetidas. Os campos de aplicação típicos são SSH, correio e inícios de sessão de administração de sites. Contra ataques distribuídos a partir de muitos endereços, ajuda apenas de forma limitada. Configurar o Fail2ban para servidores web →
FastCGI: FastCGI é um protocolo através do qual um servidor web encaminha pedidos para processos de programas em execução permanente, por exemplo o PHP-FPM. Ao contrário do CGI clássico, não é iniciado um novo processo para cada pedido. Como os processos tratam vários pedidos em sequência, é importante reiniciá-los corretamente após as atualizações. CGI e FastCGI: os fundamentos →
Forensik: A perícia forense informática investiga, depois de um incidente, de forma metódica o que aconteceu: como o atacante entrou, o que fez e que dados foram afetados. A base são cópias preservadas de suportes de dados, de memória e de registos. Os resultados são importantes para obrigações de notificação, seguros e queixas-crime. Perícia forense informática após um ataque a um servidor web →
FPM-Pool: Um pool é um grupo de processos PHP-FPM com configuração própria, socket próprio e, idealmente, utilizador de sistema próprio. Um pool por site separa os sites uns dos outros, de modo que uma intrusão num site não alcança diretamente os ficheiros dos outros. No pool, as definições podem ser fixadas com php_admin_value. Isolar pools PHP-FPM por site →
FrankenPHP: O FrankenPHP é um servidor de aplicações moderno para PHP baseado no servidor web Caddy. O PHP está aí incorporado diretamente e, no modo worker, a aplicação permanece em memória entre pedidos. Segundo a equipa do PHP, o FrankenPHP faz parte dos modos de operação afetados; após a atualização, o servidor tem de ser reiniciado com o novo PHP. Proteger o FrankenPHP →

G

GHSA: GHSA é o identificador de uma GitHub Security Advisory, ou seja, de um aviso de segurança na base de dados do GitHub. Muitos projetos de código aberto, incluindo o PHP, publicam aí os seus avisos além do número CVE. No caso do PHP2Shell, são GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp.

H

HSTS: O HSTS (HTTP Strict Transport Security) é um cabeçalho com o qual um site comunica ao navegador que, durante um determinado período, só deve ser acedido por HTTPS. Isto impede que as ligações sejam degradadas para HTTP não cifrado. Antes de o ativar, o HTTPS deve funcionar de forma fiável em todos os domínios afetados. Security headers para sites: definir corretamente os cabeçalhos de segurança →
.htaccess: Os ficheiros .htaccess são ficheiros de configuração por diretório para o Apache e servidores compatíveis como o LiteSpeed. Os CMS usam-nos para redirecionamentos e proteção de acesso; os atacantes, para redirecionamentos ocultos. O Nginx não avalia o .htaccess; as regras de proteção têm de ir, aí, para a configuração do servidor. Configurar o Apache para PHP com segurança →
Härtung: Hardening significa configurar um sistema de modo a oferecer o mínimo possível de superfície de ataque: apenas os serviços necessários, direitos reduzidos, predefinições seguras. Nos servidores PHP, incluem-se, por exemplo, pools separados, funções bloqueadas e nenhuma execução de PHP em pastas de uploads. O hardening limita os danos, mas não substitui as atualizações. Hardening de servidor para servidores web PHP →

I

Image-Digest: Um digest de imagem é um valor de hash (sha256) que identifica de forma inequívoca o conteúdo de uma imagem de contentor. Ao contrário de uma etiqueta como php:8.3-fpm, que pode ser movida para novas compilações, um digest nunca muda. Quem fixa imagens por digest tem de o atualizar deliberadamente após uma atualização de segurança. Imagens Docker oficiais do PHP: tags, digests e reconstrução →
Incident Response: A resposta a incidentes (incident response) é o tratamento ordenado de um incidente de segurança: detetar, conter, preservar vestígios, limpar, recuperar e fazer o balanço. Um procedimento definido evita que, na pressa, se destruam provas ou se ignorem backdoors. São importantes responsabilidades claras e uma documentação sem lacunas. Resposta a incidentes em ataques a servidores →
ini_set(): ini_set() é uma função PHP com a qual um script altera definições em tempo de execução. O que um script pode alterar depende do modo de alteração da definição. Como também o código malicioso pode chamar ini_set(), as definições de proteção pertencem à configuração do servidor ou do pool, e não ao código da aplicação. O php.ini explicado: estrutura, níveis e precedência →
Integritätsprüfung: Numa verificação de integridade, os ficheiros são comparados com um estado original conhecido, normalmente através de somas de verificação. Muitos CMS oferecem comandos próprios para isso, por exemplo o WordPress, o Nextcloud ou o Matomo. Ficheiros personalizados, uploads e conteúdos da base de dados não são abrangidos por esta comparação. Comparar os ficheiros principais do CMS com o original →
IOC: Os IOC (Indicator of Compromise) são vestígios concretos de um ataque, por exemplo nomes de ficheiros, valores de hash, endereços IP ou domínios. Com eles é possível verificar sistemas de forma específica quanto a um ataque conhecido. Para o PHP2Shell não existem IOCs confirmados publicados; a deteção baseia-se na análise de comportamento. Já estou comprometido? Sinais após o PHP2Shell →
ISO 27001: A ISO/IEC 27001 é a norma internacional para sistemas de gestão da segurança da informação (SGSI). Exige um tratamento regulado dos riscos, das medidas e das melhorias, incluindo a gestão de vulnerabilidades e de incidentes. As empresas podem certificar-se de acordo com ela. ISO 27001 e TISAX: o que afeta os servidores web →
IT-Grundschutz: O IT-Grundschutz do BSI é uma metodologia com módulos e requisitos para a segurança da informação em empresas e autoridades. Existem módulos próprios, por exemplo, para servidores web e aplicações web. Pode ser usado como base para um SGSI ou para uma certificação. CIS Benchmarks e módulos do BSI para servidores web →

J

JIT: O JIT (Just-in-Time Compiler) traduz em tempo de execução, para código máquina, o código PHP executado com frequência. Surgiu com o PHP 8.0 e faz parte do OPcache. Para sites típicos, o ganho de desempenho é geralmente pequeno; é maior em tarefas de cálculo intensivo. JIT e desempenho no PHP 8 →

K

Kryptominer: Um criptominer (cryptominer) é software malicioso que calcula criptomoeda em servidores alheios. Os sinais típicos são uma carga de CPU permanentemente elevada e processos desconhecidos. Um miner mostra que um atacante consegue executar código; o servidor deve então ser considerado comprometido. Criptomineiro no servidor web: sinais e como proceder →

L

Least Privilege: Least privilege (princípio do privilégio mínimo) significa que cada utilizador e cada processo recebe apenas os direitos de que realmente precisa. Se o PHP corre com direitos reduzidos, um atacante consegue fazer menos estragos depois de uma intrusão. Isto abrange utilizadores de sistema, permissões de ficheiros, contas de base de dados e acessos de administração. Least Privilege: permissões do utilizador do servidor web →
Lessons Learned: Lições aprendidas (lessons learned) é o balanço de um incidente: o que aconteceu, o que correu bem, o que tem de mudar? O objetivo são medidas concretas com responsáveis e prazos, e não atribuição de culpas. Os resultados alimentam o plano de emergência, o processo de patches e a formação. Lições aprendidas: melhorar depois do incidente →
LFI: A LFI (Local File Inclusion) ocorre quando uma aplicação inclui um ficheiro local cujo caminho o atacante consegue influenciar. Assim é possível ler ficheiros de configuração ou, em certas circunstâncias, executar código introduzido. A proteção está em listas fixas de valores permitidos, em vez de nomes de ficheiro provenientes de entradas do utilizador. Evitar Local File Inclusion em PHP: LFI e RFI →
LiteSpeed: O LiteSpeed é um servidor web em grande parte compatível com configurações Apache como o .htaccess e que liga o PHP através da sua própria interface, o LSAPI. É comum nos fornecedores de alojamento; o OpenLiteSpeed é a variante livre. Segundo a equipa do PHP, o LiteSpeed faz parte dos modos de operação afetados pelo PHP2Shell. LiteSpeed e LSAPI: atualizar o PHP →

M

Managed Server: Num servidor gerido (managed server), o fornecedor disponibiliza um servidor próprio e assume contratualmente partes definidas da operação, muitas vezes as atualizações do sistema operativo e do PHP. O que exatamente está incluído consta do contrato e difere bastante entre fornecedores. Em caso de dúvida, a responsabilidade pelos patches deve ser confirmada por escrito. Servidor gerido: esclarecer a responsabilidade →
memory_limit: O memory_limit limita a quantidade de memória que um único script PHP pode ocupar; o valor predefinido é 128 MB. Quando o limite é atingido, o PHP termina com um erro de falta de memória. Contra a CVE-2026-109618, o php.net aconselha, a título provisório, memory_limit=-1, definido de forma fixa, e um limite de memória através de contentor ou cgroup. Definir corretamente o memory_limit →
mod_php: O mod_php é o módulo PHP para o servidor web Apache. O PHP corre diretamente no processo do Apache e, em regra, com os direitos do respetivo utilizador. A equipa do PHP classifica o risco do PHP2Shell como o mais elevado no mod_php; foi demonstrado um exploit nesse modo antes sequer de o código da aplicação ser executado. mod_php explicado: o PHP dentro do processo do Apache →
ModSecurity: O ModSecurity é uma WAF de código aberto muito difundida, que funciona como módulo no Apache, no Nginx ou noutros servidores web. Avalia os pedidos com base em regras e pode registá-los ou bloqueá-los. Costuma ser usado em conjunto com o OWASP Core Rule Set. Utilizar o ModSecurity e o OWASP Core Rule Set →
Monitoring: A monitorização é a vigilância contínua de sistemas, por exemplo disponibilidade, carga, ficheiros de registo e alterações de ficheiros. A monitorização de segurança procura especificamente anomalias, como novos ficheiros PHP ou shells iniciadas pelo servidor web. Só ajuda se alguém avaliar os alertas em tempo útil. Monitorização de segurança para servidores web →

N

Nginx: O Nginx é um servidor web e proxy inverso muito difundido. Não executa o PHP por si próprio, mas encaminha os pedidos por FastCGI para o PHP-FPM. É importante uma configuração que entregue ao PHP apenas ficheiros PHP verdadeiros e exclua as pastas de uploads. Proteger o Nginx com PHP-FPM →
NIS2: A NIS2 é uma diretiva da UE que estabelece, para muitas empresas e entidades, obrigações de gestão de risco e de notificação de incidentes de segurança. Abrange claramente mais setores e dimensões de empresa do que a regulamentação anterior. Se a sua empresa está abrangida, deve esclarecê-lo com base na transposição nacional e com aconselhamento jurídico. NIS2 e segurança dos servidores web →
Notfallplan: Um plano de emergência de TI define quem faz o quê num incidente: contactos, vias de decisão, primeiros passos, retoma. Tem de estar disponível também offline, caso os sistemas falhem. Exercícios regulares mostram se funciona em caso de emergência real. Elaborar um plano de emergência de TI para servidores web →

O

OPcache: O OPcache é a cache de bytecode fornecida com o PHP. Guarda na memória partilhada o código já traduzido, para que os ficheiros PHP não sejam compilados de novo a cada pedido. Depois de uma atualização ou de uma limpeza, é preciso esvaziar a cache ou reiniciar o PHP, caso contrário pode continuar a correr código antigo. OPcache explicado: a cache de bytecode do PHP →
open_basedir: O open_basedir restringe os diretórios a que os scripts PHP podem aceder com funções de ficheiros. Em servidores com vários sites, impede que um site leia simplesmente os ficheiros de outro. Não é isolamento completo; utilizadores de sistema separados e pools FPM separados fazem parte da solução. open_basedir e isolamento por site →
Origin-Server: O servidor de origem (origin) é o servidor web propriamente dito por trás de uma CDN ou de um proxy inverso. Se também for acessível diretamente pelo seu endereço IP, os atacantes podem contornar a proteção colocada à frente. Por isso, a origem deve aceitar apenas ligações da CDN ou do proxy. Regras de proteção da Cloudflare contra o PHP2Shell: o que conseguem e o que não →
Out of Memory: Out of Memory designa o estado em que um programa não obtém mais memória e tem de terminar. No PHP, isso acontece quando o memory_limit é excedido. No caso da CVE-2026-109618, uma interrupção deste tipo pode interromper o PHP enquanto os dados do pedido estão apenas parcialmente inicializados. memory_limit e Out-of-Memory: o que acontece por dentro →
OWASP CRS: O OWASP Core Rule Set (CRS) é um conjunto de regras livremente disponível para o ModSecurity e WAFs compatíveis. Reconhece classes típicas de ataque, como SQL injection ou command injection. As regras têm de ser ajustadas à aplicação, caso contrário bloqueiam também pedidos legítimos. Utilizar o ModSecurity e o OWASP Core Rule Set →
OWASP Top 10: O OWASP Top 10 é uma lista atualizada regularmente dos principais riscos para aplicações web, publicada pela fundação sem fins lucrativos OWASP Foundation. Serve de base para o desenvolvimento, as auditorias e a formação. Como complemento, a OWASP oferece os Cheat Sheets com contramedidas concretas.

P

Patch: Um patch é uma correção do fabricante que fecha uma vulnerabilidade no código do programa. Só produz efeito depois de instalado e de todos os processos em execução terem sido reiniciados. Um patch não remove software malicioso já introduzido e não prova que nada aconteceu antes. Serviço de patches PHP: atualização com reinício e comprovativo →
PECL: O PECL (PHP Extension Community Library) é o diretório das extensões PHP escritas em C que não fazem parte do âmbito padrão. Essas extensões têm de ser compatíveis com a versão do PHP instalada. Depois de uma mudança de versão principal do PHP, muitas vezes têm de ser recompiladas ou substituídas. Compreender as extensões PHP (Extensions) →
PHP: PHP é uma linguagem de script que corre sobretudo em servidores web, onde gera páginas web. Muitos CMS e sistemas de loja muito usados, como WordPress, TYPO3 ou Shopware, estão escritos em PHP. Uma vulnerabilidade no interpretador PHP afeta por isso todas as aplicações que nele correm, independentemente do seu próprio nível de atualização. O que é o PHP? A linguagem de programação explicada →
php-cgi: O php-cgi é o programa PHP para funcionamento via CGI ou FastCGI. Segundo a equipa do PHP, faz parte dos modos de operação afetados pelo PHP2Shell. Onde o php-cgi ainda é utilizado, vale a pena verificar se é possível mudar para o PHP-FPM. php-cgi: um legado com risco →
PHP-FPM: O PHP-FPM (FastCGI Process Manager) é um serviço próprio que gere processos PHP em pools e recebe os pedidos do servidor web através de FastCGI. É hoje o modo de operação habitual com o Nginx e em muitos servidores Apache. Depois de uma atualização do PHP, o PHP-FPM tem de ser reiniciado para que não continuem a correr processos antigos. PHP-FPM explicado: gestor de processos, pools e workers →
php.ini: O php.ini é o ficheiro de configuração central do PHP. Define limites e definições de segurança e de erros, por exemplo memory_limit ou display_errors. Muitas vezes existe um php.ini próprio por SAPI (FPM, CLI, Apache), que tem de ser mantido separadamente. O php.ini explicado: estrutura, níveis e precedência →
PHP2Shell: PHP2Shell é o nome de duas vulnerabilidades críticas no próprio PHP, CVE-2026-109618 e CVE-2026-109619, cada uma com CVSS v4.0 de 9,2. Permitem a execução remota de código malicioso sem autenticação. Foram corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicados a 21/10/2026. O que é o PHP2Shell? A vulnerabilidade explicada de forma simples →
php_admin_value: O php_admin_value define uma definição do PHP no pool FPM ou na configuração do Apache de modo que as aplicações não a possam sobrepor com ini_set() ou .htaccess. Para opções ligar/desligar existe o php_admin_flag. O php.net recomenda este caminho para as medidas provisórias contra o PHP2Shell, por exemplo para memory_limit. php_admin_value: bloquear definições contra a sobrescrita →
Plesk: O Plesk é um painel de gestão de servidores web muito difundido, com o qual se configuram domínios, versões do PHP e handlers por site. Traz pacotes PHP próprios, mas pode também usar os pacotes PHP da distribuição. Em caso de backports, o Plesk pode continuar a mostrar um número mais antigo, como 8.2.34, apesar de o patch estar aplicado. Servidores Plesk: verificar e aplicar patches às versões PHP →
post_max_size: O post_max_size define o tamanho total máximo do conteúdo de um pedido POST; o valor predefinido é 8 MB. Como medida provisória contra o PHP2Shell, o php.net indica 8M para sites sem uploads e 32M com uploads. O upload_max_filesize tem de ficar abaixo deste valor. Limitar com critério post_max_size e upload_max_filesize →
Proof of Concept: Uma prova de conceito (PoC) é a demonstração de que uma vulnerabilidade pode ser explorada, muitas vezes sob a forma de um código de demonstração simples. Serve os fabricantes e investigadores para avaliação, mas pode também servir de modelo aos atacantes. Uma PoC publicada aumenta por isso, em regra, a urgência de aplicar o patch.

R

Ransomware: O ransomware cifra dados e exige um resgate para a decifração, muitas vezes associado à ameaça de publicar dados roubados. Um servidor web comprometido pode ser o ponto de entrada. A proteção mais eficaz são cópias de segurança separadas e testadas e um plano de emergência. Estratégia de backup para servidores: backups segundo a regra 3-2-1 →
RCE: RCE (Remote Code Execution) significa que um atacante pode executar remotamente código próprio num sistema alheio. Quando para isso não é necessária autenticação, fala-se de RCE não autenticada, a classe mais grave de vulnerabilidades de servidores web. Com RCE, um atacante pode ler dados, criar backdoors e continuar a abusar do servidor. O que é o PHP2Shell? A vulnerabilidade explicada de forma simples →
Release-Zyklus: Cada versão do PHP recebe primeiro correções de erros e, depois, durante algum tempo, apenas correções de segurança. O projeto PHP publica no php.net, nas versões suportadas, quando termina cada versão. Segundo o php.net, o PHP 8.2 atinge o fim do suporte a 31/12/2026. Versões do PHP e ciclo de lançamentos →
Reverse Proxy: Um proxy inverso (reverse proxy) recebe os pedidos da Internet e encaminha-os para um ou vários servidores por trás dele. Pode assumir o TLS, distribuir a carga e servir de local para regras de filtragem ou para uma WAF. Só oferece proteção se os servidores por trás dele não forem também acessíveis diretamente. Filtrar pedidos de upload na periferia: oportunidades e riscos →
RFI: A RFI (Remote File Inclusion) é a variante em que uma aplicação carrega e executa código de um endereço externo. No PHP, a definição allow_url_include=Off, que é o valor predefinido há muito tempo, impede a inclusão de ficheiros remotos. As aplicações e configurações antigas devem ser verificadas quanto a isto. Evitar Local File Inclusion em PHP: LFI e RFI →
Root-Server: Um servidor root é um servidor alugado em que o cliente tem direitos de administrador plenos. Com isso, também a responsabilidade plena por atualizações, hardening e vigilância cabe ao cliente. O fornecedor disponibiliza apenas o hardware e a rede. Proteger por si próprio o servidor root e o vServer →

S

SAPI: SAPI (Server Application Programming Interface) é a interface através da qual o PHP comunica com o seu ambiente, por exemplo com o Apache, o PHP-FPM ou a linha de comandos. A SAPI em uso determina como os processos PHP são iniciados, reutilizados e reiniciados. No caso do PHP2Shell, segundo a equipa do PHP, vários modos de operação estão afetados, sendo o mod_php o de maior risco. SAPI explicada: como o PHP comunica com o servidor web →
SEO-Spam: O spam de SEO consiste em páginas, ligações ou redirecionamentos introduzidos com os quais os atacantes colocam ofertas alheias nos motores de pesquisa. Muitas vezes só os motores de pesquisa ou os visitantes vindos do Google veem os conteúdos manipulados. Além da limpeza, é necessária depois uma verificação no Google Search Console. Spam de SEO e páginas alheias no índice do Google →
serialize_handler: O session.serialize_handler determina em que formato o PHP guarda os dados de sessão, por exemplo php, php_binary ou php_serialize. O aviso sobre a CVE-2026-115560 diz respeito apenas a uma configuração invulgar, em que este formato é alterado em tempo de execução e o session upload progress está ativo. Até à próxima versão de correção de erros, a solução provisória é session.upload_progress.enabled=0. CVE-2026-115560: aviso sobre o session upload progress →
Session: Uma sessão liga vários pedidos do mesmo visitante, por exemplo para o início de sessão ou o carrinho de compras. O PHP guarda os dados no servidor e atribui ao navegador um ID de sessão, por predefinição no cookie PHPSESSID. Quem conhece o ID de sessão de outra pessoa pode, em certas circunstâncias, fazer-se passar por esse utilizador. Sessões e cookies em PHP →
session.upload_progress: O session upload progress é uma função do PHP que guarda na sessão o progresso dos uploads de ficheiros em curso; está ativada por predefinição. O php.net aconselha, a título provisório, session.upload_progress.enabled=0 no php.ini, no pool FPM ou na configuração do servidor, seguido do reinício de todos os workers. Segundo relatórios especializados, só esta definição não fecha as duas vulnerabilidades do PHP2Shell; a atualização continua a ser obrigatória. Desativar o session.upload_progress: de forma correta e duradoura →
Shared Hosting: No alojamento partilhado (shared hosting), muitos clientes partilham um servidor operado pelo fornecedor de alojamento. O fornecedor é responsável pelo PHP, pelo sistema operativo e pelo servidor web; o cliente, pela sua aplicação. No caso do PHP2Shell, isto significa: perguntar ao fornecedor qual é o nível de patch e verificar o próprio site quanto a vestígios. Alojamento partilhado: o que faz o fornecedor e o que tem de fazer →
Sicherheits-Header: Os cabeçalhos de segurança são linhas de cabeçalho de resposta HTTP que indicam ao navegador regras de proteção, por exemplo Content-Security-Policy, Strict-Transport-Security ou X-Content-Type-Options. Protegem os visitantes de certos ataques no navegador. Contra vulnerabilidades no servidor, como o PHP2Shell, não ajudam. Security headers para sites: definir corretamente os cabeçalhos de segurança →
SIEM: Um SIEM (Security Information and Event Management) recolhe centralmente dados de registo de muitos sistemas e avalia-os quanto a eventos de segurança. Assim é possível reconhecer relações que se perdem em registos individuais. Um SIEM precisa de regras mantidas e de pessoas que tratem os alertas. Monitorização de segurança para servidores web →
Skimming: No skimming em lojas online, os atacantes introduzem no checkout JavaScript que lê e envia dados de pagamento e de clientes. O código encontra-se muitas vezes em ficheiros de temas, scripts de rastreamento ou registos da base de dados. Os clientes não notam nada; o comerciante muitas vezes só por avisos dos prestadores de pagamento. Loja online hackeada? Segurança informática para comerciantes →
SQL-Injection: Numa SQL injection, o atacante introduz, através de entradas, comandos de base de dados próprios numa aplicação. Assim é possível ler ou alterar dados. A proteção está nas instruções preparadas (prepared statements) com marcadores de posição, em vez de textos SQL compostos por concatenação. Evitar SQL Injection em PHP →
SSRF: A SSRF (Server-Side Request Forgery) leva uma aplicação a enviar, por conta do atacante, pedidos para outros endereços, incluindo sistemas internos. Assim tornam-se acessíveis serviços que, do exterior, deveriam estar protegidos. A proteção está em listas de destinos permitidos e no bloqueio de gamas de endereços internos. Evitar Server-Side Request Forgery (SSRF) em PHP →
Superglobals: As superglobais são variáveis que o PHP disponibiliza em todos os scripts, por exemplo $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER e $_SESSION. Contêm os dados do pedido atual, que em grande parte provêm do visitante. Tudo o que contêm tem de ser tratado como não fiável e validado. Superglobais: $_GET, $_POST, $_FILES e outras →
sury.org: O sury.org é um repositório de pacotes de Ondřej Surý com versões atuais e mais antigas do PHP para Debian e Ubuntu. É uma oferta de terceiros e não o arquivo de segurança do Debian. Segundo relatórios, foram aí disponibilizadas compilações para todos os ramos de 5.6 a 8.5. O repositório sury.org: pacotes PHP de fonte de terceiros →

T

Threat Hunting: O threat hunting é a procura ativa de atacantes na própria rede, sem que exista um alerta. O ponto de partida são hipóteses, por exemplo: um processo do servidor web iniciou uma shell desde 20/10? Assim encontram-se intrusões que as ferramentas automáticas não detetam. Sinal de alerta: o servidor web inicia uma shell →
TISAX: O TISAX é um procedimento de auditoria e de intercâmbio para a segurança da informação na indústria automóvel. Baseia-se num catálogo de requisitos da associação alemã da indústria automóvel (VDA) e é operado pela ENX Association. Os fornecedores precisam dele para demonstrar o seu nível de segurança perante os fabricantes. ISO 27001 e TISAX: o que afeta os servidores web →
TLS: O TLS (Transport Layer Security) cifra a ligação entre o navegador e o servidor; reconhece-se por HTTPS. Atualmente são recomendados o TLS 1.2 e o 1.3; as versões de protocolo mais antigas devem estar desativadas. O TLS protege os dados em trânsito, não contra vulnerabilidades no próprio servidor. Configurar corretamente o TLS e o HTTPS →
Type Juggling: Type juggling é a conversão automática de tipos no PHP, por exemplo na comparação laxa com ==. Assim, valores que não são iguais podem ser considerados iguais, o que se torna perigoso em verificações de palavras-passe ou de tokens. A proteção está em comparações estritas com === e em hash_equals() para segredos. Type juggling em PHP: comparações laxas como risco de segurança →

U

upload_max_filesize: O upload_max_filesize limita o tamanho de um único ficheiro enviado; o valor predefinido é 2 MB. O valor tem de ser inferior ao post_max_size, porque o ficheiro faz parte do pedido POST. Valores demasiado generosos aumentam a superfície de ataque sem benefício. Limitar com critério post_max_size e upload_max_filesize →
.user.ini: Os ficheiros .user.ini são definições PHP por diretório, avaliadas pelo PHP-FPM e pelo CGI. Permitem aos operadores de sites alterar alguns valores sem acesso ao servidor, mas apenas os que o PHP liberta para esse efeito. Segundo o php.net, as definições relevantes para a segurança, como session.upload_progress.enabled=0 contra o PHP2Shell, não devem ser feitas através de .user.ini. O php.ini explicado: estrutura, níveis e precedência →

V

VdS 10000: A VdS 10000 é uma diretriz da VdS Schadenverhütung (organização alemã de prevenção de sinistros) para a segurança da informação em pequenas e médias empresas. É mais enxuta do que a ISO 27001 e está adaptada às possibilidades das PME. É possível certificar-se de acordo com ela. VdS 10000: segurança da informação para pequenas e médias empresas →
Virtuelles Patching: O patching virtual bloqueia ataques a uma vulnerabilidade conhecida antes da aplicação, normalmente com uma WAF, sem alterar o código vulnerável. Ganha-se tempo até a atualização verdadeira ser possível. No caso do PHP2Shell, a Cloudflare, por exemplo, avisa que regras baseadas apenas nos dados do pedido não bastam; a atualização continua a ser obrigatória. WAF e patching virtual para PHP →
vServer: Um vServer (servidor virtual) é um computador virtual em hardware partilhado, com sistema operativo próprio e, na maioria dos casos, acesso root. Em termos de segurança aplica-se o mesmo que no servidor root: atualizações e hardening são da responsabilidade do cliente. Muitos vServers funcionam com painéis pré-instalados, como o Plesk. Proteger por si próprio o servidor root e o vServer →

W

WAF: Uma WAF (Web Application Firewall) examina os pedidos HTTP antes da aplicação e bloqueia padrões de ataque conhecidos. Pode funcionar como serviço na nuvem, como proxy ou como módulo do servidor web. Ganha-se tempo, mas não substitui uma atualização e é contornada se o servidor também for acessível diretamente. WAF e patching virtual para PHP →
Warnstufe: O BSI classifica a situação de ameaça dos avisos de segurança em níveis, também identificados por cores. O nível 3 (laranja) corresponde a uma situação crítica para o negócio, com possível perturbação massiva do funcionamento normal. Para o PHP2Shell aplica-se o nível de alerta 3 / laranja. Nível de alerta laranja do BSI: o que significa a classificação →
Webshell: Uma webshell é um script que os atacantes colocam num servidor web para o controlarem remotamente através do navegador. É muitas vezes pequena, ofuscada e escondida em pastas de uploads ou de cache. Uma webshell mantém-se mesmo depois de uma atualização do PHP ou do CMS e tem de ser procurada de forma específica. Detetar e remover uma webshell →

X

XSS: XSS (Cross-Site Scripting) significa que JavaScript alheio é executado, através de um site, no navegador de outros visitantes. Com isso é possível assumir sessões ou ler entradas de formulários. A proteção está na codificação consistente de todas as saídas e numa Content Security Policy. Evitar XSS em PHP: combater o Cross-Site Scripting com segurança →
XXE: O XXE (XML External Entities) explora o facto de os analisadores XML poderem carregar referências externas em documentos. Com isso, é possível, em certas circunstâncias, ler ficheiros do servidor ou desencadear pedidos internos. A proteção está em desativar o carregamento de entidades externas ao processar dados XML não fiáveis. Evitar XML External Entities (XXE) em PHP →

Z

ZAC: Os Zentrale Ansprechstellen Cybercrime (ZAC), pontos de contacto centrais para o cibercrime da polícia alemã, são serviços especializados para empresas e autoridades que foram vítimas de um ciberataque. Existem em todos os estados federados alemães e no BKA (Gabinete Federal de Polícia Criminal). Recebem denúncias e aconselham sobre os passos seguintes. Apresentar queixa: pontos de contacto centrais para cibercrime →
Zeitleiste: Uma cronologia (timeline) ordena cronologicamente todos os vestígios de um incidente: entradas de registo, alterações de ficheiros, inícios de sessão, processos. Mostra quando o ataque começou e o que aconteceu, e por que ordem. É importante um fuso horário uniforme, de preferência UTC. Elaborar a cronologia de um incidente →
Zend Engine: A Zend Engine é o núcleo do interpretador PHP. Traduz o código PHP em instruções internas (opcodes), executa-as e gere a memória. Os erros na Zend Engine afetam todas as aplicações PHP e só se corrigem com uma atualização do PHP. A Zend Engine: o coração do PHP →
Zero-Day: Um zero-day é uma vulnerabilidade que é explorada ou se torna pública antes de o fabricante disponibilizar um patch. Os operadores têm então zero dias de antecedência. Até ao patch, só ajudam medidas provisórias, isolamento e vigilância. A janela de tempo entre o patch e o ataque →

Contacto imediato

Cada hora conta. Escreva-nos agora.

Descreva brevemente o sistema, a versão do PHP e o que observou. Entramos em contacto consigo, esclarecemos a situação e trabalhamos remotamente até o incidente estar concluído e documentado.

Emergência por WhatsApp Ligar