Vulnerabilidades em PHP são fraquezas no tempo de execução do PHP, código da aplicação, pacotes de terceiros ou configuração do servidor que podem expor um site a acesso não autorizado, roubo de dados ou interrupção. Exemplos comuns incluem injeção de SQL, scripting entre sites (XSS), uploads inseguros de arquivos e controles de acesso quebrados.
A distinção é importante porque as correções são diferentes. Uma falha de segurança no tempo de execução requer um build de PHP corrigido. Um bug de autorização requer uma mudança no código ou na política. Atualizar o PHP é essencial, mas não reparará automaticamente todas as fraquezas em um site construído com ele.
Para serviços de cripto, os riscos podem incluir controles de saque, credenciais de API e os detalhes da transação exibidos aos usuários da carteira. Um site comprometido não significa que as regras de consenso do Bitcoin ou a criptografia de um blockchain foram quebradas.
Comece Com Software Suportado e Corrigido
Atualização de segurança, 22 de outubro de 2026: O aviso de 21 de outubro do PHP identificou duas vulnerabilidades críticas de execução remota de código, CVE-2026-109618 e CVE-2026-109619. As versões corrigidas para branches suportadas foram PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A equipe do PHP instou os usuários a atualizarem; mitigações temporárias não substituem completamente o patching. Verifique o anúncio oficial de segurança e as orientações do seu provedor de hospedagem.
Use a versão corrigida aplicável ou uma versão estável posterior corrigida. Fornecedores de distribuição podem fazer backport de correções de segurança, portanto, verifique o status do aviso do pacote em vez de julgar apenas sua string de versão. Confirme que o tempo de execução que serve a web — não apenas o PHP de linha de comando — foi atualizado e que os workers relevantes foram reiniciados.
Mantenha um plano de atualização também. O suporte de segurança upstream do PHP 8.2 termina em 31 de dezembro de 2026; receber este patch específico não estende seu ciclo de vida de suporte normal.
Injeção de SQL: Mantenha os Dados Fora da Estrutura da Consulta
A injeção de SQL ocorre quando entrada não confiável se torna parte de um comando de banco de dados. A correção principal é vincular valores de dados por meio de instruções preparadas em vez de juntar a entrada do usuário em strings SQL. A documentação PDO do PHP explica a separação.
Por exemplo, uma consulta de artigo privado pode vincular tanto um ID de artigo validado quanto a identidade do usuário autenticado no lado do servidor:
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);Placeholders protegem valores de dados, não nomes de tabelas arbitrárias, nomes de colunas ou direções de ordenação. Mapeie essas escolhas para valores fixos e permitidos. Mantenha os privilégios do banco de dados limitados também: a aplicação raramente precisa de uma conta que possa administrar todo o banco de dados.
Scripting Entre Sites (XSS): Codifique Para o Contexto de Saída
Scripting entre sites, ou XSS, ocorre quando conteúdo não confiável é interpretado como conteúdo executável do navegador. Um comentário, campo de perfil ou documento importado pode se tornar perigoso quando uma página o renderiza incorretamente.
Use a codificação automática do seu framework e mantenha dados não confiáveis fora de contextos executáveis. Para texto simples colocado entre tags HTML comuns, o htmlspecialchars() do PHP com tratamento explícito de UTF-8 é uma ferramenta apropriada. Não é uma solução universal para JavaScript, CSS ou URLs.
Se os usuários precisarem enviar HTML rico, use um sanitizador de HTML mantido e baseado em lista de permissões em vez de tratar toda a entrada como confiável. Uma Política de Segurança de Conteúdo (CSP) adiciona outra camada; ela não substitui o manuseio correto do conteúdo. Essas distinções são abordadas nas orientações de prevenção de XSS da OWASP.
Uploads e Manipulação de Arquivos: Controle o Que o Servidor Aceita
Um recurso de upload não deve permitir que um usuário decida qual arquivo executável aparece no servidor. Permita apenas os tipos de arquivo necessários para o produto, verifique o conteúdo em vez de confiar no tipo MIME declarado pelo navegador, imponha limites de tamanho e gere nomes de arquivo no lado do servidor.
Armazene uploads não confiáveis fora da raiz web ou em armazenamento separado, com recuperação controlada. Garanta que a configuração de serviço não possa executar o conteúdo carregado. Autenticação, autorização e inspeção apropriada de malware ou conteúdo fornecem salvaguardas adicionais. As orientações de upload de arquivos da OWASP recomendam combinar esses controles.
Aplique a mesma disciplina aos caminhos de arquivo e importações. Mapeie IDs de documentos voltados para o usuário para arquivos aprovados no lado do servidor em vez de passar valores brutos de requisição para funções de inclusão de arquivo. Evite alimentar entrada não confiável em comandos de shell, ou desserialização de objetos PHP. APIs mais seguras e formatos de dados validados reduzem a necessidade dessas operações perigosas.
Autenticação, Sessões e CSRF Precisam de Controles Separados
Autenticação estabelece quem é um usuário; autorização decide o que esse usuário pode fazer. Uma página de login funcional não prova que registros de conta, downloads ou ações administrativas estão protegidos. Verifique as permissões no servidor para cada operação e objeto sensível.
Use funções estabelecidas de manipulação de senhas como password_hash() e password_verify(), proteja contas privilegiadas com MFA e limite tentativas de login abusivas. Para sessões, exija HTTPS, configure atributos de cookie Secure, HttpOnly e SameSite apropriados, renove identificadores de sessão após autenticação ou mudanças de privilégio e invalide sessões no logout. Siga as orientações de gerenciamento de sessão da OWASP em vez de inventar um esquema de sessão personalizado.
Requisições que alteram estado e são autenticadas por cookie também precisam de proteção contra CSRF. Prefira a implementação mantida pelo framework, incluindo validação de token no lado do servidor onde aplicável. Cookies SameSite são uma defesa útil em profundidade, mas não devem ser assumidos como proteção para todas as implantações ou fluxos de requisição. Não use requisições GET para realizar mudanças de estado sensíveis.
Configuração e Dependências São Parte da Aplicação
Um controlador bem escrito ainda pode residir em uma implantação insegura. Mantenha credenciais, chaves privadas, segredos de configuração e backups fora de diretórios públicos. Desabilite a exibição detalhada de erros em produção, mantendo logs controlados por acesso que ajudem a investigar falhas sem coletar segredos desnecessários.
Revise o inventário completo de dependências: o tempo de execução do PHP, extensões, framework, CMS, plugins e pacotes Composer. O comando audit do Composer pode identificar problemas de segurança reportados em dependências, mas não pode certificar que a lógica de aplicação personalizada é segura.
Teste atualizações contra a aplicação e implante de forma reproduzível a partir de versões de dependências revisadas. Remova componentes não utilizados em vez de deixá-los expostos indefinidamente. Restrinja permissões do sistema de arquivos para que um processo de aplicação não possa reescrever tudo no servidor, e separe ferramentas de desenvolvimento da produção.
Como Vulnerabilidades em PHP Podem Afetar Sites de Cripto
A camada de aplicação de um site de cripto pode ser atacada separadamente do blockchain ao qual se conecta. Os seguintes são cenários de risco arquitetônico, não descobertas sobre qualquer exchange ou carteira nomeada.
| Risco de Cripto | O que pode dar errado | Controle Prático |
|---|---|---|
| Abuso de conta custodial ou de saque | Sessões sequestradas ou autorização fraca no lado do servidor | Reautentique ações sensíveis e vincule a aprovação ao destinatário e valor exatos. |
| Engano de endereço de depósito ou assinatura | Conteúdo de página web alterado ou descrições de transação enganosas | Verifique a rede, destinatário, ativo e valor em uma interface de carteira confiável ou display de hardware-wallet legível. |
| Exposição de credenciais de API | Segredos vazados através de código, logs ou arquivos públicos | Mantenha chaves no lado do servidor, escopo de permissões restrito, omita direitos de saque quando desnecessário e rotacione credenciais expostas. |
Proteger uma chave privada não protege automaticamente a decisão de usá-la. As orientações de clear-signing da Trezor explicam por que um front-end comprometido pode descrever incorretamente uma transação. Não aprove requisições que você não pode verificar significativamente, ou insira uma frase de recuperação em um site alegando que ele precisa de uma atualização de segurança.
Aplique o patch ou a mudança de código relevante, e então teste tanto o controle de segurança quanto o comportamento normal do usuário. Inclua testes negativos: um usuário não deve acessar o registro de outra pessoa simplesmente mudando um identificador. Execute testes de segurança apenas contra sistemas que você possui ou está explicitamente autorizado a avaliar.
Se o comprometimento for suspeito, o patching é apenas uma parte da recuperação. Contenha o incidente, preserve evidências úteis, investigue persistência e credenciais expostas, e restaure a partir de um estado limpo verificado. Uma regra de firewall ou um resultado de scanner limpo não estabelece que o acesso de um atacante foi removido.
Perguntas Frequentes
O PHP é inerentemente inseguro?
Não. O risco depende da versão do tempo de execução, design da aplicação, dependências e implantação. Aplicações PHP ainda requerem manutenção de segurança rotineira.
Atualizar o PHP corrigirá injeção de SQL e XSS?
Não necessariamente. Atualizações de tempo de execução corrigem vulnerabilidades de tempo de execução; construção de consulta insegura e manipulação de saída geralmente requerem mudanças na aplicação.
O HTTPS previne vulnerabilidades em PHP?
Não. O HTTPS protege os dados em trânsito. Ele não corrige permissões quebradas, uploads inseguros ou código vulnerável no lado do servidor.
Um firewall de aplicação web pode substituir o patching?
Não. Ele pode reduzir alguma exposição, mas não pode reparar de forma confiável o defeito de software subjacente ou a lógica da aplicação.
Conclusão
Vulnerabilidades em PHP não têm uma única correção universal. Corrija o tempo de execução e as dependências, mantenha os valores do banco de dados separados do SQL, manipule a saída do navegador com segurança, restrinja uploads e imponha controles de acesso no lado do servidor.
Para aplicações de cripto, proteja também a autorização de saque, credenciais de API e detalhes de transações voltados para a carteira. Combine cada fraqueza com o controle correto e verifique esse controle após a implantação. Atualizações, codificação segura e monitoramento operacional trabalham juntos; nenhum substitui os outros.
