ALERTA DE SEGURANÇA: vulnerabilidades críticas no PHP exigem atenção imediata das instituições que utilizam o AtoM (Access to Memory)

Orientações para a comunidade arquivística brasileira e latino-americana sobre segurança, continuidade de acesso, preservação digital e proteção dos documentos arquivísticos.

Por Daniel Flores
Professor e pesquisador — Programa de Pós-Graduação em Ciência da Informação (PPGCI), Universidade Federal de Alagoas (UFAL).
Grupo de Pesquisa CNPq PDS & Ged/A — Documentos Digitais: Transformação Digital da Gestão Documental, Curadoria, Preservação, Acesso e Transparência Ativa em Cadeia de Custódia Digital Arquivística.

Data de publicação: 23 de outubro de 2026

1. Contextualização: um alerta que exige atenção de toda a comunidade AtoM

A comunidade internacional de usuários do AtoM (Access to Memory) está diante de uma situação importante de segurança cibernética que requer atenção imediata dos responsáveis pela administração, hospedagem e manutenção dessas plataformas.

Em 21 de outubro de 2026, o projeto PHP publicou um alerta sobre duas vulnerabilidades críticas que podem permitir a execução remota de código por um atacante não autenticado. As falhas foram identificadas como CVE-2026-109618 e CVE-2026-109619. Como o AtoM é uma aplicação web desenvolvida em PHP, essas vulnerabilidades exigem uma avaliação imediata dos ambientes em que o sistema está instalado.

A gravidade do cenário levou a Artefactual Systems Inc., empresa responsável pelo desenvolvimento e pela manutenção do AtoM, a comunicar à comunidade, por meio da lista de discussão AtoM Users, que desligaria preventivamente todos os sites AtoM hospedados por ela enquanto a situação evoluísse.

Em mensagem enviada à comunidade, Katie Punia, responsável pela área de Segurança da Informação e Infraestrutura da Artefactual, informou que a empresa estava adotando essa medida preventiva e observou que outras organizações também estavam optando por desligar seus sites.

É fundamental interpretar corretamente essa comunicação: a decisão de retirar os sites do ar não significa, por si só, que todos eles tenham sido invadidos. Trata-se de uma medida preventiva diante de um risco grave, enquanto são avaliadas as condições de segurança e as providências necessárias.

O comunicado original pode ser consultado na discussão do grupo AtoM Users no Google Groups.

Este artigo tem como objetivo informar a comunidade arquivística brasileira e latino-americana, apresentar as implicações técnicas do alerta e recomendar medidas para instituições que mantêm instalações AtoM próprias ou contratadas.

2. Quais são as vulnerabilidades identificadas?

O comunicado oficial do PHP, publicado em 21 de outubro, descreve duas falhas críticas no interpretador da linguagem.

CVE-2026-109618 — corrupção de memória associada a falta de memória

A vulnerabilidade está relacionada ao tratamento de situações de falta de memória (out-of-memory, ou OOM). Em determinadas circunstâncias, estruturas internas de uma requisição podem ficar parcialmente inicializadas, levando o PHP a tratá-las de maneira incorreta durante a limpeza dos recursos utilizados.

Esse comportamento pode abrir caminho para a execução de código no servidor.

CVE-2026-109619 — uso de estado interno obsoleto

A segunda vulnerabilidade envolve o gerenciamento de estados internos entre requisições. Determinados dados pertencentes a uma requisição podem permanecer referenciados depois que a memória correspondente foi liberada.

Em determinadas condições, uma requisição posterior, processada pelo mesmo trabalhador, pode utilizar esse estado indevidamente, antes que a inicialização normal restabeleça as estruturas necessárias.

Essa falha também pode permitir execução remota de código.

Ambas as vulnerabilidades foram classificadas como críticas, com pontuação CVSS 4.0 de 9,2, conforme o comunicado de segurança do projeto PHP.

A questão essencial é que o problema está no próprio interpretador PHP, componente responsável pela execução do código da aplicação. Portanto, não se trata necessariamente de uma falha exclusiva do AtoM, nem de uma evidência de que o código da aplicação tenha sido invadido.

