Entraron por el servidor de impresión: el sistema que no está en ninguna lista de críticos

El 27 de agosto PaperCut avisó de dos fallas críticas en el software que administra la impresión de miles de oficinas, colegios y clínicas. Los ataques ya venían corriendo desde el día anterior. Y el parche que sacaron ese jueves no alcanzó: al día siguiente hubo que publicar otro. Si en tu empresa hay un servidor de impresión, es probable que nadie lo tenga en la lista de sistemas que hay que actualizar.

Hay una categoría de equipos que no entra en ninguna conversación de seguridad. No son el servidor de la base de datos, no son el correo, no son el firewall. Son los sistemas auxiliares: el que administra la impresión, el de las fichadas, el que graba las cámaras, el del control de acceso, el de la central telefónica. Están adentro de la red, andan solos hace años y nadie los mira porque "funcionan".

Esta semana le tocó a uno de esos. Y el caso sirve para mostrar exactamente cómo se rompe una empresa por el costado que no estaba mirando.

Qué pasó, en orden

26 de agosto. Investigadores de Huntress detectan actividad de ataque en servidores PaperCut de dos de sus clientes. En uno de los casos, todo el episodio dura menos de dos minutos. Todavía no hay aviso del fabricante ni parche disponible: esto es lo que se llama un día cero — primero pasa el ataque, después llega la noticia.

27 de agosto. PaperCut publica el aviso de seguridad y un parche de emergencia. Reconoce incidentes confirmados en clientes. Son dos vulnerabilidades:

• CVE-2026-82078 (severidad 9,4 sobre 10): carga dinámica insegura de clases en las utilidades de conexión a la base de datos. En criollo: el servidor puede ser inducido a cargar y ejecutar código Java que le manden.
• CVE-2026-81578 (severidad 8,8): control de acceso indebido en la interfaz web de administración. Permite que alguien sin estar logueado modifique la configuración del sistema.

28 de agosto. PaperCut publica un segundo parche de emergencia. Los equipos de watchTowr y Huntress habían encontrado varias formas de eludir el primero: watchTowr identificó una falla de autenticación adicional que la corrección original no cubría, y Huntress logró reproducir la cadena completa de ejecución remota sin autenticar aun con el parche puesto.

Ese detalle es el más importante de toda la nota y el que más se pasa por alto: quien actualizó el jueves y dio el tema por cerrado, sigue expuesto.

Cómo se encadenan las dos fallas

Ninguna de las dos, por separado, es catastrófica. El problema es que se combinan.

Primero, el atacante usa la falla de control de acceso para tocar la configuración del servidor sin credenciales. Lo que modifica es a dónde apunta la conexión de base de datos. Después, el servidor —haciendo exactamente lo que le pidieron— va a buscar el componente que necesita para conectarse, carga el código que encontró y lo ejecuta.

El resultado es ejecución remota de código sin autenticación previa: el atacante corre comandos en el servidor sin tener usuario, sin tener contraseña y sin ser nadie dentro del sistema. Y los corre con los permisos del servicio de impresión, que en la mayoría de las instalaciones son altos, porque el software necesita hablar con el directorio de usuarios, con las impresoras y con los recursos compartidos.

En los casos que se documentaron, lo primero que ejecutaron fue esto:

whoami & ver — y en el segundo caso, whoami & ver & tasklist.

Traducido: "¿con qué cuenta estoy corriendo?", "¿en qué versión de Windows caí?", "¿qué procesos hay dando vueltas?". Es reconocimiento, no destrucción. Es lo que hace alguien que acaba de entrar y todavía está midiendo dónde está parado. En los dos incidentes no se desplegó malware ni se dejó persistencia: por eso conviene leerlo como una etapa previa, no como el final de la historia.

Por qué esto no es "un problema de impresoras"

La palabra "impresión" hace que el tema suene menor. Conviene sacarla de la frase y mirar lo que queda: un servidor Windows, adentro de tu red, con permisos elevados, integrado al directorio de usuarios y —muy seguido— publicado a internet.

¿Por qué publicado a internet? Porque en algún momento alguien pidió imprimir desde la sucursal, desde la casa o desde el celular, y la forma rápida de resolverlo fue abrir el puerto. Esa decisión de hace tres años no está escrita en ningún lado y nadie la revisó desde entonces.

Para un atacante, ese servidor no es el objetivo: es la cabecera de playa. Una vez adentro, lo que importa no es la impresión, sino que desde ahí se ve el resto de la red y hay credenciales de servicio para robar.

Y no es una hipótesis. Ya pasó con este mismo producto. En 2023, la falla CVE-2023-27350 fue explotada masivamente: entraron por ahí los grupos de ransomware Cl0p y LockBit, la banda Bl00dy y actores vinculados a estados. El servidor de impresión no es un blanco exótico. Es una puerta conocida, que se revisa de nuevo cada vez que aparece una falla.

Lo que agrava el caso de esta semana

Dos cosas, más allá de la vulnerabilidad en sí.

El exploit ya es público. Se publicó un módulo de Metasploit que arma la cadena completa. Metasploit es la herramienta estándar de pruebas de penetración: que un ataque llegue ahí significa que dejó de requerir conocimiento y pasó a ser un botón. A partir de ese momento, el escaneo masivo de internet buscando servidores sin parchear es cuestión de horas.

