A vulnerabilidade do PHP e o OpenEMR: o que quem o usa precisa saber e fazer

Se a sua clínica, laboratório ou projeto usa o OpenEMR, há uma tarefa urgente nesta semana: atualizar o PHP. Em 21 de outubro de 2026 o projeto PHP publicou correções de emergência para duas falhas críticas que permitem execução remota de código sem autenticação. O OpenEMR é escrito em PHP, então cada instalação exposta à internet é, por padrão, um alvo.

Neste artigo explicamos o que é a vulnerabilidade, o que é o OpenEMR (e seu derivado AIOTP, a plataforma "All in One" da OPAS) e que ações concretas quem o opera deveria tomar hoje.

O que é a PHP2Shell

PHP2Shell é o nome que a comunidade de segurança deu a duas vulnerabilidades do núcleo do PHP: CVE-2026-109618 e CVE-2026-109619. Ambas têm severidade crítica, 9,2 no CVSS v4.0, e permitem que um atacante sem credenciais execute código no servidor com os privilégios do processo web.

A primeira falha está no tratamento de erros por falta de memória: se o PHP fica sem memória enquanto prepara os dados de uma requisição, esses dados ficam inicializados pela metade e depois são tratados como válidos. A segunda ocorre porque o PHP mantém estado de uma requisição depois de liberar sua memória; se o mesmo processo atende a requisição seguinte, pode ler esse estado obsoleto. Essa segunda via também permite vazar memória, o que pode expor senhas, tokens, chaves de API e certificados.

O que torna este caso especialmente grave:

• Não depende da aplicação. A falha está no interpretador, não no WordPress, no Drupal ou no OpenEMR. Segundo o PHP, toda instalação que atende requisições web está em risco: PHP-FPM, Apache com modphp, php-cgi, FrankenPHP e LiteSpeed. Com modphp o ataque pode acontecer antes que rode uma única linha de código da aplicação.
• Amplo alcance histórico. Afeta do PHP 5.4 até o 8.5.11.
• Vazou antes da correção. Os detalhes circularam em 20 de outubro, antes da divulgação coordenada; o PHP antecipou a publicação para 21 de outubro e nesse mesmo dia surgiram análises técnicas detalhadas.
• Versões sem suporte ficam de fora. O PHP 8.1 e anteriores não receberão correção oficial.

Fontes: Huntress, Google Cloud.

O que é o OpenEMR

O OpenEMR é o prontuário eletrônico (EHR) de código aberto mais conhecido do mundo: uma aplicação web gratuita, escrita em PHP sobre MySQL/MariaDB, que integra prontuário clínico, agenda, faturamento e portal do paciente. Tem mais de duas décadas de desenvolvimento comunitário e é mantido por uma comunidade de voluntários e empresas prestadoras de serviços.

Suas capacidades mais relevantes para quem trabalha com interoperabilidade:

• Certificação ONC nos Estados Unidos (2015 Cures Update). A certificação da versão 7 foi retirada em 27 de fevereiro de 2026; hoje o ramo certificado é o OpenEMR 8.
• API FHIR R4 alinhada ao US Core e SMART on FHIR para autorização de aplicativos de terceiros.
• Módulos clínicos e administrativos: prescrição eletrônica, relatórios de qualidade (eCQM), determinantes sociais da saúde, faturamento X12, telemedicina e portal do paciente.
• Internacionalização: traduzido para dezenas de idiomas, incluindo o espanhol e o português, e usado em clínicas de muitos países.

Na América Latina tem também respaldo institucional: o BID o inclui em seu catálogo de soluções de código aberto e ele é um bem público digital reconhecido pela Digital Public Goods Alliance. Por isso é uma opção frequente em clínicas privadas, ONGs, projetos acadêmicos e pilotos de saúde digital na região.

Essa mesma popularidade é o que o torna um alvo atraente: um prontuário eletrônico concentra dados de saúde, identificação e faturamento, justamente o que mais vale para um atacante.

Por que o OpenEMR está diretamente exposto

O OpenEMR usa sessões PHP e permite o envio de arquivos (documentos clínicos, imagens, consentimentos). Segundo o aviso oficial do OpenEMR de 21 de outubro, qualquer site com sessões ou envio de arquivos habilitados, ambos ativos por padrão, é explorável. O mesmo aviso indica que a vulnerabilidade já está sendo explorada e que existe código público de prova de conceito.

Este vídeo mostra, em 42 segundos e sem áudio, como é o ataque contra um prontuário eletrônico em PHP exposto à internet: o atacante detecta uma versão vulnerável, envia uma requisição manipulada e obtém uma shell sem usuário nem senha. É uma animação ilustrativa e conceitual; não contém um exploit real. O texto na tela está em espanhol.