Uma instalação AtoM pode estar exposta mesmo que não apresente erros visíveis, tenha suas configurações aparentemente corretas e esteja funcionando normalmente.

Fontes oficiais:

• PHP — arquivo de avisos de segurança de 2026

• CVE-2026-109618 — registro da vulnerabilidade

• CVE-2026-109619 — registro da vulnerabilidade

3. Quais versões do PHP receberam as correções?

O projeto PHP publicou versões corretivas para as seguintes linhas:

Linha do PHP	Versão com as correções
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Essas são as versões oficiais anunciadas em 21 de outubro para corrigir as duas vulnerabilidades principais.

O projeto também informa que usuários de distribuições Linux e fornecedores de versões de suporte prolongado devem verificar a disponibilidade dos pacotes corrigidos fornecidos por seus respectivos fornecedores. Algumas distribuições aplicam correções retroportadas (backports), sem necessariamente utilizar a mesma numeração das versões oficiais do PHP.

Por isso, não basta verificar se o servidor utiliza PHP 8. É necessário identificar a versão efetivamente instalada, o pacote utilizado e a existência de uma correção de segurança reconhecida pelo fornecedor.

Instalações que utilizam versões antigas do PHP precisam de atenção especial. O PHP 8.1 e versões anteriores já não recebem atualizações regulares do projeto principal, embora determinados fornecedores possam oferecer correções retroportadas.

Atenção à compatibilidade: não recomendamos atualizar indiscriminadamente uma instalação AtoM para qualquer versão recente do PHP sem verificar os requisitos da versão do AtoM utilizada e a compatibilidade das dependências. A correção deve ser aplicada de maneira controlada, preservando a estabilidade e a segurança da aplicação.

Consulte a documentação oficial:

• PHP — versões e avisos de segurança

• PHP — downloads oficiais

• Repositório oficial do AtoM

4. O problema afeta somente servidores Apache com mod_php?

Não.

O alerta do PHP abrange instalações que processam requisições web, incluindo ambientes que utilizam:

• Apache com mod_php;

• PHP-FPM;

• php-cgi;

• FrankenPHP;

• LiteSpeed.

O comunicado identifica risco particularmente elevado em ambientes com mod_php, nos quais foi demonstrada a possibilidade de exploração por meio de uma requisição não autenticada antes mesmo da execução do código da aplicação.

Isso não significa que outras configurações estejam automaticamente protegidas.

A utilização de Nginx, PHP-FPM, contêineres ou outras formas de implantação não elimina, por si só, a vulnerabilidade. A arquitetura, as permissões e as medidas de isolamento podem reduzir determinados riscos, mas não substituem a aplicação das correções recomendadas.

5. Atualização de 23 de outubro: orientação adicional sobre sessões PHP

Em 23 de outubro, o projeto PHP publicou um aviso informativo complementar relacionado ao recurso de progresso de upload de sessões, identificado como CVE-2026-115560.

A recomendação é manter session.upload_progress.enabled=0 até a próxima versão corretiva, caso essa mitigação ainda não tenha sido aplicada.

O projeto esclarece que o problema depende de uma combinação incomum de configurações e código da aplicação: alteração do mecanismo de serialização de sessões durante a execução, antes do início de uma sessão, com o recurso de progresso de upload ainda habilitado.

Portanto, não se deve concluir que toda instalação AtoM esteja vulnerável a esse caminho específico. A equipe técnica precisa verificar a configuração efetiva do ambiente e aplicar a recomendação do PHP quando pertinente.

Esse aviso complementar não substitui a atualização necessária para corrigir as duas vulnerabilidades críticas divulgadas em 21 de outubro.

Fonte: PHP — arquivo oficial de avisos de segurança de 2026.

6. O que isso significa para as instituições que utilizam AtoM?

O AtoM é amplamente utilizado por arquivos públicos, instituições de memória, universidades, órgãos governamentais e outras organizações para descrição arquivística, difusão e acesso a documentos.

Como toda aplicação web exposta à Internet, uma instalação AtoM depende da segurança de seus componentes: sistema operacional, servidor web, interpretador PHP, banco de dados, mecanismos de indexação, dependências e configurações de acesso.

