PaperCut sofre ataques ativos — até o primeiro patch precisa ser trocado
Em 29 de agosto de 2026, a orientação vigente para PaperCut NG e MF era substituir a primeira correção pelo Emergency Patch Release 2. O boletim de segurança da PaperCut registra incidentes confirmados, informa que a exploração está ativa e recomenda o Release 2 até para instalações que já receberam o patch original.
A resposta direta para administradores é: todas as versões de PaperCut NG e MF estão potencialmente afetadas. Há pacotes do Release 2 para as linhas 24, 25 e 26; versões 23 ou anteriores devem migrar para uma versão atual. Se o Application Server puder ser alcançado pela internet, o acesso web precisa ser limitado imediatamente a IPs internos ou explicitamente confiáveis.
Qual caminho seguir em cada ambiente
A prioridade depende da versão instalada, da exposição das interfaces web e da existência de sinais de comprometimento. Atualização, contenção e resposta a incidentes resolvem problemas diferentes e podem ser necessárias ao mesmo tempo.
- NG ou MF 24, 25 ou 26, sem indícios de invasão: instalar o Emergency Patch Release 2 correspondente ao produto e ao sistema operacional. Isso também vale para quem aplicou a primeira correção.
- NG ou MF 23 ou anterior: atualizar para uma versão atual e então aplicar a correção vigente. O caminho recomendado não é esperar por um pacote emergencial para essas linhas antigas.
- Application Server acessível pela internet: restringir as interfaces web a IPs internos ou confiáveis por firewall, controle de acesso de rede ou medida equivalente, mesmo sem atividade suspeita observada.
- Suspeita de comprometimento: proteger os backups existentes, acionar o processo de resposta a incidentes, apagar e reconstruir integralmente o Application Server e restaurar um backup limpo anterior ao primeiro comportamento suspeito.
O bloqueio de endereços não confiáveis não substitui o patch, mas reduz a exposição enquanto a atualização e a investigação são conduzidas. Da mesma forma, instalar o Release 2 corrige as falhas conhecidas, mas não elimina uma intrusão que possa ter ocorrido antes.
Release 2 corrige duas vulnerabilidades exploradas
O alerta do Centro Canadense, publicado em 28 de agosto, relaciona a exploração aos códigos CVE-2026-81578 e CVE-2026-82078 e considera vulneráveis as edições NG e MF anteriores ao Release 2 das linhas 24, 25 e 26.
A CVE-2026-81578 é uma falha de controle de acesso na interface de gerenciamento web. Em condições específicas, uma solicitação remota sem autenticação pode acionar funções administrativas antes da conclusão das verificações de acesso e alterar determinadas configurações.
A CVE-2026-82078 está nos utilitários de conexão com bancos de dados. O software pode carregar classes de drivers definidas na configuração sem validá-las em uma lista de componentes permitidos. Se um invasor conseguir manipular esses parâmetros, poderá executar bytecode Java presente no classpath sob o contexto de segurança do processo do servidor.
O risco operacional não se limita, portanto, à mudança indevida de uma opção administrativa: a manipulação da configuração pode abrir caminho para execução de código no servidor. O Release 2 acrescenta proteção além da correção emergencial original, razão pela qual o primeiro pacote deixou de ser a opção recomendada.
Conter o servidor não encerra a investigação
O aviso do NHS England, de 28 de agosto, registra exploração ativa das duas vulnerabilidades, recomenda o Release 2 e avalia como altamente provável a continuidade dos ataques. Quando a instalação imediata não for possível, o órgão orienta remover a exposição pública ou limitar as interfaces do Application Server a IPs confiáveis.
Depois da contenção, a análise pode procurar alertas de sistemas de detecção de intrusão, proteção de endpoints ou monitoramento de rede relacionados ao Application Server. Atividade pós-exploração suspeita originada pelo processo pc-app.exe, arquivos server.log ausentes, apagados ou truncados e erros incomuns de driver ou consulta de Card/ID estão entre os indicadores divulgados.
A ausência desses sinais não comprova que o ambiente permaneceu íntegro. Os indicadores públicos ainda são limitados; conexões anormais, processos inesperados ou alterações não autorizadas devem ser avaliados no contexto de cada instalação. Havendo suspeita consistente, reconstruir o servidor a partir de um backup limpo é uma medida de resposta ao incidente, não uma etapa opcional do patch.
Site Servers e integrações exigem atenção após o patch
A atualização não termina no Application Server principal. Site Servers e servidores secundários ou de impressão devem ser levados a uma versão corrigida. Print Deploy e Mobility Print usam componentes não afetados por essas vulnerabilidades e não precisam ser atualizados por causa deste incidente; a orientação de bloquear interfaces públicas também não se aplica às portas do Mobility Print.
Ambientes que consultam números de cartão ou identificação em um banco de dados externo têm uma verificação adicional. Essa função, pouco utilizada, fica desabilitada por padrão após a correção e deve ser habilitada explicitamente com a propriedade security.card-number-lookup.enabled=Y no arquivo server/security.properties antes da reinicialização do Application Server. A interface administrativa pode continuar exibindo a integração como configurada enquanto as consultas externas são ignoradas.
Também houve relatos de problemas com consultas externas de Card/ID e com SAML após a instalação. Para consultas em SQL Server que ainda utilizam o driver jTDS legado, a recomendação é migrar primeiro para uma versão compatível do Microsoft SQL JDBC; essa troca pode não resolver todos os casos e não substitui o Release 2.
O pacote continua emergencial
Na atualização de 30 de agosto, o Release 2 ainda não era uma versão regular: o pacote não havia passado pelo processo habitual de lançamento da PaperCut. A engenharia continuava trabalhando em uma versão oficial, enquanto a correção emergencial permanecia como proteção disponível para os ramos 24, 25 e 26.
A investigação seguia sem atribuição pública dos ataques e sem uma descrição completa das ações posteriores à exploração. O estado conhecido é que o primeiro patch deve ser substituído, interfaces web públicas precisam ser limitadas a endereços confiáveis e servidores com suspeita de comprometimento devem ser tratados como incidentes. Ainda são esperados novos indicadores, esclarecimentos sobre os problemas pós-instalação e a versão oficial.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.