Animação sem áudio, de 42 segundos, ilustrativa e conceitual: não contém um exploit real. O texto na tela está em espanhol.

  1. O cenário. À esquerda, um prontuário eletrônico em PHP exposto à internet; à direita, a máquina do atacante.
  2. Reconhecimento. O atacante aponta para o servidor sem precisar de credenciais, e o servidor revela que roda PHP 8.1, uma versão vulnerável e sem correção oficial.
  3. A requisição. O atacante envia uma requisição HTTP manipulada: um formulário multipart com "upload progress".
  4. O que acontece dentro do PHP. A requisição esgota a memória do processo do PHP, um dado fica inicializado pela metade, a limpeza o trata como válido e o atacante controla esse dado para executar código. A falha está no PHP, não na aplicação: dispara antes que rode uma única linha do prontuário.
  5. Servidor comprometido. O atacante obtém uma shell com os privilégios do processo web, sem usuário nem senha. A partir daí pode ler tudo o que o prontuário pode: o banco de dados de pacientes, as credenciais, as chaves de API e os dados clínicos, ou instalar um webshell.
  6. A correção. Com o PHP atualizado para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, a requisição já não corrompe a memória e o ataque falha. Se ainda usa PHP 7.x ou 8.1, tire-o da internet e planeje migrar: não haverá correção oficial.
  7. Revise sua instalação hoje. Inventariar cada servidor com OpenEMR, AIOTP ou PHP; corrigir o PHP ou isolar o que não tiver correção; trocar segredos e buscar sinais de comprometimento.

O servidor, o domínio e os dados são fictícios.