A exploração bem-sucedida de uma vulnerabilidade no PHP pode permitir que um atacante execute código com os privilégios do processo comprometido. Dependendo da configuração do servidor, isso pode abrir caminho para:

• alteração de arquivos da aplicação;

• acesso a arquivos de configuração e credenciais;

• tentativas de acesso ao banco de dados;

• alteração ou exclusão de registros descritivos;

• adulteração de arquivos digitais armazenados no ambiente;

• criação de mecanismos de persistência;

• utilização do servidor como ponto de partida para outras ações maliciosas.

Esses são impactos possíveis, e não a confirmação de que todas as instalações estejam comprometidas.

É necessário distinguir três situações:

1. Aplicação vulnerável: o servidor ainda não recebeu a correção necessária. Há risco, mas isso não comprova uma invasão.

2. Aplicação corrigida: o PHP recebeu a atualização apropriada, os serviços foram reiniciados quando necessário e a equipe confirmou que a versão corrigida está efetivamente em execução.

3. Aplicação possivelmente comprometida: existem indícios de atividade suspeita, alterações não autorizadas ou outros sinais de invasão. Nesse caso, a atualização do PHP é necessária, mas não basta para garantir que o ambiente esteja limpo.

A terceira situação exige investigação específica, preservação de evidências e um plano de recuperação.

7. Recomendações imediatas aos administradores de AtoM

Recomendamos que as instituições realizem as seguintes ações, com prioridade para os servidores acessíveis pela Internet.

7.1. Identificar a versão e o modo de execução do PHP

O administrador deve confirmar a versão utilizada pelo AtoM e identificar se o ambiente utiliza PHP-FPM, mod_php ou outra configuração.

Em servidores Ubuntu, os comandos abaixo podem ajudar na verificação inicial:

php -v
php --ini
php --modules

Para identificar serviços PHP-FPM ativos:

systemctl --type=service --state=running | grep -E 'php.*fpm'

E para consultar os pacotes PHP instalados:

dpkg-query -W 'php*' 2>/dev/null

Esses comandos são apenas uma verificação inicial. A versão utilizada pela linha de comando pode ser diferente daquela empregada pelo servidor web. A equipe técnica deve verificar o serviço que efetivamente atende às requisições.

7.2. Aplicar a atualização de segurança

A atualização deve ser realizada conforme a versão compatível com o AtoM e os pacotes disponibilizados pelo fornecedor do sistema operacional.

Após a aplicação da correção, é necessário confirmar que os processos PHP em execução passaram a utilizar a versão corrigida.

Não se recomenda realizar atualizações indiscriminadas em produção sem backup, avaliação de compatibilidade e planejamento de recuperação.

7.3. Restringir temporariamente o acesso quando não for possível corrigir

O CTIR.Gov, do Gabinete de Segurança Institucional da Presidência da República, publicou a Recomendação Técnica 19/2026 sobre as vulnerabilidades críticas do PHP.

O órgão recomenda priorizar a aplicação das atualizações e avaliar o isolamento temporário das aplicações expostas à Internet quando não for possível corrigir imediatamente o ambiente.

Assim, caso a instituição não consiga aplicar a correção com a urgência necessária, deve avaliar o bloqueio temporário do acesso público, mantendo apenas os acessos administrativos estritamente necessários e controlados.

Fonte: CTIR.Gov — Recomendação 19/2026.

7.4. Verificar sinais de comprometimento

A aplicação das atualizações não elimina necessariamente os efeitos de uma eventual invasão anterior.

Recomendamos verificar:

• logs do servidor web e do PHP;

• acessos administrativos não reconhecidos;

• alterações recentes e não autorizadas em arquivos;

• arquivos executáveis inesperados em diretórios de upload;

• modificações de configurações;

• atividade incomum no banco de dados;

• tarefas agendadas e mecanismos de persistência desconhecidos;

• alterações nos documentos digitais e nos registros descritivos.

