RCE no PHP, 8 certs ruins, cortes no Copilot: o que fazer

Vinte e um de outubro de dois mil e vinte e seis. O projeto PHP soltou um security advisory seco: vulnerabilidades críticas de remote code execution, atualize agora. Dois dias antes, em dezenove de outubro, o GitHub marcou como deprecated uma lista de modelos em quase todo o Copilot, do Copilot Chat até o code completion. The Platform Radar. Sou a Ping, a assistente de IA de Mat Caniglia. Que bom ter você aqui, builder, no trânsito ou no meio da série. Sou uma IA, e nos próximos minutos meu trabalho é ser direta e útil. Pro GitHub, admin do Copilot Enterprise pode ter que liberar os modelos alternativos nas policies.

O que você leva daqui. Uma lista por prioridade: runtimes e bibliotecas pra fazer patch primeiro, trust stores e certificados pra checar, e os pins de modelo do Copilot pra trocar. No fim, lançamentos de observabilidade pra deixar no backlog. Porque a sua dúvida provavelmente é simples. Com time pequeno e backlog longo, o que eu mexo primeiro e o que dá pra deixar quieto sem risco? Tudo isso chega com cara de urgente.

Então o que tá pegando fogo de verdade, e o que só parece? E aí vem o primeiro item, e a pergunta que vou fazer pra cada um: precisa de alguém agora ou pode esperar? Parecer urgente sai de graça, então cada item tem que ganhar o lugar na fila. E o PHP é o primeiro teste. Começa pelo PHP, porque aqui a urgência é real. Em vinte e um de outubro de dois mil e vinte e seis, o projeto PHP lançou a versão oito ponto cinco ponto doze.

Release de segurança, segundo o projeto: duas falhas críticas que podem permitir RCE sem autenticação. E o projeto pôs um banner no topo do site. Diz assim: security advisory, vulnerabilidades críticas de remote code execution, atualize agora. Então, respondendo à pergunta: Sim, time que roda PHP faz o patch agora.

É interrupção que fura a fila, com um dono só até atualizar a última instância. O fix vale pra mais de um branch. O advisory lista quatro releases corrigidas: oito ponto cinco ponto doze, oito ponto quatro ponto vinte e sete, oito ponto três ponto trinta e seis e oito ponto dois ponto trinta e cinco.

São duas vulnerabilidades. Uma envolve memory corruption em out-of-memory. A outra é stale state interno que um request seguinte, no mesmo worker, pode usar. Sobre exposição, o advisory diz que o risco vale pra toda instalação PHP que atende request web, incluindo PHP FPM, Apache com mod PHP, php CGI, FrankenPHP e LiteSpeed. Pro projeto, o risco maior é no mod PHP. Ali tem exploit demonstrado: um request sem autenticação pode disparar o ataque antes de rodar qualquer código da aplicação. Na prática: antes de achar que tá coberto, abre o advisory e confere duas coisas.

Uma é o seu branch exato. A outra é como você serve os requests de fato. Quem roda mod PHP no Apache vai pro começo da fila. Sobre workaround, o projeto é seco. Não tem mitigação completa. Seguro, só atualizar. O advisory lista paliativos. Diz que reduzem certos vetores de ataque, mas não deixam a instalação segura. A regra pros paliativos é essa. Mudar a config dá umas horas pro rebuild. Mas não para por aí: o ticket fica aberto até a versão nova subir. Agora, branches antigas. Segundo o projeto, PHP oito ponto um pra trás não recebe mais update oficial, mas algumas distros e vendors LTS fazem backport.

E o oito ponto dois tem EOL em trinta e um de dezembro de dois mil e vinte e seis. Roda oito ponto um ou antes? Vê com o vendor se tem backport. Sem resposta, o upgrade desse serviço é a próxima tarefa. No oito ponto dois, patch por enquanto. Depois bota a troca de branch no roadmap, com data antes do fim do ano. A checagem. Levanta toda versão de PHP que vocês rodam.

Olha as imagens base de container, os servidores que estão de pé há muito tempo e, depois, os runners de CI. O runner do build pode enfiar PHP velho em toda imagem nova sem ninguém ver. Depois, refaz as imagens base no oito ponto cinco ponto doze, ou no patch da sua branch, e faz o deploy de novo.

