Duas falhas do PaperCut NG/MF, identificadas pelos códigos CVE-2026-81578 e CVE-2026-82078, entraram no catálogo de Vulnerabilidades Conhecidas Exploradas da CISA em 31 de agosto de 2026, depois que a exploração saiu das sondagens e passou a incluir invasões ativas. O caso exige atenção porque as vulnerabilidades podem ser encadeadas para permitir acesso sem autenticação e execução remota de código, isto é, a capacidade de fazer um sistema executar comandos à distância. A seguir, o ponto central é entender o que cada falha abre, por que a evolução dos ataques muda a urgência e qual correção deve ser aplicada.

Quando duas falhas formam uma única porta de entrada

A primeira vulnerabilidade, a CVE-2026-81578, está associada a uma falha de autenticação em uma função crítica do PaperCut, enquanto a CVE-2026-82078 envolve uma reflexão insegura. Em termos práticos, a cadeia descrita pelas fontes permite que um atacante não autenticado modifique configurações pela interface web e, em seguida, execute código Java arbitrário. A autenticação funciona como a porta que deveria separar visitantes de usuários autorizados; quando esse controle é contornado, a interface deixa de ser apenas um painel administrativo e passa a participar da invasão. O segundo estágio transforma essa entrada em capacidade de execução, e é justamente essa sequência que torna o problema mais grave do que duas falhas isoladas.

Essa combinação alcança as versões 24, 25 e 26 do PaperCut NG e MF, segundo os detalhes técnicos reunidos pelas fontes. A execução remota de código sem autenticação reduz a quantidade de barreiras entre uma requisição feita por um invasor e uma ação realizada no servidor. A pergunta que fica para quem administra o software é direta: a instalação está apenas vulnerável em teoria ou já recebeu tentativas de exploração? A resposta não deve ser construída somente pela leitura de registros genéricos de vulnerabilidades, porque as evidências apresentadas incluem tentativas reais e uma progressão operacional que leva o caso para dentro da rotina de resposta a incidentes.

Da sondagem à presença dentro da rede

A gravidade ganhou um marcador concreto quando a Huntress detectou tentativas reais de exploração em 26 de agosto de 2026. A informação aproxima o alerta da atividade observada nos sistemas, em vez de deixá-lo restrito ao campo das possibilidades técnicas. Para organizações que mantêm versões afetadas, essa diferença importa: uma falha descrita em um relatório pode exigir atualização preventiva, mas uma tentativa registrada exige também verificar se houve sinais de acesso e se o equipamento exposto continua confiável. A própria sequência de datas mostra uma corrida entre a descoberta, as correções e a ação dos invasores, e o passo seguinte dessa história foi ainda mais expressivo.

Essa mudança apareceu nas observações da WatchTowr, que identificou a evolução das explorações para uma interação "mãos no teclado", expressão usada para descrever a atuação direta de invasores depois do acesso inicial. Os atacantes passaram a utilizar ferramentas de acesso remoto para manter a persistência, ou seja, conservar uma forma de voltar ao ambiente, e para fazer a movimentação lateral, que consiste em avançar internamente pela rede comprometida. A diferença entre uma sondagem automatizada e uma presença operada por pessoas é semelhante à diferença entre testar uma fechadura e permanecer dentro do prédio: a segunda situação pede uma investigação mais ampla sobre o que aconteceu depois da primeira entrada.

O alerta da WatchTowr acrescenta uma orientação severa para sistemas expostos à internet e que não foram corrigidos desde a descoberta: eles devem ser assumidos como comprometidos. Essa recomendação não afirma que cada instalação afetada sofreu o mesmo tipo de dano, mas muda a pergunta operacional que precisa ser feita. Em vez de perguntar apenas se o patch foi instalado, a equipe precisa considerar se o sistema exposto deve continuar sendo tratado como uma fonte confiável de acesso à rede. A noção de confiança, tão discreta no cotidiano digital quanto a moldura invisível de uma obra de arte, passa a depender de evidências técnicas, e não de uma expectativa de que ninguém tenha atravessado a porta.

Por que o segundo patch importa