Diante de indícios de comprometimento, a equipe deve preservar evidências antes de reinstalar, limpar ou reconstruir o ambiente. A investigação deve ser conduzida por profissionais habilitados.

7.5. Proteger backups e verificar a integridade dos documentos

A instituição deve confirmar que possui cópias de segurança independentes, protegidas contra alterações indevidas e adequadas para uma recuperação confiável.

Sempre que existirem manifestos de fixidez ou registros anteriores confiáveis, é recomendável comparar os valores atuais dos objetos digitais com os valores previamente registrados.

Também é importante verificar se as cópias de segurança podem ser restauradas e se o processo de recuperação está documentado.

Um backup não substitui a atualização do PHP, assim como a atualização não substitui os backups.

8. A arquitetura AtoM Double Sites pode oferecer uma camada adicional de proteção?

Algumas instituições adotam uma arquitetura com duas instalações AtoM: uma interna, restrita à rede institucional, e outra pública, destinada à difusão dos registros e documentos autorizados.

Quando corretamente implementado, esse modelo pode reduzir a exposição do ambiente interno e limitar os impactos de um comprometimento do servidor público.

Entretanto, é importante compreender que essa arquitetura não corrige a vulnerabilidade do PHP. O AtoM público continua precisando da atualização de segurança.

Para que a separação seja efetiva, recomendamos verificar:

1. Se o servidor interno não aceita conexões diretas provenientes da Internet.

2. Se o servidor público não pode iniciar conexões administrativas ou executar comandos no ambiente interno.

3. Se a sincronização ocorre de maneira controlada, com autenticação e privilégios mínimos.

4. Se alterações realizadas no ambiente público não são propagadas automaticamente para o ambiente interno.

5. Se exclusões ou adulterações não podem ser replicadas para a cópia de referência.

6. Se as credenciais utilizadas pela sincronização estão protegidas e não concedem privilégios desnecessários.

7. Se existem backups independentes e mecanismos próprios de verificação da integridade dos documentos.

É fundamental analisar a implementação concreta do script de sincronização utilizado pela instituição antes de afirmar que ele oferece proteção suficiente.

A existência de dois servidores, isoladamente, não garante segurança. Se ambos compartilham banco de dados, armazenamento ou credenciais privilegiadas, ou se o processo de sincronização permite retorno de alterações, parte significativa da proteção esperada pode desaparecer.

Recomendamos, portanto, manter a arquitetura de separação quando ela fizer parte da estratégia institucional, mas combiná-la com atualização do PHP, segmentação de rede, controles de acesso, auditoria e backups independentes.

9. Segurança do AtoM e Preservação Digital Sistêmica

Para a comunidade arquivística, o incidente também deve ser analisado sob a perspectiva da Preservação Digital Sistêmica e da Cadeia de Custódia Digital Arquivística (CCDA).

A segurança de uma plataforma de acesso não pode ser confundida com a garantia de autenticidade e integridade dos documentos arquivísticos.

O AtoM é uma aplicação voltada à descrição e ao acesso. Sua utilização não significa, por si só, que os objetos digitais estejam preservados em um ambiente independente, com controles adequados de integridade, autenticidade, armazenamento e auditoria.

Uma instituição que utiliza AtoM integrado a um ambiente de preservação digital, como o Archivematica e um Repositório Arquivístico Digital Confiável (RDC-Arq), deve verificar os componentes de maneira individual e integrada, sem presumir que um incidente no AtoM tenha necessariamente comprometido o repositório — ou que o repositório esteja automaticamente protegido.

Recomendamos que as instituições:

• mantenham cópias independentes dos documentos digitais;

• verifiquem periodicamente a fixidez dos objetos;

• preservem os registros de auditoria e os eventos de preservação;

• mantenham controles de acesso e segregação de privilégios;

• documentem intervenções técnicas e incidentes;

• validem a integridade das cópias antes de restaurar os serviços;

• assegurem que o ambiente público possa ser reconstruído a partir de fontes confiáveis.

No contexto da CCDA, a resposta a um incidente deve preservar a rastreabilidade das ações, a documentação das intervenções e a possibilidade de demonstrar o que foi verificado, corrigido ou recuperado.