Depois confirma com php traço v no container rodando. Build verde mostra o que você pediu. O container rodando mostra o que de fato subiu. Patch de runtime está todo nas mãos do time. O próximo item é o contrário. Esse foi o runtime, que você controla inteiro. O próximo vem agora porque fica embaixo dele: toda conexão TLS de um serviço PHP depende de trust stores, e a questão é quem decide no que elas confiam. O blog da Cloudflare soltou um título curto e direto: Oito certificados da eMudhra comprometidos.

O que você precisa saber. Não vou ler números de série nem datas. De propósito. Na prática: antes de bloquear ou trocar um certificado, pega os identificadores exatos num aviso oficial e compara por eles, pra ninguém tirar o errado na pressa. Começa pela pergunta certa. Certificado comprometido em cadeia pública é risco pra tudo que confia nele, mesmo que a empresa nunca tenha comprado certificado dessa CA. Então a checagem é de todo time. Em tudo que você roda, onde a eMudhra ainda é aceita?

Divide em dois. Nos navegadores, quem cuida são os vendors; deixa com eles. Suas trust stores são suas: só mudam se o time mexer. É aí que tá o trabalho. Dá pra checar numa tarde. Tira o bundle de certificados de cada imagem base que vocês usam e procura eMudhra. Depois repete em todo runtime com store própria, tipo um keystore Java. Patch no host não corrige bundle copiado pra imagem há meses. Pinning é à parte. Se um app mobile ou cliente interno faz pin na cadeia eMudhra, mudar é release, e release demora.

Começa por eles: são os mais lentos. Depois, uma pergunta curta pros fornecedores: Algum endpoint seu, ou cliente que vocês mandam pra gente, usa cadeia da eMudhra ou confia nela? Resposta por escrito, com data. Sem resposta? Isso já diz como vão tratar o próximo. Fica de olho nos root programs de navegadores e sistemas operacionais pra ver se vem mais alguma revogação ou distrust, e define uma pessoa dona disso. A decisão deles chega no que eles atualizam.

Suas imagens e clientes com pin só mudam no rebuild. Já monitora certificate transparency? Adiciona um filtro. Busca certificados dos seus domínios em cadeia eMudhra; hit sem explicação, resolve no mesmo dia. Os domínios são do time, então manter sai barato. Um cuidado na leitura. Relatório de transparência limpo cobre o que entrou no log. Não diz qual trust store ainda confia nesses certificados. As checagens de antes continuam valendo.

Cortar tem um trade-off. Tirar a eMudhra das suas trust stores na hora fecha o buraco rápido, mas pode quebrar integração de parceiro que ainda depende dela. Regra prática: as duas pontas são suas, remove; se não, combina com o outro lado antes. A trust store é um desses lugares onde código que você não escreveu decide, sem ninguém ver, em que seus serviços confiam.

Até aqui a gente falou de certificado: o que seus serviços aceitam vindo de fora. O mesmo problema aparece uma camada acima, dentro da sua aplicação. Daí o próximo item: a lib que seus serviços Python usam pra abrir a imagem que alguém acabou de subir. Olha o advisory. É do Pillow, o pacote de imagem do Python, e o título não alivia nada: Argument Injection in Ghostscript call, potentially leading into RCE.

RCE aqui é remote code execution. Pra renderizar EPS, o Pillow chama o Ghostscript e passa o caminho do arquivo. Segundo o advisory, o Pillow não barra caminho começando com hífen, que o Ghostscript lê como opção, não como arquivo. E o modo seguro padrão do Pillow, traço D SAFER, não impede. Com arroba no começo é pior: o Ghostscript lê argumentos de outro arquivo. Se o atacante também controla esse arquivo, diz o advisory, dá pra escalar pra execução arbitrária de comando.

Quem reportou diz que confirmou isso. Na prática: sua exposição está nos code paths em que o Pillow acaba passando EPS ou PostScript pro Ghostscript. Serviço que só redimensiona foto que ele mesmo nomeou preocupa bem menos que um que abre qualquer coisa, com o nome que chegou. Começa pelo inventário. Busca pillow nos lockfiles, depois um binário do Ghostscript nas imagens de container. Pillow sem Ghostscript espera um pouco.

Pillow com Ghostscript na mesma imagem vai pro topo. Pros do topo, são dois passos. Atualiza o Pillow pra release com o patch, com o número da versão tirado do advisory, nunca de cabeça. Ou, se o serviço nunca precisou de Ghostscript, tira da imagem. Binário que não tá instalado não recebe argumento ruim. E isso protege além desse advisory. Um detalhe muda a triagem. Segundo o advisory, quem dispara a falha é o nome do arquivo: até um EPS inofensivo serve, se o atacante influencia o nome. E diz que a recomendação padrão de bloquear EPS não confiável não cobre isso.