Você também pode vê-lo em sua própria página: PHP2Shell: como funciona o ataque.

Quantas instalações estão à vista

Uma consulta ao Shodan, o buscador de dispositivos conectados à internet, encontrou em 21 de outubro de 2026 1.386 servidores com OpenEMR visíveis na internet, em 46 países. 62 % estão nos Estados Unidos, e a maioria roda em nuvens públicas. O Censys, outro buscador do mesmo tipo, contou 487 nesse dia buscando pelo título da página, com a mesma tendência: 70 % nos Estados Unidos. Os números não se somam, porque cada buscador indexa de forma diferente.

A mesma busca retornou 405 iscas (honeypots) que imitam a página do OpenEMR. São armadilhas que pesquisadores e equipes de segurança costumam montar para observar os atacantes, e o seu número mostra que o OpenEMR já está sob vigilância ativa. Na China, além disso, quase todos os resultados não marcados como isca seguem o mesmo padrão: páginas de instalação em nuvens públicas e em portas aleatórias. O Censys encontra só 13 servidores na China.

Na América Latina e no Caribe aparecem apenas 28 servidores no Shodan e 8 no Censys, mas isso diz pouco sobre o risco real:

O ponto delicado são as imagens Docker oficiais, que é como a maioria das instalações é implantada hoje. A correção depende da versão do Alpine Linux sobre a qual cada imagem foi construída:

Três detalhes que podem surpreender uma equipe de operações:

• Baixar a imagem mais recente não basta. A imagem 8.4.x publicada foi construída antes da correção, então um docker pull continua entregando PHP vulnerável.
• A correção aplicada dentro do contêiner é frágil. Ela fica na camada gravável: um docker compose down ou up --force-recreate a desfaz. É preciso usar restart.
• A cadeia de construção do projeto estava parada por uma queda de um repositório do Ubuntu/Launchpad, então as imagens reconstruídas podem demorar.

As instalações fora do Docker (pacotes do sistema operacional, XAMPP no Windows, servidores compartilhados) dependem do ritmo de sua distribuição ou provedor de hospedagem. As que ainda rodam PHP 7.x ou 8.1 estão na pior posição, porque não haverá correção oficial.

AIOTP: a plataforma "All in One" da OPAS baseada no OpenEMR

O risco não termina no repositório oficial. Na organização ciips-code do GitHub está a All In One Telehealth Platform (AIOTP), uma suíte de telessaúde de código aberto encomendada pela Organização Pan-Americana da Saúde (OPAS/OMS) ao CIIPS do Instituto de Efectividad Clínica y Sanitaria (IECS), dentro da iniciativa IS4H. Seu objetivo é melhorar o acesso à atenção em populações remotas da América Latina e do Caribe, e foi proposta sua evolução para interoperabilidade com OpenHIE, HL7 FHIR e CDS Hooks.

O AIOTP tem dois módulos principais, e ambos rodam sobre PHP:

Isso o coloca na situação mais delicada de todas:

• Todos os ramos do PHP envolvidos estão sem suporte. O PHP 7.4 e o 8.1 não receberão correção oficial da PHP2Shell; há apenas backports mínimos de código-fonte ou os que cada distribuição oferecer.
• A imagem 7.0.0 não está coberta pelo aviso do OpenEMR, que só dá instruções para as imagens 8.0 a 8.4. Além disso, a certificação ONC do OpenEMR 7 foi retirada em fevereiro de 2026.
• Pouca atividade recente. A última mudança de código no pacote OpenEMR do AIOTP é de dezembro de 2024 e a do módulo de teleconsulta, de outubro de 2023, então não se deve esperar uma correção imediata do projeto.
• É um bem público regional. Justamente por vir da OPAS, pode estar implantado em ministérios, programas de doenças crônicas ou pilotos de telessaúde, às vezes por equipes que não sabem que por baixo roda o OpenEMR.

Se você opera o AIOTP ou uma instalação derivada, trate-a como uma instalação sem correção: tire-a da internet ou coloque-a atrás de VPN, desative session.upload_progress.enabled no php.ini dos dois módulos, procure sinais de comprometimento e planeje a migração para um ramo suportado do OpenEMR 8 e do PHP. O mesmo vale para qualquer outro derivado do OpenEMR: identifique a imagem base e a versão exata do PHP no Dockerfile ou instalador antes de dar o problema por resolvido.

O que fazer se usa o OpenEMR ou um derivado