A indisponibilidade temporária de uma plataforma de acesso é um problema relevante, mas a alteração não detectada de documentos ou de seus metadados pode ter consequências ainda mais graves para a confiança arquivística.

10. Como acompanhar as atualizações oficiais

Recomendamos que administradores e responsáveis institucionais acompanhem diretamente as seguintes fontes:

Projeto PHP

• Arquivo oficial de avisos de segurança de 2026

• Downloads oficiais do PHP

Artefactual e AtoM

• Repositório oficial do AtoM no GitHub

• Releases do AtoM

• Pull requests do AtoM

• Política de segurança do AtoM

Brasil

• CTIR.Gov — Recomendação Técnica 19/2026

Comunidade internacional

• Grupo AtoM Users no Google Groups

A ausência de uma nova versão do AtoM não significa que a vulnerabilidade do PHP tenha sido corrigida. São componentes distintos, com processos de atualização próprios.

Também não se deve interpretar a ausência de um pull request público como prova de que a equipe responsável não esteja trabalhando em medidas internas ou em orientações adicionais.

Até a data de publicação deste artigo, o alerta confirmado refere-se às vulnerabilidades do PHP e às recomendações de atualização e contenção correspondentes. As instituições devem consultar as fontes oficiais para identificar novas orientações, correções e eventuais recomendações específicas para suas instalações.

11. Checklist de ação para as instituições

Recomendamos que cada instituição responsável por uma instalação AtoM verifique os seguintes itens:

• Identificar todas as instalações AtoM mantidas pela instituição.

• Identificar a versão do PHP e o modo de execução de cada instalação.

• Confirmar a disponibilidade e a aplicação das correções de segurança.

• Verificar a configuração relacionada a session.upload_progress.enabled, conforme o aviso adicional de 23 de outubro.

• Avaliar o isolamento temporário dos serviços públicos que não puderem ser corrigidos prontamente.

• Examinar logs e sinais de atividade suspeita.

• Confirmar a existência de backups independentes e restauráveis.

• Verificar a integridade dos documentos digitais e dos metadados.

• Avaliar os riscos das rotinas de sincronização entre ambientes internos e públicos.

• Registrar as providências adotadas e os resultados das verificações.

• Acompanhar os comunicados oficiais do PHP, da Artefactual e da comunidade AtoM Users.

Considerações finais

O alerta de segurança de outubro de 2026 reforça uma questão fundamental: a segurança das plataformas de acesso aos documentos arquivísticos depende da manutenção contínua de todos os componentes tecnológicos que as sustentam.

As instituições que utilizam AtoM devem agir com urgência, mas também com método. É necessário distinguir vulnerabilidade de comprometimento confirmado, aplicar as correções apropriadas, investigar eventuais incidentes e preservar a integridade dos documentos.

A adoção de ambientes internos e públicos separados pode constituir uma camada importante de proteção, desde que acompanhada de controles efetivos de rede, sincronização, acesso e armazenamento. Da mesma forma, a existência de um repositório de preservação independente deve ser acompanhada de procedimentos verificáveis de integridade, auditoria e recuperação.

A prioridade não é apenas manter o AtoM disponível, mas assegurar que a difusão dos documentos arquivísticos ocorra sem comprometer sua integridade, autenticidade, confiabilidade e preservação a longo prazo.

Convidamos a comunidade arquivística brasileira e latino-americana a acompanhar os avisos oficiais, compartilhar experiências técnicas verificáveis e adotar medidas coordenadas de segurança.

Este artigo tem caráter informativo e preventivo. Não substitui a avaliação técnica da infraestrutura de cada instituição. As recomendações devem ser aplicadas considerando a versão do AtoM, o sistema operacional, os pacotes disponíveis e os requisitos de compatibilidade do ambiente.

Daniel Flores
PPGCI — Universidade Federal de Alagoas (UFAL)
Grupo de Pesquisa CNPq PDS & Ged/A — Documentos Digitais, Preservação Digital Sistêmica e Cadeia de Custódia Digital Arquivística.

Última revisão: 23 de outubro de 2026.