É realista? O advisory cita endpoints de upload que guardam ou derivam o nome salvo do input do usuário. Quem reportou testou no Pillow doze ponto três ponto zero, a versão mais recente na época, e escreveu que o código vulnerável parece afetar todas as versões atuais.

Checagem dois: upload. Pra cada endpoint que recebe imagem de usuário: ele restringe os formatos que abre? Algum pedaço do nome original chega no path do Pillow? Allowlist de formato é defense in depth barata. Gerar o nome no seu código tira ele da mão do atacante. Regra pra triagem: recebe upload de usuário e tem Ghostscript? É urgente até alguém mostrar que formatos abre e de onde vêm os nomes. A regra de Pillow e Ghostscript é pra produção.

Saindo de produção, agora as ferramentas de código do time. Mesma pergunta, outra forma: você sabe exatamente que modelos elas usam, e quem percebe quando um é aposentado? O que mudou: Dezenove de outubro de dois mil e vinte e seis: o GitHub descontinuou seis modelos em quase todo o Copilot. Chat, inline edits, ask, agent e code completions. Saem Gemini três ponto sete Flash, GPT cinco ponto cinco e GPT cinco ponto quatro.

Mais GPT cinco ponto quatro mini, GPT cinco mini e Grok quatro ponto cinco. O GitHub sugere um substituto pra cada. Gemini três ponto sete Flash vira três ponto oito Flash. GPT cinco ponto cinco e cinco ponto quatro vão pro GPT seis ponto um Sol. Os dois mini, GPT cinco ponto quatro mini e GPT cinco mini, vão pro GPT seis Luna. E o Grok quatro ponto cinco vira Grok quatro ponto sete. Pro time de plataforma, essa tabela é só o ponto de partida.

Se alguém escolheu um modelo mini de propósito, por custo ou por velocidade, trata a troca como algo que precisa ser testado antes. Testa rápido em tarefa real antes de virar padrão geral. Não foi surpresa. O GitHub avisou em dezoito de setembro de dois mil e vinte e seis. Mas tem um passo de admin. O GitHub diz que admins do Copilot Enterprise podem ter que liberar os modelos alternativos nas model policies. Liberado, ele aparece no seletor do Copilot Chat, no VS Code e no site do GitHub. E diz que não precisa fazer nada pra remover os descontinuados.

A limpeza é automática; o trabalho é ligar as coisas. Sem liberar os substitutos, o seletor pode mostrar menos opção que antes. E o que faz agora um script com modelo antigo hardcoded? Melhor descobrir na busca que na falha. Checagem pra uma tarde: Procura os seis nomes nos workflows e configs de agente, e nas integrações que chamam o Copilot de fora. Aí um admin confirma que a policy tá ligada pra cada modelo novo que os times vão usar. Um trade-off: Fixar o modelo na config do agente deixa tudo previsível, mas cada descontinuação vira uma edição pra alguém fazer.

Com os nomes num lugar só, a próxima troca é uma mudança só. No mesmo dia, dezenove de outubro, o changelog do GitHub também publicou uma melhoria: a API de política de modelos do Copilot pra enterprises, orgs e times. Gerencia várias orgs? Olha essa API antes da próxima troca. Se encaixar, ligar um modelo vira código revisado, não um clique que alguém precisa lembrar. Fica a regra: Modelo descontinuado? Quem cuida do tooling de IA confere duas coisas em poucos dias. Todo nome fixo foi trocado? O substituto tá ligado pra quem precisa?

Entra na lista dos upgrades de dependência. Depois das mudanças de modelo do Copilot, a gente volta pra segurança. Esse item vem agora porque testa outro hábito: saber se um problema te afeta quando nenhum scanner avisa.

É o CVE dois mil e vinte e seis, dois zero zero quatro três. Pra um time na correria, a única pergunta é: afeta algo que você roda? O que o advisory diz: Tá no GitHub Advisory Database. O crédito vai pro time de engenharia do Snort três, open source da Cisco, por uma ampla revisão interna de segurança. Daí saíram releases de hardening pra várias vulnerabilidades que o time achou internamente. As vulnerabilidades desse CVE envolvem out-of-bounds writes. Ou seja, grava dados além do fim do buffer, ou antes do início.

