A falha CVE-2026-17543, corrigida nas versões 8.2.33, 8.3.33, 8.4.24 e 8.5.9 do PHP lançadas em 30 de julho de 2026, é uma vulnerabilidade de injeção de SQL na extensão PostgreSQL (ext-pgsql) que recebeu nota CVSS 4.0 de 8,1 e a classificação de fraqueza CWE-89. O problema permite que um atacante remoto leia ou altere dados protegidos por meio de uma quebra de escape de barra invertida nas funções pg_insert, pg_update, pg_select e pg_delete. Não há exploração confirmada na natureza até o momento, mas as correções já estão disponíveis e devem ser aplicadas com prioridade por qualquer instalação que use a extensão pgsql.

Como a injeção de SQL funciona

A raiz do problema está na rotina de escape usada pela extensão PostgreSQL do PHP. Na configuração padrão do PostgreSQL, a rotina de escape não trata corretamente o caractere de barra invertida presente em parâmetros fornecidos pelo atacante. Esse descuido permite a chamada quebra de escape (backslash breakout) em literais de string delimitados por E'...': o atacante consegue fechar a string prematuramente e injetar uma consulta SQL própria. As quatro funções de alto nível da extensão são todos caminhos viáveis de exploração.

Como o ataque trafega pela rede, com complexidade baixa e sem necessidade de privilégios ou interação do usuário, qualquer aplicação web que exponha esses caminhos a entrada externa fica exposta de imediato. O resultado prático é a violação de confidencialidade, integridade e disponibilidade dos dados — as três dimensões marcadas como altas no vetor CVSS 4.0 publicado pela equipe do PHP, que atua como Autoridade de Numeração de CVE.

O impacto vai além de uma leitura indevida de registros isolados. Em sistemas que concentram consultas de leitura e escrita na extensão pgsql, a injeção pode escalar para extração em massa de tabelas, alteração silenciosa de saldos ou permissões e, em cenários mais graves, execução de comandos no banco por meio de funções armazenadas. Por isso, mesmo sem prova de exploração ativa, o risco residual de manter versões não corrigidas é alto.

Versões afetadas e gravidade

A falha afeta as famílias 8.2, 8.3, 8.4 e 8.5 do PHP, em todos os builds anteriores aos pontos de correção. A classificação oficial, registrada no NVD em 30 de julho de 2026, atribui CVSS-BT 8,1 na escala 4.0 e o tipo de fraqueza CWE-89 (injeção de SQL). O coordenador da CISA avaliou o impacto técnico como total no modelo SSVC, o que significa que uma exploração bem-sucedida poderia comprometer completamente o sistema afetado.

Mesmo sem exploração ativa documentada, a existência de um código de prova de conceito público e uma probabilidade EPSS inicial de 0,39% mantêm a falha no radar de equipes que priorizam correções por risco. O alcance é amplo porque o PHP roda uma fatia enorme da web pública; qualquer instalação que combine a extensão PostgreSQL com parâmetros derivados de entrada externa permanece em risco até aplicar o patch. A tabela abaixo resume o lote completo de correções liberado no mesmo dia:

CVE CVSS 4.0 Tipo Versões corrigidas
CVE-2026-17543 8,1 Injeção de SQL (ext-pgsql) 8.2.33, 8.3.33, 8.4.24, 8.5.9
CVE-2026-17544 8,1 Gravação fora dos limites (BCMath) 8.4.24, 8.5.9
CVE-2026-7260 5,4 Estouro de pilha (phar) 8.2.33, 8.3.33, 8.4.24, 8.5.9

Em outras palavras, o mesmo lote de versões corrigiu ainda outras duas falhas: a CVE-2026-17544, uma gravação fora dos limites em bccomp() da extensão BCMath também com nota 8,1, e a CVE-2026-7260, um estouro de pilha em phar via symlinks circulares, classificada como 5,4. As duas primeiras exigem atenção imediata por potencial de corrupção de dados e de memória.

Plano de correção e mitigação

A correção direta é aplicar um build corrigido do PHP. Siga a ramificação ativa da sua instalação e não adie o ciclo de testes:

  1. Inventarie todos os servidores e contêineres que executam PHP 8.2, 8.3, 8.4 ou 8.5 com a extensão pgsql habilitada.
  2. Atualize para 8.2.33, 8.3.33, 8.4.24 ou 8.5.9 conforme a ramificação, verificando as assinaturas GPG antes de implantar.
  3. Reconstrua imagens de contêiner para que o runtime carregue o novo binário; reiniciar o processo sem trocar o pacote não elimina a exposição.
  4. Valide em homologação antes da produção e monitore logs de banco em busca de consultas anômalas após a implantação.

Como defesa adicional, prefira consultas parametrizadas (prepared statements) em vez de escapar manualmente a entrada do usuário. Esse hábito blinda a aplicação contra toda a classe de injeção de SQL, e não apenas contra este CVE específico, e reduz a superfície de ataque mesmo em versões ainda não atualizadas. Calibre o ritmo de resposta da sua equipe com base em casos recentes de zero-days que exigem mais do que um simples patch e na rotina de triagem do catálogo KEV da CISA, dois fluxos que ajudam a ordenar correções por risco real.

Fontes