A resposta do fabricante passou por duas etapas em poucos dias. A primeira correção foi publicada em 27 de agosto, mas pesquisadores conseguiram contorná-la; por essa razão, a fonte técnica orienta a aplicação do Emergency Patch Release 2, publicado em 28 de agosto de 2026. A cronologia elimina uma interpretação perigosa: instalar qualquer atualização relacionada ao caso não significa automaticamente que a cadeia de exploração deixou de funcionar. Quando uma correção é contornada, o problema deixa de ser apenas manter o inventário atualizado e passa a exigir a confirmação da versão e do pacote exato aplicados em cada instalação.

Esse detalhe muda a forma de organizar a prioridade. O administrador que atualizou o PaperCut no primeiro momento precisa confirmar se recebeu a segunda correção, enquanto quem ainda mantém as versões afetadas precisa tratar o Emergency Patch Release 2 como o ponto de referência indicado pelas fontes. O encadeamento envolve uma falha que permite alterar configurações e outra que permite executar Java arbitrário, portanto a verificação não deve parar no nome do produto ou no número geral da versão. A correção precisa ser relacionada ao pacote de emergência correto, porque a história do primeiro patch contornado mostra que a aparência de atualização pode esconder uma proteção incompleta.

O alerta da CISA como relógio operacional

A inclusão das duas vulnerabilidades no catálogo Known Exploited Vulnerabilities, conhecido pela sigla KEV, formalizou a exploração ativa para fins de priorização pela CISA. Com base na Diretiva Operacional Vinculante BOD 26-04, as agências federais dos Estados Unidos devem priorizar a correção até 14 de setembro de 2026. O prazo se aplica ao setor federal americano, mas o valor informativo do alerta alcança qualquer organização que utilize o PaperCut e precise decidir qual atualização vem primeiro. Um catálogo desse tipo funciona como um relógio: ele transforma a existência de uma falha em uma tarefa com urgência definida, especialmente quando já há registros de exploração.

Há, contudo, uma fonte adicional de confusão nos registros técnicos associados aos CVEs. Mesmo depois da inclusão no KEV e da liberação dos patches, bases como NVD/SSVC ainda exibiam o status de exploração como "none", ou seja, nenhum. A divergência entre esse campo e o alerta oficial da CISA pode levar uma equipe a diminuir a prioridade justamente quando as evidências apontam na direção oposta. A recomendação reunida nas fontes é ignorar esse status isolado e priorizar a correção com base no alerta da CISA e nas evidências públicas de exploração, uma escolha que lembra uma regra elementar da investigação: quando dois sinais discordam, é preciso examinar a origem e o contexto de cada um.

A caixa de ferramentas para agir agora

Para sair da notícia e chegar à ação, a sequência deve começar pelo inventário das instalações do PaperCut NG/MF, com atenção às versões 24, 25 e 26 mencionadas na análise técnica. Em seguida, a equipe deve confirmar se o pacote aplicado é o Emergency Patch Release 2, e não apenas a primeira correção de 27 de agosto. Se o sistema esteve exposto à internet e permaneceu sem correção desde a descoberta, a orientação das fontes é tratá-lo como comprometido, enquanto a presença de ferramentas de acesso remoto, persistência ou movimentação interna deve entrar na verificação. A lista abaixo organiza o essencial sem transformar a resposta em um ritual automático:

  • Verifique se a instalação está entre as versões afetadas, 24, 25 ou 26.
  • Confirme a aplicação do Emergency Patch Release 2, publicado em 28 de agosto de 2026.
  • Considere comprometidos os sistemas expostos à internet e não corrigidos desde a descoberta.
  • Leve em conta as evidências de exploração ativa, mesmo que outra base ainda mostre o status "none".

O próximo passo tem uma data clara para o setor federal dos Estados Unidos: 14 de setembro de 2026 é o prazo definido para priorizar a correção. Para as demais organizações, a combinação entre tentativas reais detectadas pela Huntress, invasões ativas observadas pela WatchTowr e o desvio da primeira correção fornece a medida prática da urgência. O PaperCut pode parecer uma peça silenciosa da rotina, quase como um mecanismo escondido atrás da folha impressa, mas as falhas mostram que componentes discretos também podem abrir caminhos profundos pela rede; confirmar a correção certa e avaliar a exposição são as decisões que devolvem o controle às equipes.