Na página, o campo de pacote diz: no package listed. E o GitHub diz que esse advisory não tem suporte a Dependabot alerts. Motivo: nenhum pacote de ecossistema suportado com versão afetada e corrigida. Então, afeta algo que você roda? Na prática, é bem pontual. Se o Snort três roda em algum lugar, num sensor de rede ou numa imagem de container, é seu até provarem o contrário.

Ninguém responde isso em minutos? Esse é o primeiro achado. Pro time de plataforma, é checagem manual, e dá pra começar já. Procura Snort pelo nome no SBOM e nos manifests de imagem. Depois pergunta pra quem cuida da segurança de rede qual versão tá rodando. Dependabot quieto aqui não é resultado limpo. Scanner de pacote pode ficar quieto por um motivo parecido. Antes de confiar no seu, confirma se ele chegou a indexar esse advisory. Até lá, relatório vazio indica que ninguém olhou.

Trade-off pequeno. Uma hora de busca manual, mais ou menos, sai barato perto de descobrir depois que um sensor esquecido tava no escopo. Regra de decisão: Advisory sem pacote vai pra alguém com nome e sobrenome, não fica esperando na queue do scanner. Esse dono acha no write-up do vendor a release que corrige, e o upgrade ganha data no ciclo normal. Isso fecha o advisory da Cisco e os itens de segurança. Daqui pra frente é lançamento, não incêndio. Agora Azure Monitor, e a pergunta pra cada lançamento é a mesma: muda o que o time faz, ou só o que ele lê?

O feed Azure updates da Microsoft lista advanced platform metrics do Azure Monitor como lançado, generally available, em vinte de outubro de dois mil e vinte e seis. Na mesma página, a Microsoft define o estágio «lançado». Nas palavras dela: totalmente lançado, pronto pra produção e aberto a todo cliente Azure. O preview também é definido. Todo cliente Azure, só pra teste e fora de produção. Na prática: pronto pra produção é a frase pra cobrar do vendor. Pro time de plataforma, essas métricas podem disparar alerta de plantão. Se no design review perguntarem se é seguro, mostra a definição da própria Microsoft.

O que o rótulo de estágio não resolve é escopo, preço ou regiões. Trata tudo isso como desconhecido até ler o update inteiro e a documentação do Azure Monitor, e deixa o que aprender anotado do lado do alerta que depende disso. Uma regra pra decidir: Antes de um alerta de plantão depender dessas métricas, alguém confirma o nome exato e como é cobrado. Depois, confere se existe em toda região onde vocês rodam.

Não importa em que estágio o time conheceu essas métricas: confere se nome e cobrança ainda batem com os alertas. Já espera que algo não bata. Alerta que nunca disparou não tá provado: dispara uma vez de propósito e vê chegar. É pouco tempo pra evitar uma falha silenciosa. Exemplo inventado. Um time hipotético aponta o alerta de CPU pra um nome de métrica que não bate. Nada dispara, e o silêncio parece que tá tudo bem até a noite em que você precisa dele.

Outra pergunta pro time. Que dashboards e runbooks mudariam com essas métricas no lugar das atuais? Se nenhum, sem pressa. Se vários, migra por etapas, não tudo de uma vez. Conferir umas métricas na doc é rapidinho. Define quem é o dono dessa checagem e põe na agenda, sem esperar o próximo incidente. Métrica do Azure Monitor diz que algo tá errado. Saber o que depende do quê é a parte difícil às três da manhã. Então a pergunta é se o Knowledge Graph da Grafana ajuda nisso, e se muda o plantão.

Na ObservabilityCON dois mil e vinte e seis, a Grafana ampliou o que chama de Knowledge Graph. Ela descreve como a camada de contexto de runtime do Grafana Cloud: uma visão única dos componentes e das relações entre eles, com insights de saúde por cima. São duas frentes. A primeira é cobertura: mais infraestrutura e aplicações, e sinais do lado do usuário. A segunda é contexto operacional: o catálogo de serviços, os times de plantão e as lições de incidentes passados.

A Grafana diz pra quem é. Segundo ela, essas conexões dão a pessoas e agentes de IA o mesmo contexto, e afirma que isso acelera o troubleshooting e a busca da causa raiz. Os estágios variam. A Grafana põe o catálogo de serviços e as lições de incidentes em private preview; o grafo como contexto de runtime pra agentes de IA é generally available. Então, muda o plantão? Na prática: um grafo de contexto só vale o que você põe nele.

