# Blogue: PHP2Shell, segurança de servidores e assistência de emergência

> Blogue sobre PHP2Shell e segurança de servidores: situação, alojamento, deteção, hardening, desenvolvimento seguro, gestão e apoio à decisão.

Fonte: https://phpsos.de/pt/blog/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

Enquadramento da situação, instruções para administradores e apoio à decisão para a administração. Ordenado por tema, cada artigo com fontes.

- [PHP2Shell: o que está comprovado e o que não está](https://phpsos.de/pt/blog/php2shell-was-belegt-ist/): Uma verificação de factos sobre o PHP2Shell: que afirmações vêm de fontes primárias, quais vêm de notícias dos media e que alegações não se sustentam.
- [Porque é que a vulnerabilidade PHP foi conhecida antes do patch](https://phpsos.de/pt/blog/php-luecke-vorzeitig-bekannt/): Segundo notícias, houve pormenores sobre o PHP2Shell que se tornaram públicos antes de terminar o embargo. Explicamos o processo e o que significa para o seu planeamento de patches.
- [Autoridades retiram sites da rede: o que as empresas podem aprender](https://phpsos.de/pt/blog/behoerden-webseiten-offline/): Mogúncia, o governo regional do Hessen e o BKA retiraram sites da rede por precaução. O que as empresas podem aprender com isso para a sua própria decisão.
- [Nível de alerta laranja do BSI: o que significa a classificação](https://phpsos.de/pt/blog/bsi-warnstufe-orange-erklaert/): O BSI classifica o PHP2Shell com 3 / laranja. O que a escala diz, o que não diz e como as empresas traduzem a classificação em decisões.
- [O que o CERT-EU e o CERT-Bund recomendam sobre o PHP2Shell](https://phpsos.de/pt/blog/cert-eu-empfehlungen-php/): As entidades oficiais estão de acordo: aplicar o patch de imediato, caso contrário isolar. Comparamos as recomendações e mostramos como é o isolamento na prática.
- [Regras de proteção da Cloudflare contra o PHP2Shell: o que conseguem e o que não](https://phpsos.de/pt/blog/cloudflare-waf-php2shell/): A Cloudflare lançou cedo regras de proteção contra o PHP2Shell. Porque ajudam, porque não substituem a atualização do PHP e que definições deve verificar.
- [22,6 milhões de instâncias expostas: como interpretar os números](https://phpsos.de/pt/blog/exponierte-instanzen-einordnen/): A Unit 42, a CybelAngel e outros apresentam números muito diferentes sobre o PHP2Shell. Explicamos o que foi contado e que número conta realmente para si.
- [PHP2Shell em cinco minutos: briefing para a administração](https://phpsos.de/pt/blog/php2shell-briefing-geschaeftsfuehrung/): A falha de segurança PHP2Shell numa página para quem decide: situação, risco, cinco perguntas à TI e as decisões para hoje.
- [A vulnerabilidade de segurança PHP explicada de forma simples](https://phpsos.de/pt/blog/php-luecke-einfach-erklaert/): O PHP2Shell para quem não é técnico: com imagens do dia a dia, um pequeno glossário e três situações típicas sobre o que fazer como operador de um site.
- [PHP2Shell: 15 perguntas de clientes de alojamento](https://phpsos.de/pt/blog/fragen-von-hosting-kunden/): O seu site está num fornecedor de alojamento e quer saber o que tem de fazer pessoalmente no PHP2Shell? Aqui estão as 15 perguntas mais frequentes, com respostas curtas.
- [Porque é que uma atualização do WordPress não ajuda contra o PHP2Shell](https://phpsos.de/pt/blog/warum-wordpress-update-nicht-hilft/): Depois das manchetes, muitos operadores atualizaram o WordPress e sentem-se seguros. Porque é que isso não resolve nada no PHP2Shell e o que conta em vez disso.
- [PHP2Shell e Log4Shell: o que as vulnerabilidades têm em comum](https://phpsos.de/pt/blog/php2shell-und-log4shell/): Muitos comparam o PHP2Shell com o Log4Shell de 2021. O que a comparação sustenta, onde falha e que lições de então ajudam hoje.
- [Varrimentos em massa à procura de PHP sem patch: como decorrem os ataques automatizados](https://phpsos.de/pt/blog/automatisierte-massenscans/): Depois do PHP2Shell, os atacantes varrem a Internet de forma automatizada à procura de servidores vulneráveis. Como decorre, porque o tamanho não importa e o que o protege.
- [A janela de tempo entre o patch e o ataque](https://phpsos.de/pt/blog/zeitfenster-patch-angriff/): No PHP2Shell houve tentativas de ataque já antes do patch. Explicamos as fases da janela de tempo, como medir a sua e como a encurtar.
- [Depois do PHP2Shell: porque são prováveis mais avisos](https://phpsos.de/pt/blog/weitere-php-meldungen/): O PHP2Shell não terminou com o patch de 21 de outubro. Porque são de esperar avisos posteriores e como preparar a sua equipa para eles.
- [PHP2Shell: o panorama da primeira semana](https://phpsos.de/pt/blog/lagebild-erste-woche/): Uma semana depois da primeira tentativa de ataque observada: o ponto da situação sobre patches, alertas de autoridades, ataques e desligamentos, separado por fontes.
- [Falsas dicas perigosas sobre o PHP2Shell que estão a circular](https://phpsos.de/pt/blog/gefaehrliche-falschtipps/): Bloquear cookies, esconder mensagens de erro, atualizar só o CMS: nove conselhos sobre o PHP2Shell que criam falsa segurança e o que realmente conta.
- [Alterar a versão do PHP na área de cliente do alojamento](https://phpsos.de/pt/blog/php-version-hosting-aendern/): Como mudar a versão do PHP na área de cliente do seu fornecedor de alojamento, que versão escolher e o que verificar antes e depois.
- [Debian e Ubuntu: o meu pacote PHP tem patch?](https://phpsos.de/pt/blog/debian-ubuntu-paket-gepatcht/): Que pacotes PHP o Debian e o Ubuntu corrigiram contra o PHP2Shell, como comparar exatamente o estado instalado e onde falha o comprovativo.
- [RHEL, AlmaLinux e Rocky Linux: verificar o patch do PHP](https://phpsos.de/pt/blog/rhel-almalinux-rocky-php/): O que a Red Hat publicou sobre o PHP2Shell, como comprovar o estado dos pacotes no RHEL e nos derivados e porque um reload não basta.
- [O repositório sury.org: pacotes PHP de fonte de terceiros](https://phpsos.de/pt/blog/sury-repository-php/): Muitos servidores Debian e Ubuntu obtêm o PHP do repositório sury. O que isso significa para atualizações, comprovativos e versões antigas do PHP depois do PHP2Shell.
- [O repositório Remi: manter o PHP atualizado em sistemas RHEL](https://phpsos.de/pt/blog/remi-repository-php/): O Remi fornece versões atuais do PHP para a família RHEL, como módulo ou instaláveis em paralelo. Como verificar o estado depois do PHP2Shell e evitar ramos esquecidos.
- [Porque é que o php -v mostra o mesmo número depois da atualização](https://phpsos.de/pt/blog/php-v-zeigt-alte-nummer/): A atualização correu, mas o php -v indica a versão antiga. Em geral é um backport e não um erro. Como distinguir o inofensivo dos problemas reais.
- [Comprovar números CVE no changelog do pacote](https://phpsos.de/pt/blog/cve-im-changelog-nachweisen/): Quem tem de comprovar um patch do PHP à administração, a auditores ou a seguradoras precisa de mais do que um número de versão. Assim a entrada do changelog torna-se comprovativo.
- [Mudar de fornecedor de alojamento após um incidente de segurança: o que ter em conta?](https://phpsos.de/pt/blog/hoster-wechseln-nach-vorfall/): Depois de um incidente, o desejo de um novo fornecedor de alojamento é compreensível. Para que a mudança não leve o atacante consigo, contam a ordem e a escolha.
- [Várias versões do PHP num servidor: aplicar o patch a cada uma](https://phpsos.de/pt/blog/mehrere-php-versionen-server/): Em muitos servidores correm três, quatro ou mais instalações do PHP lado a lado. Depois do PHP2Shell, cada uma tem de ser encontrada, atualizada e reiniciada.
- [Desativar versões antigas do PHP no painel de alojamento](https://phpsos.de/pt/blog/alte-php-versionen-abschalten/): O PHP2Shell é uma boa ocasião para se livrar de versões antigas do PHP. Proceda em três fases, para que nenhum site nem tarefa cron falhe sem ser notado.
- [Plesk: compreender os handlers do PHP (FPM, FastCGI, módulo Apache)](https://phpsos.de/pt/blog/plesk-php-handler/): O handler PHP que o Plesk usa para um site decide a isolação, a configuração e o risco. Uma comparação com o olhar no PHP2Shell.
- [CloudLinux e alt-php: o que os clientes de alojamento devem saber](https://phpsos.de/pt/blog/cloudlinux-alt-php/): Em servidores CloudLinux, os sites correm muitas vezes com pacotes alt-php próprios. Cada uma destas versões precisa do seu próprio patch, e só o operador do servidor o pode aplicar.
- [PHP em NAS, firewalls e appliances: os sistemas esquecidos](https://phpsos.de/pt/blog/php-auf-nas-und-appliances/): Não são só os servidores web que usam PHP. Também sistemas NAS, firewalls e equipamentos especializados com interface web podem estar afetados. Aí, o patch costuma ser do fabricante; a acessibilidade, define-a você.
- [PHP em fornecedores cloud e PaaS: quem aplica o patch ao runtime?](https://phpsos.de/pt/blog/paas-php-laufzeit/): Nos serviços de plataforma, o patch do PHP depende do modelo de operação. Decisivo é o runtime que realmente serve os pedidos, não o ambiente local nem o código da aplicação.
- [Imagens Docker oficiais do PHP: tags, digests e reconstrução](https://phpsos.de/pt/blog/offizielle-php-docker-images/): Uma tag da imagem oficial do PHP é um apontador que, com o tempo, passa para novos estados. Quem sabe o que significam tag, variante e digest escolhe a imagem certa e consegue comprovar o estado do patch.
- [CI/CD: reconstruir imagens PHP automaticamente](https://phpsos.de/pt/blog/php-images-in-ci-neu-bauen/): Uma imagem desatualiza-se mesmo sem alterações ao código. Com builds agendados, uma verificação de versão e uma publicação por digest, os patches do PHP chegam de forma fiável à produção.
- [Suporte de longo prazo para versões antigas do PHP: opções e limites](https://phpsos.de/pt/blog/langzeitsupport-alte-php-versionen/): Quem não pode mudar de imediato do PHP 8.1 ou anterior encontra suporte de longo prazo em distribuições, fornecedores terceiros e serviços comerciais. O que estes caminhos oferecem, o que precisa por escrito e onde estão os limites.
- [Atualizar o PHP no Windows](https://phpsos.de/pt/blog/php-unter-windows-aktualisieren/): No Windows não há atualização automática do PHP. Quem escolhe a variante certa, verifica o download e reinicia todos os processos leva o patch do PHP2Shell de forma limpa a cada computador.
- [Sinal de alerta: o servidor web inicia uma shell](https://phpsos.de/pt/blog/webserver-startet-shell/): Se um processo PHP-FPM ou do servidor web inicia uma shell, é um dos sinais de alerta mais fortes de uma intrusão. Como verificar a árvore de processos, enquadrar as exceções e vigiar o padrão de forma duradoura.
- [Encontrar processos suspeitos em servidores Linux](https://phpsos.de/pt/blog/verdaechtige-prozesse-linux/): Os processos maliciosos camuflam-se com nomes inofensivos, correm a partir de pastas temporárias ou de ficheiros apagados. Com poucos comandos de leitura encontra anomalias e enquadra-as.
- [Reconhecer cronjobs escondidos como porta dos fundos](https://phpsos.de/pt/blog/cronjobs-als-hintertuer/): Os atacantes usam tarefas agendadas para regressar depois de uma limpeza. Como verificar por completo crontabs, diretórios cron, temporizadores systemd e trabalhos at e reconhecer entradas suspeitas.
- [Encontrar ficheiros alterados recentemente no servidor web](https://phpsos.de/pt/blog/geaenderte-dateien-finden/): Depois de uma possível intrusão, conta o que mudou no servidor. Como pesquisar por janelas de tempo, usar corretamente mtime e ctime e comparar com pacotes, Git e cópias de segurança.
- [Ficheiros PHP na pasta de upload: interpretar bem os achados](https://phpsos.de/pt/blog/php-dateien-im-upload-ordner/): Um ficheiro PHP na pasta de upload é quase sempre um sinal de alarme, mas nem todos são código malicioso. Como avaliar o achado sem destruir vestígios e esclarecer se alguém o chamou.
- [Reconhecer código PHP ofuscado](https://phpsos.de/pt/blog/verschleierter-php-code/): Código PHP ilegível com eval e base64_decode é um sinal clássico de código malicioso introduzido. Que padrões procurar, como encontrá-los sem perigo e quando a ofuscação é legítima.
- [Verificar as ligações de saída de um servidor](https://phpsos.de/pt/blog/ausgehende-verbindungen-pruefen/): Um servidor web responde sobretudo a pedidos. Se ele próprio estabelece ligações a destinos desconhecidos, pode significar controlo por atacantes ou fuga de dados. Como verificar e limitar o tráfego de saída.
- [Encontrar contas de administrador estranhas no CMS e no servidor](https://phpsos.de/pt/blog/fremde-admin-konten-finden/): Um administrador desconhecido é muitas vezes a porta dos fundos mais simples. Como procurar nível a nível contas estranhas, também as que a interface esconde.
- [Encontrar e remover chaves SSH desconhecidas](https://phpsos.de/pt/blog/ssh-schluessel-pruefen/): Uma chave SSH introduzida abre a porta aos atacantes, mesmo depois de todas as palavras-passe terem sido alteradas. Como encontrar cada ficheiro authorized_keys e verificar cada entrada.
- [Criptomineiro no servidor web: sinais e como proceder](https://phpsos.de/pt/blog/kryptominer-auf-dem-server/): CPU permanentemente cheia sem que venham mais visitantes: pode ser um criptomineiro. Como verificar a carga, encontrar o processo e os seus mecanismos de reinício e proceder de forma ordenada.
- [O servidor envia spam: encontrar as causas](https://phpsos.de/pt/blog/server-verschickt-spam/): Mensagens não entregues, listas de bloqueio, queixas: quando o próprio servidor envia spam, por trás está em regra um script ou uma caixa de correio sequestrada. Como encontrar a origem.
- [Spam de SEO e páginas alheias no índice do Google](https://phpsos.de/pt/blog/seo-spam-im-google-index/): De repente, sob o seu domínio aparecem páginas sobre medicamentos ou artigos de marca. Como descobrir de onde vem o spam de SEO e voltar a tirá-lo do índice.
- [O site reencaminha para páginas alheias](https://phpsos.de/pt/blog/website-leitet-um/): Os visitantes acabam em concursos ou lojas duvidosas, mas do seu lado tudo parece normal? Como encontrar a camada onde está o redirecionamento e eliminá-lo.
- [Preservar provas antes de reinstalar o servidor](https://phpsos.de/pt/blog/beweise-sichern-vor-neuinstallation/): Reconstruir elimina o atacante, mas também todos os vestígios. Quem investir antes uma hora na preservação de provas poderá dizer depois o que aconteceu.
- [Elaborar a cronologia de um incidente](https://phpsos.de/pt/blog/zeitleiste-eines-vorfalls/): Quando chegou o atacante, o que fez, quando foi notado? Uma cronologia bem feita responde a estas perguntas e é a base para notificações, seguro e relatório.
- [Comparar os ficheiros principais do CMS com o original](https://phpsos.de/pt/blog/cms-kerndateien-vergleichen/): A comparação com um original limpo mostra cada ficheiro alterado, quer um scanner o conheça ou não. Como montar a comparação para WordPress, projetos Composer e pacotes do sistema.
- [Verificar na base de dados a presença de código introduzido](https://phpsos.de/pt/blog/datenbank-auf-schadcode-pruefen/): Quem só verifica ficheiros deixa passar metade. Como procurar código introduzido nos conteúdos, definições, triggers e contas da base de dados, só em leitura e numa cópia.
- [Scanners de malware para sites: o que encontram e o que não encontram](https://phpsos.de/pt/blog/grenzen-von-malware-scannern/): O scanner não comunica nada, logo está tudo bem? Não necessariamente. Que tipos de scanners de sites existem, o que cada um vê e o que não consegue ver por princípio.
- [Isolar pools PHP-FPM por site](https://phpsos.de/pt/blog/php-fpm-pools-isolieren/): Um pool próprio por site é o início, não o fim. Como verificar os pools existentes e reforçar sockets, extensões, páginas de estado, recursos e registos.
- [Definir corretamente o memory_limit](https://phpsos.de/pt/blog/memory-limit-richtig-setzen/): O memory_limit limita a memória de cada pedido PHP. Após o PHP2Shell, o php.net aconselha temporariamente o contrário. O que vale em operação normal, na fase transitória e depois da atualização.
- [Limitar com critério post_max_size e upload_max_filesize](https://phpsos.de/pt/blog/post-max-size-upload-limits/): Os limites de upload atuam em três locais: no servidor web, no PHP e na aplicação. Como definir os valores de forma coerente, incluindo os valores transitórios do php.net para o PHP2Shell.
- [Desativar o session.upload_progress: de forma correta e duradoura](https://phpsos.de/pt/blog/session-upload-progress-abschalten/): A solução para a CVE-2026-115560 e uma das medidas transitórias do PHP2Shell define-se depressa. Para durar, tem de estar no sítio certo, estar bloqueada e ser verificada de novo após cada atualização.
- [expose_php e cabeçalhos Server: ocultar a versão](https://phpsos.de/pt/blog/expose-php-versionsangaben/): O PHP, o Nginx e o Apache indicam por defeito o número da versão em cada resposta. Isso não protege contra ataques, mas dá aos scanners uma lista cómoda de alvos. Como desativar e manter, ainda assim, a visão geral.
- [display_errors off: desativar a saída de erros em produção](https://phpsos.de/pt/blog/display-errors-produktion/): As mensagens de erro visíveis do PHP revelam caminhos, nomes de bases de dados e versões. Como as desativar no PHP, na framework e no servidor web sem perder os erros de vista.
- [php_admin_value: bloquear definições contra a sobrescrita](https://phpsos.de/pt/blog/php-admin-value-sperren/): Uma definição de segurança serve de pouco se a aplicação a voltar a alterar com uma linha de código. Com php_admin_value e php_admin_flag, fixa valores de forma vinculativa para o PHP-FPM e o Apache.
- [Definir limites de memória com systemd e cgroups](https://phpsos.de/pt/blog/speichergrenzen-systemd-cgroups/): O php.net recomenda, como medida transitória do PHP2Shell, memory_limit=-1 e um limite de memória fora do PHP. Como definir esse limite com systemd e cgroups sem que um único worker arraste todo o serviço.
- [Configurar o Nginx para PHP com segurança](https://phpsos.de/pt/blog/nginx-fuer-php-absichern/): A maioria das vulnerabilidades nas configurações Nginx para PHP não está no Nginx, mas em poucas linhas da location PHP. Como configurar a passagem ao PHP-FPM de modo que só sejam executados os scripts pretendidos.
- [Configurar o Apache para PHP com segurança](https://phpsos.de/pt/blog/apache-fuer-php-absichern/): O Apache é flexível, e é precisamente isso que o torna vulnerável a erros de configuração. Como ligar o PHP através do PHP-FPM, fechar o .htaccess como porta dos fundos e definir com segurança as opções centrais mais importantes.
- [Proibir a execução de PHP em pastas de uploads](https://phpsos.de/pt/blog/php-in-uploads-verbieten/): Uma webshell precisa de duas coisas: uma pasta onde possa ser escrita e um servidor que a execute. Como retirar-lhe a segunda, e em todas as pastas com escrita, não apenas em uploads.
- [Filtrar pedidos de upload na periferia: oportunidades e riscos](https://phpsos.de/pt/blog/upload-anfragen-am-rand-filtern/): Autores especializados propõem bloquear no proxy os pedidos de upload fora dos caminhos de upload reais até o PHP ser corrigido. Pode ajudar, mas também paralisar formulários e encomendas. Como proceder de forma controlada.
- [Utilizar o ModSecurity e o OWASP Core Rule Set](https://phpsos.de/pt/blog/modsecurity-owasp-crs/): Uma Web Application Firewall própria com ModSecurity e o OWASP Core Rule Set é gratuita e poderosa, mas não funciona sozinha. Como escolher o motor, começar sem falhas e afinar as regras.
- [Configurar o Fail2ban para servidores web](https://phpsos.de/pt/blog/fail2ban-fuer-webserver/): O Fail2ban bloqueia endereços que se destacam repetidamente nos registos. Para servidores web traz filtros prontos, e com poucas linhas acrescentam-se filtros próprios. Como configurá-lo sem bloquear a si próprio ou os seus clientes.
- [Firewall para servidores web: abrir só as portas necessárias](https://phpsos.de/pt/blog/firewall-fuer-webserver/): Um servidor web precisa, para o exterior, em regra de apenas duas portas. Ainda assim, em muitos servidores há bases de dados, PHP-FPM ou interfaces de administração à escuta na Internet. Como encontrar serviços abertos e fechar o que não é necessário.
- [Atualizações de segurança automáticas em servidores Linux](https://phpsos.de/pt/blog/automatische-sicherheitsupdates/): Segundo relatos, as distribuições entregaram backports do PHP em parte ainda a 21 de outubro de 2026, o dia dos patches. Quem usa atualizações de segurança automáticas tinha-os depressa no servidor. Para que também atuem, são precisos reinícios, fontes de terceiros e controlo.
- [Least Privilege: permissões do utilizador do servidor web](https://phpsos.de/pt/blog/rechte-des-webserver-benutzers/): O código introduzido corre com as permissões do utilizador do servidor web. O que esta conta pode fazer decide até onde chega um atacante. Como limitar shell, sudo, cron, base de dados e sistema de ficheiros ao necessário.
- [Proteger as áreas de administração com IP, VPN ou proteção adicional](https://phpsos.de/pt/blog/admin-bereiche-abschirmen/): Porque é que o backend de um site não tem de estar acessível ao mundo inteiro e como o proteger com lista de IP, VPN ou autenticação prévia, sem se trancar de fora.
- [Configurar corretamente o TLS e o HTTPS](https://phpsos.de/pt/blog/tls-https-richtig-konfigurieren/): Que versões de TLS e cipher suites um servidor web deve oferecer hoje, em que se baseiam as recomendações e como verificar o Nginx, o Apache e as ligações de saída do PHP.
- [CIS Benchmarks e módulos do BSI para servidores web](https://phpsos.de/pt/blog/cis-benchmarks-bsi-bausteine/): Que normas de reforço existem para servidores web Linux, em que diferem os CIS Benchmarks e os módulos do IT-Grundschutz e como transformá-los numa diretriz verificável para os seus servidores PHP.
- [Guardar palavras-passe em PHP com segurança: usar corretamente o password_hash](https://phpsos.de/pt/blog/passwoerter-in-php-speichern/): Como os programadores guardam palavras-passe em PHP com password_hash e password_verify, escolhem o procedimento adequado e substituem hashes MD5 ou SHA-1 antigos sem repor a palavra-passe de todos os utilizadores.
- [Proteção CSRF em aplicações PHP](https://phpsos.de/pt/blog/csrf-schutz-php/): Como os programadores evitam o Cross-Site Request Forgery em aplicações PHP: tokens para cada pedido que altera dados, verificação da origem no cabeçalho e cookies SameSite como camada adicional.
- [Validar e filtrar entradas em PHP com filter_var](https://phpsos.de/pt/blog/eingaben-validieren-php/): Como os programadores verificam entradas em PHP com filter_var, filter_input_array e listas de permissão, que filtros estão obsoletos e porque é que a validação não substitui prepared statements nem a codificação da saída.
- [Evitar Command Injection em PHP](https://phpsos.de/pt/blog/command-injection-php/): Como os programadores evitam a Command Injection em PHP: substituir comandos de sistema por funções PHP, usar proc_open sem shell, verificar argumentos e encontrar pontos perigosos no código existente.
- [Evitar Server-Side Request Forgery (SSRF) em PHP](https://phpsos.de/pt/blog/ssrf-in-php/): Como os programadores impedem que uma aplicação PHP consulte sistemas internos por conta de terceiros: listas de permissão, restrição de protocolos, verificação do endereço resolvido e limites na rede.
- [Evitar XML External Entities (XXE) em PHP](https://phpsos.de/pt/blog/xxe-in-php/): Como os programadores processam XML em PHP com segurança: comportamento por defeito da libxml, opções arriscadas como LIBXML_NOENT, proteção com entity loader e LIBXML_NO_XXE e entradas XML ocultas típicas.
- [Type juggling em PHP: comparações laxas como risco de segurança](https://phpsos.de/pt/blog/type-juggling-php/): Porque é que as comparações laxas com == em PHP podem levar a falhas de segurança, o que mudou com o PHP 8.0 e como escrever comparações robustas em inícios de sessão, tokens e permissões.
- [Números aleatórios e tokens seguros em PHP com random_bytes](https://phpsos.de/pt/blog/sichere-tokens-php/): Como os programadores geram em PHP tokens para links de palavra-passe, chaves de API e códigos de utilização única: fontes criptograficamente seguras, comprimento suficiente, armazenamento como hash e validade limitada.
- [Proteger corretamente credenciais e ficheiros .env](https://phpsos.de/pt/blog/env-dateien-schuetzen/): Como proteger palavras-passe de bases de dados, chaves de API e outros segredos em projetos PHP: ficheiros .env fora do webroot, bloqueios no servidor web, permissões restritas e substituição ordenada após um incidente.
- [Pasta .git pública: uma fuga de dados subestimada](https://phpsos.de/pt/blog/git-ordner-oeffentlich/): Porque é que um webroot implementado via Git pode expor todo o código-fonte com o histórico, como o verificar, bloquear de imediato e montar o deployment de forma duradoura sem a pasta .git.
- [Ficheiros de backup no webroot: .zip, .sql e .bak](https://phpsos.de/pt/blog/backup-dateien-im-webroot/): Porque é que dumps de bases de dados, arquivos e cópias de segurança no diretório público estão entre as fugas de dados mais frequentes, como os encontrar, bloquear e esclarecer se foram consultados.
- [Ficheiros phpinfo(): porque têm de desaparecer](https://phpsos.de/pt/blog/phpinfo-dateien-entfernen/): Após o PHP2Shell, muitos administradores criam depressa um info.php. Porque é que esses ficheiros são uma fuga de dados, como os encontrar e que formas de verificação são melhores.
- [Manter as dependências atualizadas: Composer, npm e plugins](https://phpsos.de/pt/blog/abhaengigkeiten-aktuell-halten/): Um projeto assenta em três mundos de pacotes: Composer, npm e plugins de CMS. Como manter os três atualizados com um ritmo fixo, responsabilidade clara e testes.
- [Code review de segurança para projetos PHP](https://phpsos.de/pt/blog/sicherheits-code-review-php/): Como as equipas examinam o código PHP próprio à procura de falhas de segurança: tipos de revisão, funções críticas, ferramentas úteis e uma lista de verificação.
- [Registar com segurança: registar erros sem fuga de dados](https://phpsos.de/pt/blog/sicher-loggen-php/): Os registos ajudam na deteção de erros e na perícia forense, mas tornam-se depressa uma fuga de dados. O que as aplicações PHP devem registar, o que nunca e como proteger os registos.
- [Proteger APIs REST em PHP](https://phpsos.de/pt/blog/rest-api-php-absichern/): As interfaces estão muitas vezes pior protegidas do que o site que está à frente. As regras mais importantes para APIs REST em PHP, da permissão por objeto à limitação de taxa.
- [Contratos com prestadores de serviços de TI: regular com clareza as obrigações de segurança](https://phpsos.de/pt/blog/dienstleistervertrag-sicherheit/): O PHP2Shell mostrou como é muitas vezes pouco claro quem tem de aplicar os patches. Que obrigações de segurança devem constar dos contratos com agência, fornecedor de alojamento e prestador de TI.
- [Subcontratação de dados quando prestadores acedem a servidores](https://phpsos.de/pt/blog/auftragsverarbeitung-serverzugriff/): Quem deixa externos entrar em servidores com dados de clientes precisa quase sempre de um contrato de subcontratação (AVV). O que exige o Art. 28 RGPD e como organizar os acessos de emergência em conformidade com a proteção de dados.
- [Gestão de vulnerabilidades para PME](https://phpsos.de/pt/blog/schwachstellenmanagement-mittelstand/): Nenhuma PME consegue tratar de imediato todos os alertas. Um ciclo enxuto de registar, avaliar, decidir e comprovar garante que o mais importante é feito primeiro.
- [Saber o que está a correr: inventário de todos os sites e servidores](https://phpsos.de/pt/blog/inventar-websites-server/): No PHP2Shell, muitos não tropeçaram no patch, mas na pergunta de onde corre sequer PHP. Eis como montar um inventário de todos os sites e servidores.
- [Gestão de patches como processo e não como combate a incêndios](https://phpsos.de/pt/blog/patch-management-prozess/): Quem só aplica patches quando há fogo perde tempo na emergência. Como um processo de gestão de patches, com classes, janelas e comprovativos fixos, une rotina e emergência.
- [Contactos de emergência: quem deve ser informado e quando?](https://phpsos.de/pt/blog/notfallkontakte-liste/): Numa emergência, conta quem se consegue contactar e quando. Como montar uma lista de contactos de emergência de TI, com gatilhos, substitutos e os dados de que cada chamada precisa.
- [O que custa um servidor invadido: as rubricas de custo](https://phpsos.de/pt/blog/kostenposten-eines-hacks/): Um servidor web invadido causa mais custos do que a reparação. Que rubricas surgem e como justificar, com números próprios, um orçamento para a prevenção.
- [Informar os clientes após um incidente](https://phpsos.de/pt/blog/kunden-nach-vorfall-informieren/): Seja obrigação ou opção: como decidir, após um incidente, quem informar, que canais são seguros e como preparar o apoio ao cliente.
- [A cadeia de fornecimento na web: agência, alojamento, fornecedores de plugins](https://phpsos.de/pt/blog/lieferkette-agentur-hoster/): O PHP2Shell mostrou quantos elos existem entre um patch e o seu site. Como conhecer e proteger a cadeia de fornecimento do seu site e absorver falhas de elos individuais.
- [Consciência de segurança para administradores e editores: sensibilização na equipa web](https://phpsos.de/pt/blog/sicherheitsbewusstsein-redaktion/): Quem mantém sites decide todos os dias sobre segurança, muitas vezes sem o notar. Como formar administradores e editores por função e sem maratonas de diapositivos.
- [Exercício de emergência à mesa: simular um incidente num servidor web](https://phpsos.de/pt/blog/notfalluebung-am-tisch/): Um exercício à mesa custa uma tarde e mostra se o seu plano de emergência aguenta. Aqui encontra um guião pronto para um incidente num servidor web PHP.
- [ISO 27001 e TISAX: o que afeta os servidores web](https://phpsos.de/pt/blog/iso-27001-tisax-webserver/): Quem opera um SGSI segundo a ISO 27001 ou tem um selo TISAX tem de ter em conta os servidores web. Eis que requisitos os tocam e que comprovativos contam após o PHP2Shell.
- [VdS 10000: segurança da informação para pequenas e médias empresas](https://phpsos.de/pt/blog/vds-10000-kmu/): A VdS 10000 é um quadro enxuto de segurança da informação para PME. O que exige, o que trouxe de novo em 2025 e o que isso significa para sites e servidores web.
- [Lições aprendidas: melhorar depois do incidente](https://phpsos.de/pt/blog/lessons-learned-nach-vorfall/): Depois do incidente vem o próximo. Um balanço estruturado, sem atribuição de culpas, transforma uma má semana num progresso mensurável.
- [Aplicar patch, desligar ou esperar? Uma ajuda à decisão perante a falha do PHP](https://phpsos.de/pt/blog/patchen-abschalten-abwarten/): Perante uma vulnerabilidade crítica do PHP, os responsáveis têm de decidir depressa. Esta ajuda ordena as três opções, indica critérios e mostra quando esperar é defensável.
- [WAF ou atualização: porque precisa de ambas](https://phpsos.de/pt/blog/waf-oder-update/): Uma firewall de aplicações web pode travar ataques, mas não fecha uma vulnerabilidade no interpretador PHP. Quando a WAF ajuda, onde acaba e como combinar ambas com sentido.
- [Reinstalar ou limpar o servidor? A decisão após uma infeção](https://phpsos.de/pt/blog/neu-aufsetzen-oder-bereinigen/): Após uma intrusão há dois caminhos: limpar o servidor ou reconstruí-lo. Que critérios decidem e porque é que a ordem é mais importante do que a escolha.
- [Resolver sozinho ou contratar um prestador de serviços? Uma ponderação honesta](https://phpsos.de/pt/blog/selbst-beheben-oder-dienstleister/): Nem toda a situação de segurança precisa de ajuda externa. Com estes critérios e um breve autoteste, decida se a sua equipa resolve o PHP2Shell sozinha ou precisa de apoio.
- [Escolher um prestador de serviços de segurança de TI: 12 perguntas antes de contratar](https://phpsos.de/pt/blog/sicherheitsdienstleister-auswaehlen/): Sob pressão de tempo, é difícil encontrar um bom prestador de serviços de segurança. Estas doze perguntas ajudam a comparar propostas com objetividade, sem cair em promessas publicitárias.
- [Alojamento gerido ou servidor próprio? A comparação de segurança](https://phpsos.de/pt/blog/managed-oder-eigener-server/): O PHP2Shell foi um teste de esforço a todos os modelos de operação. A comparação mostra quando o alojamento gerido é mais seguro, quando o servidor próprio o é, e que formas mistas resultam.
- [Atualização do PHP ou backport? A decisão para sistemas antigos](https://phpsos.de/pt/blog/php-upgrade-oder-backport/): Para versões antigas do PHP há, após o PHP2Shell, vários caminhos: backport da distribuição, fonte de terceiros, patch ao código-fonte, suporte de longo prazo ou atualização. O que vale cada um e quanto tempo aguenta.
- [Mudar de CMS depois do ataque? Quando ajuda e quando não](https://phpsos.de/pt/blog/cms-wechsel-nach-hack/): Após uma intrusão, a confiança no CMS desaparece muitas vezes. Mas um sistema novo raramente resolve a verdadeira causa. Quando a mudança faz sentido e como fazê-la sem riscos.
- [Sites estáticos: menos PHP, menos superfície de ataque](https://phpsos.de/pt/blog/statische-website-alternative/): Um site estático entrega ficheiros HTML prontos e dispensa PHP no servidor. Isso reduz bastante a superfície de ataque, mas traz limites e deveres próprios.
- [Pentest, bug bounty ou análise de vulnerabilidades? Escolher o método de verificação certo](https://phpsos.de/pt/blog/pentest-bugbounty-scan/): A análise, o teste de intrusão e o bug bounty verificam sites de formas muito diferentes. O que cada método consegue, onde falha e que sequência se adequa à sua empresa.