A única correção completa é atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35; tanto o PHP quanto o OpenEMR dizem isso explicitamente. Todo o resto é contenção enquanto a correção não chega.

Nas próximas horas

1. Inventariar. Identifique cada servidor, contêiner ou máquina onde roda o OpenEMR ou um derivado, incluindo ambientes de teste, demonstrações e equipamentos de treinamento. Para cada um, anote a versão do OpenEMR e execute php -v.
2. Tirar o OpenEMR da internet. Um prontuário eletrônico com dados de pacientes não deveria estar exposto diretamente. Restrinja o acesso a redes confiáveis ou VPN; se não puder, considere desligá-lo até ter a correção.
3. Corrigir conforme o seu caso.

- Imagem oficial 8.4.x: atualize os pacotes php85 dentro do contêiner e reinicie-o com docker compose restart, não com down/up. Confirme com php -v que aparece 8.5.12 ou superior.
- Imagens 8.2.x ou 8.3.x: aguarde o backport do Alpine 3.23 ou migre para a 8.4.x e aplique o mesmo procedimento.
- Imagem 8.0.x: não receberá correção dentro do contêiner; migre para a 8.4.x ou compile o PHP 8.4.27.
- Instalações sem Docker: aplique os pacotes da sua distribuição ou do seu provedor de hospedagem.

1. Se está preso ao PHP 8.1 ou anterior, desative session.upload_progress.enabled no php.ini e reinicie o serviço web. Isso reduz os vetores conhecidos, mas não substitui a atualização.

Nos próximos dias

• Buscar sinais de comprometimento. Verifique se o processo do PHP ou do Apache iniciou shells (sh, bash), interpretadores ou ferramentas como curl ou wget. Procure novos arquivos PHP no diretório web, tarefas cron ou contas desconhecidas.
• Trocar segredos. Como uma das falhas permite vazar memória, troque senhas de banco de dados, chaves de API, segredos de clientes OAuth/SMART e certificados dos servidores que estiveram expostos.
• Preservar evidências. Se encontrar algo suspeito, isole o servidor e guarde os logs do servidor web e do PHP antes de reinstalar.
• Avaliar a obrigação de notificar. O comprometimento de um prontuário eletrônico é um incidente com dados sensíveis. Na Costa Rica, a Lei 8968 de proteção de dados pessoais obriga a avaliar a notificação à PRODHAB e aos titulares afetados; em outros países, como o Brasil com a LGPD, valem normas equivalentes.

De forma permanente

• Manter-se em versões suportadas do OpenEMR, do PHP e do sistema operacional base. O OpenEMR 8.4.1 é a versão estável atual.
• Reconstruir imagens, não corrigi-las à mão. Quando as imagens oficiais corrigidas forem publicadas, migre para elas para que a correção não dependa da camada gravável do contêiner.
• Colocar camadas na frente: proxy reverso, WAF e limites de tamanho de requisição e de memória no contêiner.
• Inscrever-se nos avisos do fórum do OpenEMR e do projeto PHP, e designar uma pessoa responsável por acompanhá-los.

O que a PHP2Shell nos deixa

O código aberto não é o problema: o OpenEMR publicou um aviso detalhado no mesmo dia da divulgação, algo que muitos fornecedores proprietários não fazem. O problema é operar um sistema clínico sem um responsável de segurança atento à pilha completa: aplicação, linguagem, imagem base e sistema operacional.

Do ponto de vista da interoperabilidade há uma lição adicional. Um prontuário que expõe uma API FHIR e conexões SMART on FHIR é uma porta de entrada para todo um ecossistema de intercâmbio. Sua segurança já não é só um assunto da clínica, mas de cada sistema com o qual compartilha dados.

Na Meddyg apoiamos instituições de saúde na avaliação de suas implantações, na gestão de vulnerabilidades e na integração segura com padrões como o HL7 FHIR. Se precisar de apoio para revisar sua instalação do OpenEMR ou de um derivado, fale conosco.

Fontes

• OpenEMR: aviso php2shell
• PHP: aviso de segurança CVE-2026-109618
• PHP: aviso de segurança CVE-2026-109619
• Huntress: Rapid Response php2shell
• Google Cloud: resposta às vulnerabilidades do PHP
• Shodan: servidores com OpenEMR visíveis na internet, sem honeypots, consulta de 21 de outubro de 2026
• Censys: servidores com OpenEMR por título da página, consulta de 21 de outubro de 2026
• OpenEMR: funcionalidades
• BID: OpenEMR no catálogo de soluções de código aberto
• AIOTP: All In One Telehealth Platform
• AIOTP: pacote OpenEMR (openemr-telesalud)