PaperCut obliga a parchear dos veces: la primera corrección podía eludirse
PaperCut publicó el 28 de agosto Emergency Patch Release 2 para PaperCut NG y MF después de que investigadores encontraran varias formas de eludir la primera corrección. La cronología de BleepingComputer recoge que la empresa pide instalar esta segunda entrega incluso en servidores que ya recibieron el parche original.
Por tanto, Release 1 ya no basta para considerar corregido un servidor. Una alerta publicada ese mismo 28 de agosto por NHS England señala explotación activa reportada de CVE-2026-81578 y CVE-2026-82078, recomienda aplicar Release 2 cuanto antes y retirar de Internet las interfaces web de PaperCut que no puedan actualizarse inmediatamente.
Por qué el primer parche dejó de ser suficiente
Release 2 no es una actualización opcional para quienes llegaron tarde. PaperCut la preparó con refuerzos adicionales después de que Huntress y watchTowr colaboraran en el análisis; ambas firmas reprodujeron la cadena de ataque y hallaron vías para sortear las correcciones iniciales.
Las dos vulnerabilidades cubren etapas complementarias. CVE-2026-81578 permite que solicitudes remotas sin autenticar activen determinadas funciones administrativas antes de concluir las comprobaciones de acceso y modifiquen configuraciones. CVE-2026-82078 afecta a la carga dinámica de clases en las utilidades de conexión a bases de datos: si un atacante logra manipular los parámetros necesarios, puede ejecutar bytecode Java dentro del contexto del proceso de PaperCut.
Esta relación explica el riesgo de encadenamiento: la primera vulnerabilidad abre la posibilidad de alterar la configuración y la segunda convierte ese control en ejecución de código. El segundo parche incorpora protecciones frente a las rutas identificadas durante la investigación, mientras la empresa continúa preparando una versión oficial sometida a su proceso ordinario.
La matriz de versiones y componentes
El boletín oficial de PaperCut, actualizado el 30 de agosto, delimita las ramas cubiertas, los componentes que requieren intervención y los indicadores observados durante la respuesta al incidente.
- PaperCut NG y MF 24, 25 y 26: instalar Emergency Patch Release 2. Existen paquetes para Windows, Linux y macOS.
- PaperCut NG y MF 23 o anteriores: migrar a la versión más reciente; la ruta recomendada no es esperar un parche para esas ramas.
- Application Servers, Site Servers y servidores secundarios o de impresión: deben quedar en una versión parcheada. Actualizar solo el Application Server principal no completa la remediación.
- Print Deploy y Mobility Print: no están afectados por estas vulnerabilidades y no necesitan esta actualización.
El aviso considera potencialmente afectadas todas las versiones de PaperCut NG y MF, aunque Release 2 solo se distribuye directamente para las ramas 24, 25 y 26. Es un parche de emergencia, no una versión oficial completa: al cierre del 30 de agosto, PaperCut seguía trabajando en esa entrega ordinaria.
Parchear y contener resuelven problemas distintos
La contención temporal consiste en impedir que direcciones de Internet no confiables alcancen las interfaces web del Application Server. Puede aplicarse mediante reglas de cortafuegos, controles de acceso de red o medidas equivalentes, sin esperar a que aparezca una alerta.
Esa restricción reduce la superficie accesible, pero no corrige el código ni descarta una intrusión anterior. La secuencia operativa debe cubrir ambas necesidades:
- Inventariar Application Servers, Site Servers y servidores secundarios, incluida la versión instalada en cada uno.
- Retirar la exposición pública de las interfaces web o limitarlas a direcciones internas y de confianza.
- Instalar Release 2 en las ramas 24, 25 y 26, aunque el historial ya muestre la primera corrección.
- Migrar las instalaciones de la versión 23 o anteriores a una rama compatible.
- Revisar telemetría y registros históricos para buscar actividad anterior y posterior al parcheo.
Tras la instalación también hay dos incidencias funcionales bajo investigación: consultas externas de números de tarjeta o identificación y SAML que no funcionan como se esperaba. En entornos con SQL Server y el controlador jTDS heredado para esas consultas, la primera medida recomendada es migrar al controlador Microsoft SQL JDBC compatible más reciente, aunque el cambio puede no resolver todos los casos.
Qué indicios de explotación deben revisarse
La búsqueda debe combinar telemetría del endpoint, la red y la aplicación. Entre los indicios están la actividad sospechosa iniciada por pc-app.exe o pc-app, así como archivos server.log ausentes, eliminados o truncados de manera inesperada.
En server.log deben buscarse errores sobre controladores JDBC inexistentes y consultas de cardID que incluyan “VALUES CAST”. Los indicadores añadidos el 30 de agosto comprenden una base Derby en memoria denominada “pwn”, referencias hexadecimales que comienzan por “cafebabe” y nombres aleatorios de cinco caracteres asociados al controlador de base de datos.
También se observaron archivos con nombres aleatorios de cinco caracteres y extensiones .class, .cmd u .out en directorios del servidor. En algunos sistemas, el proceso de PaperCut inició cmd.exe y ejecutó órdenes de reconocimiento como whoami, ver y tasklist. La aparición de un servicio de Windows llamado “Remote Access Service” que ejecute SimpleService.exe, o una instalación inesperada de AnyDesk, exige investigación.
La ausencia de esos elementos no demuestra que el servidor esté limpio, porque los archivos pueden ser eliminados durante el ataque y no existe un patrón único para todos los entornos. Ante una sospecha fundada, PaperCut recomienda preservar las copias disponibles, borrar y reconstruir por completo el Application Server, restaurar una copia limpia anterior a la actividad sospechosa y activar el procedimiento interno de respuesta a incidentes.
La corrección es inmediata, la investigación continúa
PaperCut reconoce incidentes confirmados entre sus clientes, pero no ha atribuido los ataques ni ha determinado públicamente todo lo ocurrido después del acceso. Release 2 es la corrección vigente mientras avanza el análisis y se prepara una versión oficial.
El estado al 30 de agosto combina tres controles que no son intercambiables: instalar Release 2, limitar la exposición de las interfaces web y revisar evidencias históricas. Los administradores aún deben esperar la versión ordinaria y posibles indicadores adicionales, pero quienes aplicaron Release 1 ya tienen una conclusión inequívoca: deben parchear de nuevo.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.