Eu já perdi a conta de quantas noites em claro passei por causa de um CVE novo pipocando na stack. Você recebe o alerta, o time de segurança entra em pânico, e o Slack vira um festival de perguntas: ‘afeta a gente?’, ’temos esse pacote em produção?’, ‘quem mantém esse container mesmo?’. A rotina de quem mexe com DevOps ou cuida de deploy em cloud já virou basicamente isso — gerenciar sustos e separar o que é ruído do que é risco real.

Semana passada, enquanto rolava aquele cafezinho pós-almoço, alguém soltou: ‘vocês viram a vulnerabilidade de PHP? Chamaram de PHP2Shell, parece braba’. O clima na mesa mudou, porque, convenhamos, toda vez que falam em remote code execution (RCE) em linguagem popular, a galera sente o chão tremer. Eu fui atrás da notícia e, pra quem não viu, a Microsoft publicou um post explicando o impacto desses CVEs no Azure DevOps (tá aqui a fonte original: PHP2Shell and Azure DevOps: what to check).

Entendendo o que rolou

No dia 21 de outubro de 2026, o time do PHP divulgou duas falhas críticas que permitem execução remota de código. E não é qualquer falha — é daquelas que tem potencial pra virar headline no Twitter e gerar exploit em menos de 24 horas. Chamar de PHP2Shell não é exagero: o atacante pode transformar qualquer instância vulnerável num ponto de entrada na sua infraestrutura.

A questão no contexto do Azure DevOps era óbvia: alguém pode explorar isso dentro dos serviços de pipeline, repositórios ou aplicações deployadas por lá? O post da Microsoft esclarece direto — nem o Azure DevOps Services (na nuvem) nem o Azure DevOps Server (on-premises) usam PHP pra lidar com requisições dos clientes, então quem só usa o DevOps puro, sem customização, pode respirar aliviado. Mas aí vem a pegadinha: pipelines, containers e aplicações que você sobe e gerencia podem sim estar rodando PHP desatualizado, aí o problema é seu mesmo.

Por que isso importa

Por mais que o PHP viva sendo meme pra muita gente, ele ainda é base de milhares de aplicações. WordPress, Magento, plataformas legadas — tudo isso aparece até hoje em pipelines CI/CD do Azure, seja rodando teste, buildando imagem de container ou sendo deployado numa VM. E é aí que mora o perigo: a própria plataforma da Microsoft pode não ser vulnerável, mas o que você coloca nela pode estar furado.

Esse tipo de problema expõe um ponto crítico da automação moderna: a responsabilidade do patch não é só do provedor da nuvem, mas de quem monta e mantém os ambientes. Eu já vi deploy automático empacotar aplicação PHP com imagem antiga, e só descobrimos o risco quando rolou um scan de compliance por acaso. O pessoal acha que, por estar na cloud, “alguém deve estar cuidando da segurança”. Spoiler: quase nunca estão.

Outra coisa que não dá pra ignorar é o delay entre a divulgação da vulnerabilidade e o rollout do patch. Mesmo nos sistemas mais automatizados, a cadeia de atualização pode demorar. Se você usa container, a imagem oficial provavelmente já atualizou, mas e aquela imagem customizada no seu repositório privado? Já vi time ficar dois meses rodando código vulnerável porque ninguém atualizou o Dockerfile.

No contexto do Azure DevOps, o problema escala: times grandes, múltiplos pipelines, dezenas de ambientes que ninguém sabe direito quem mantém. E quando falha, a culpa sempre cai em cima do DevOps — já tive que explicar pra gestor querendo saber “como deixamos isso passar”, sendo que o código vulnerável tava num pacote de terceiros buildado há anos.

Na prática

Se você mantém alguma pipeline que envolve PHP — build, teste, deploy — chegou a hora de revisar as imagens e os runtimes. Não confie só no que vem “by default” no Azure DevOps. O próprio post da Microsoft deixa claro: o ambiente é responsabilidade de quem o define.

Quer saber onde olhar? Se você usa container, começa pelo seu Dockerfile:

FROM php:8.2-apache   # Verifique se essa imagem já foi atualizada com o patch
# Outras configurações

Se está rodando direto na VM, garanta que o pacote foi atualizado:

sudo apt update && sudo apt upgrade php   # Vai garantir o patch mais recente

E no pipeline YAML, vale checar se está pegando sempre a última versão:

- script: |
    composer install
    php -v  # Veja a versão retornada aqui

Nunca é demais configurar um scanner automático de CVEs no pipeline — Azure DevOps permite gambiarras assim com tasks customizadas ou integração com ferramentas tipo Whitesource, Snyk, Trivy. Isso já me salvou de deployar aplicação com vulnerabilidade zero-day sem nem perceber.

O que eu acho disso

Confesso que sempre fico com um pé atrás quando vejo empresas grandes aliviando a própria barra nesses comunicados. “Não usamos PHP pra lidar com requisição de cliente” é tecnicamente correto, mas não livra ninguém do perrengue se a stack for customizada. O recado implícito é: se você construiu um Frankenstein de pipeline e runtime, a dor de cabeça é sua mesmo, não reclame com o suporte.

Olhando com mais distância, é aquela velha história: automação e cloud facilitam o deploy, mas nunca vão eliminar a necessidade de revisar ambiente e manter dependência em dia. Quem depende de PHP nos pipelines do Azure precisa criar rotina de patch, usar imagens oficiais e automatizar o máximo possível os scans. Tem coisa que não dá pra delegar pra plataforma.

Minha preocupação maior é com projetos esquecidos, scripts de build antigos e imagens rodando há anos sem manutenção. Essas são as portas de entrada preferidas do atacante — e raramente alguém faz inventário completo disso, principalmente em times grandes.

E aí, na sua stack, tem algum PHP largado?

Quero ouvir histórias de quem já sofreu com patch correndo atrás de CVE. Você já pegou alguma surpresa dessas em pipeline ou deploy? Conta aí.