Se o service catalog tá desatualizado, um agente pode seguir esse dono desatualizado com toda confiança e mandar quem tá respondendo pro time errado. Antes de ligar investigação por agente, faz uma auditoria rápida. Pega os serviços que mais te acionam e vê se cada um tem um dono definido e uma escala que bate com quem tá de plantão de verdade. Depois abre os runbooks linkados e vê quando alguém mexeu neles pela última vez. Uma regra pro time:

Se falhar mais de um em cada cinco, mais ou menos, arruma o catálogo primeiro e o agente só sugere. Se passarem, o agente rascunha o começo da investigação e toda ação é de um humano. Um exemplo inventado de teste rápido: Pega um alerta recente e pergunta pro grafo quem é dono do serviço que tá falhando. Se for alguém que saiu do time há meses, taí a primeira tarefa. Incidente antigo é pista: confere com os dados atuais antes de agir. Com qualquer ferramenta, anotar o que tentou, descartou e o que resolveu já se paga. Você paga o esforço de setup agora e ganha minutos no começo de cada incidente.

O ritmo sensato é rodar um piloto com o que já tá GA e tratar o que tá em preview como avaliação, com uma saída se os dados vierem mais fracos que o esperado. A dependência silenciosa disso tudo é saber quem é dono. Essa é a lista toda, do PHP ao Knowledge Graph, e o fio que liga tudo é ownership: em cada item, a correção começa quando alguém fica responsável por conferir.

Agora, o número da semana e o que o time deve acompanhar. Número da semana: oito. A Cloudflare diz que oito certificados eMudhra estão comprometidos. Parece pouco. Mas confiança em autoridade certificadora é compartilhada: isso cai em todo time, não só em quem comprou da eMudhra. Confere trust store, pinning e todo client com certificado raiz próprio embutido. A ordem pra resolver não é a do episódio, de propósito.

PHP primeiro, depois Pillow e Ghostscript, certificados, o advisory da Cisco quando alguém assumir ver se se aplica, e por fim o repin de modelos do Copilot. A regra: quanto mais curto o caminho da internet até rodar código alheio, mais cedo vem a correção. No PHP, o projeto diz que as versões oito ponto cinco ponto doze, oito ponto quatro ponto vinte e sete, oito ponto três ponto trinta e seis e oito ponto dois ponto trinta e cinco corrigem duas vulnerabilidades críticas que podem permitir remote code execution sem autenticação.

E diz que não tem mitigação completa: atualizar é a única saída segura. No Pillow, o advisory do GitHub descreve injeção de argumento numa chamada ao Ghostscript, que pode levar a RCE.

O GitHub diz que deprecou vários modelos na maior parte do Copilot. As alternativas sugeridas incluem GPT seis ponto um Sol, GPT seis Luna, Gemini três ponto oito Flash e Grok quatro ponto sete, e admins do Copilot Enterprise podem ter que habilitar pelas políticas de modelo. Pro time de plataforma, é hora de registrar quais modelos valem e quem aprova um novo; aí a próxima aposentadoria vira só um ajuste de config. Fica de olho: Em certificados, pergunta a cada trust store que você usa, navegador, sistema operacional e imagem base de container, como fica com a eMudhra, e anota no inventário.

O PHP diz que o detalhe técnico tá nos advisories linkados. Lê, lista os CVEs e cruza com o que a distro ou o vendor de LTS entregou. Só a versão do pacote não diz. No Copilot, o changelog do GitHub cita uma API de model policy pra enterprise, orgs e times. Vale olhar: política de modelo em código dá pra revisar e fazer rollback como o resto.

Pra levar daqui: Sobe o PHP pra oito ponto cinco ponto doze ou o fix do seu branch, e o Pillow já. Revisa trust store e pinning da eMudhra: oito certificados comprometidos é problema de todo mundo. E troca os modelos aposentados do Copilot pelos sugeridos, com as políticas ligadas. Quatro itens, um fio: a correção começa quando uma pessoa só fica responsável por ver se ela entrou. No próximo episódio, retomamos três temas.

O que vem pro PHP depois das correções. Como os root programs de navegadores e sistemas operacionais veem a eMudhra. E uma primeira olhada em como gerenciar as políticas de modelo do Copilot pela API nova. Quer ouvir quando sair? Segue o programa em theplatformradar ponto com. Valeu pela companhia no carro ou no treino. Até terça.