El primer parche era incompleto. Esto rompe el reflejo habitual —"lo actualicé, listo"— y obliga a una segunda pasada. Es exactamente el mismo patrón que se vio este mes con N-central, la plataforma de gestión remota: se corrige una falla, alguien encuentra una variante que esquiva la corrección, y hay que volver a parchear. Cuando un producto entra en ese ciclo, la única postura sensata es asumir que va a haber una tercera versión y no soltar el tema.

Qué hacer si tenés PaperCut

1. Actualizar a la Release 2, la del 28 de agosto, no a la del 27. Mínimo: 25.0.12.76497 para NG y 25.0.12.76496 para MF. Hay correcciones para las versiones 24, 25 y 26; si estás en la 23 o anterior, no hay parche: hay que migrar.
2. Actualizar también los servidores secundarios y los servidores de impresión, no solo el principal. Es el punto que más se saltea.
3. Sacar el servidor de internet. Si la interfaz de administración contesta desde afuera, restringirla a direcciones IP confiables. Para el acceso remoto legítimo, VPN. Esto solo, sin parche, ya corta la mayoría del riesgo.
4. Preservar la evidencia antes de tocar nada. Copiar la carpeta server/logs completa. El parche tapa el agujero pero no borra lo que haya quedado, y una reinstalación apurada destruye la única forma de saber si entraron.
5. Buscar rastros. En los registros: la cadena DB URL: jdbc:derby:memory:pwn, el error No suitable driver found for jdbc:no:x y errores de base de datos al consultar cardID. En el disco: archivos .class que nadie reconozca dentro de server/lib/, y archivos .cmd o .out sueltos en server/data/content/. En el sistema: que el proceso pc-app.exe haya lanzado una consola de comandos.
6. Si aparece algo de eso, el alcance ya no es el servidor. Hay que asumir que las credenciales que ese equipo tenía guardadas están comprometidas y rotarlas.

Y si no tenés PaperCut, igual te toca

Cambiá "PaperCut" por el sistema auxiliar que tengas y la historia se repite. Lo que este caso deja no es una marca: son cuatro preguntas que casi ninguna pyme puede contestar hoy.

1. ¿Qué servidores tuyos contestan desde internet? No cuáles creés que contestan: cuáles contestan. Es una lista que se obtiene mirando, no recordando.
2. ¿Quién tiene asignado actualizarlos? Con nombre y apellido. Si la respuesta es "el proveedor que lo instaló", conviene confirmar que ese proveedor todavía crea que es su trabajo.
3. ¿Cómo te enterás de que salió un parche urgente? Si la respuesta es "cuando lo veo en alguna parte", no hay proceso: hay suerte.
4. Si entraron, ¿lo sabrías? Los dos incidentes de este caso duraron minutos y no dejaron malware. Sin registros guardados y sin nadie que los mire, un episodio así no deja ninguna señal visible.

Ninguna de estas cuatro cosas se resuelve comprando un producto. Se resuelven con inventario, con un responsable asignado y con una rutina que alguien ejecute todos los meses aunque no pase nada. Es trabajo aburrido, y por eso es el primero que se cae de la lista.

El fondo del asunto

La seguridad de una pyme casi nunca se rompe por donde se la imagina. No entra por el servidor que todos cuidan: entra por el que nadie recuerda que existe. La impresión, las cámaras, el reloj de fichadas, el equipo que quedó de un proyecto que terminó en 2021.

Y el atacante no eligió tu empresa. El escaneo que busca servidores PaperCut sin actualizar es automático y no distingue entre una universidad de veinte mil alumnos y un estudio contable de doce personas. Encuentra el que contesta.

Ese trabajo constante —inventariar lo que está expuesto, parchear con fecha y responsable, guardar registros y revisarlos— es un servicio, no una tarea suelta. En Tecnicanet lo hacemos todos los días: mirá Ciberseguridad gestionada, donde el seguimiento de vulnerabilidades y el parcheo están en el abono.

Y si querés empezar por saber qué tenés y qué está mirando hacia afuera, una auditoría tecnológica es el punto de partida: la lista de servidores, servicios expuestos y responsables que hoy no está escrita en ningún lado.

Fuentes

• PaperCut Software — aviso de seguridad del 27 de agosto de 2026 y segundo parche de emergencia (Release 2) del 28 de agosto de 2026.
• Huntress — PaperCut Zero-Day: Active Exploitation and Pre-Auth RCE (27 de agosto de 2026): explotación observada desde el 26 de agosto, comandos ejecutados e indicadores de compromiso.
• watchTowr — identificación de una vulnerabilidad de autenticación adicional no cubierta por el primer parche.
• Rapid7 — PaperCut NG/MF Critical Zero-Day Exploited in the Wild: análisis de la cadena y módulo de Metasploit multi/http/papercut_ng_external_user_lookup_rce.
• BleepingComputer — PaperCut releases second emergency patch for exploited flaws (28 de agosto de 2026), incluido el antecedente de CVE-2023-27350 explotado por Cl0p, LockBit y Bl00dy en 2023.