PaperCut: el servidor de impresión corre como SYSTEM, y casi la mitad del parque medido no tiene parche

Todo edificio tiene una puerta principal con recepción, y una puerta de servicio por la que entran las cajas y sale la basura. La primera tiene cámara, registro de visitas y alguien mirando. La segunda está abierta media mañana porque es lo cómodo. En una red corporativa, la puerta de servicio suele ser el servidor de impresión: no está en la lista de sistemas críticos, no lo tocó nadie en dos años y funciona. Esta semana ha sido, otra vez, por donde han entrado.

El 27 de agosto, PaperCut publicó un aviso urgente para todos los clientes de PaperCut NG y PaperCut MF: estaba investigando explotación activa y había incidentes de clientes confirmados. Al día siguiente llegaron los identificadores. CVE-2026-81578, control de acceso indebido en la interfaz web de gestión, CVSS 8.8. CVE-2026-82078, carga dinámica de clases insegura en las utilidades de conexión a base de datos, CVSS 9.4. Encadenados, dan ejecución remota de código sin autenticar dentro del proceso del Application Server.

Hasta aquí, la noticia que ya has leído en otros sitios y que acaba siempre igual: parchea ya. Nosotros queremos detenernos en dos cosas que en las coberturas aparecen de pasada y que, para una empresa normal, son las que de verdad deciden el desenlace. Una es con qué cuenta corre ese servicio. La otra es que casi la mitad de las instalaciones que alguien ha podido contar no tiene ningún parche que aplicar.

Tres días, contados en orden

La cronología importa porque marca quién iba por delante, y conviene leerla con los relojes puestos: PaperCut es una empresa de Melbourne y fecha sus actualizaciones en hora australiana. Huntress observó la actividad de explotación en entornos de clientes los días 26 y 27 de agosto. El 27 se publicó el boletín. El primer parche de emergencia salió a las 02:10 AEST del 28, que aquí son las seis y diez de la tarde del jueves 27, y solo cubría las ramas 25 y 26. El viernes 28 se asignaron los dos CVE. Es decir: el fallo se estaba usando antes de que existiera el aviso, que es la definición de día cero y no una manera dramática de contarlo.

La escala, en cambio, es más modesta de lo que sugiere el ruido: Huntress habla de actividad limitada en dos entornos de clientes, y describe uno de los incidentes como algo que duró menos de dos minutos en total. Esa cifra no es la duración de un ataque contra una empresa; es la duración de la parte que se ve. Hay otro detalle en el boletín que se lee rápido y dice mucho: PaperCut cuenta que pudo reproducir el fallo gracias a la información que le pasaron el equipo de seguridad y los forenses de un cliente universitario. Quien encontró esto no fue un escáner: fue alguien mirando su propio incidente.

La palabra que cambia el tamaño del problema: SYSTEM

La cadena, tal como la describe Huntress, tiene dos pasos y ninguno es exótico. Primero, una petición construida de forma que referencia una página para renderizarla mientras ejecuta acciones de otra: con eso se salta la comprobación de autorización de la interfaz de gestión. Segundo, se aprovechan las utilidades de conexión a base de datos para cargar bytecode Java arbitrario. El primer fallo abre la puerta y el segundo mete el código.

Lo que se hizo después es rutina de manual: comandos de descubrimiento codificados en base64 —whoami & ver, y luego whoami & ver & tasklist—, ficheros .class depositados en el servidor, la salida volcada a un fichero, y borrado de registros y de payloads al terminar. El detalle que a nosotros nos hizo levantar la vista no está en esas intrusiones, sino en la prueba de concepto que Huntress rehízo en su laboratorio: desde una máquina remota consiguieron lanzar un proceso observable, charmap.exe, colgando de pc-app.exe y corriendo como SYSTEM. Lo que un atacante ejecute ahí dentro se ejecuta con ese nivel.

El 47 %: para casi la mitad, «parchea ya» no significa nada

Huntress publicó de pasada la cifra que ordena todo lo demás. Tiene visibilidad sobre unas 2.500 instalaciones de PaperCut y dice que el 47 % de ellas va por la versión 23 o anterior. Es su telemetría, no un censo mundial, pero es el único número real que hay sobre la mesa. Para esa rama no hay parche, y el fabricante lo dice sin rodeos en su FAQ: «el camino recomendado para todos los clientes anteriores a PaperCut NG/MF v24 es actualizar a la última versión».

Esa frase, dicha un viernes con explotación activa, describe un proyecto y no una tarea. Aplicar un parche de emergencia es una ventana de mantenimiento corta y un reinicio del servicio. Saltar de versión mayor en un sistema de impresión corporativo es otra cosa: revisar compatibilidad de los drivers, la integración con el directorio, las tarjetas de los usuarios, las aplicaciones embebidas de cada marca de multifunción, y una prueba antes de tocar producción. El trabajo que le toca al 47 % no cabe en una tarde de viernes. Y la parte incómoda es que ese trabajo no ha aparecido ahora: llevaba años sin hacerse, y lo que ha cambiado es que hoy tiene fecha límite.

Es nuestra lectura, y la marcamos como lectura: ese 47 % no es negligencia, es lo que pasa cuando un servidor no tiene dueño claro. El de impresión suele quedar en tierra de nadie entre quien administra los sistemas y quien gestiona el contrato de las fotocopiadoras. No es que alguien decidiera no actualizarlo; es que no aparecía en ninguna lista donde apareciera esa decisión. Lo mismo que contábamos sobre el agente de gestión remota que instala tu proveedor: el software que llega por un canal distinto al de IT hereda el ciclo de vida de nadie.

El parche del jueves no valía el viernes

A las 20:42 AEST del 28 —mediodía del viernes aquí— PaperCut publicó una segunda tanda de parches de emergencia, Emergency Patch Release 2, después de trabajar con su equipo interno y con investigadores de Huntress y watchTowr que habían encontrado varias formas de saltarse los parches originales, además de un fallo adicional de salto de autenticación. La rama 24, que se había quedado fuera del primer parche, no tuvo el suyo hasta hora y media más tarde. El fabricante lo dice sin adornos: instala la Release 2 aunque ya hayas aplicado el parche original. Quien parcheó a conciencia el jueves por la tarde, el viernes seguía expuesto.

Esto no es un reproche al fabricante: sacar dos rondas en menos de un día, con investigadores externos encima, es hacerlo bien. Es un reproche a cómo nos organizamos el resto. Un parche no es un evento, es un estado. Si tu proceso consiste en aplicar el parche y cerrar el ticket, la ventana de exposición de tu empresa la marca el día que pasaste por ahí, no el estado real del software. El criterio que defendemos es el contrario: un parche no está cerrado hasta que alguien vuelve a comprobar la versión instalada contra el aviso tal como está hoy, no como estaba cuando lo leíste.

Y hay un corolario práctico: si el parche se puede saltar, la mitigación de red es la que aguanta las dos veces. Conviene subrayar quién lo dice, porque no es una ocurrencia nuestra: el propio PaperCut coloca esto en una sección titulada Immediate action required, por delante de la del parche, y con una frase que no admite lectura tibia: «haz esto ahora, aunque no hayas observado actividad sospechosa». Restringir el acceso web del servidor a direcciones de confianza —los rangos internos— con reglas de cortafuegos o controles de acceso a red. Rapid7 dice lo mismo y Huntress añade la VPN y una pregunta que deberías responder por escrito: revisa por qué una interfaz de gestión de PaperCut es alcanzable desde internet. Cuando llega un aviso así, primero se cierra el acceso y después se parchea.

Esto ya pasó en 2023, y con el mismo producto

El 11 de mayo de 2023, CISA y el FBI publicaron un aviso conjunto titulado, literalmente, Malicious Actors Exploit CVE-2023-27350 in PaperCut MF and NG. Aquel fallo era ejecución remota de código sin credenciales, CVSS 9.8. El FBI observó explotación desde mediados de abril y, a principios de mayo, un grupo que se hacía llamar Bl00dy Ransomware Gang lo estaba usando contra el subsector de instalaciones educativas. La frase que cierra el círculo está en el propio aviso: entraron en redes donde los servidores PaperCut vulnerables estaban expuestos a internet. Algunas de esas operaciones acabaron en exfiltración y cifrado.

Tres años después, distinto CVE, distinta cadena, mismo producto y —esta es la parte que duele— mismo prerrequisito. Lo que no ha cambiado en tres años no es el software. Es que ese servidor sigue sin tener a nadie que se levante un martes pensando en él.

Qué mirar esta tarde, en este orden

Si tienes PaperCut NG o MF, esto es una tarde y no hace falta ningún proyecto:

• ¿Se llega desde fuera? Es la primera pregunta y la única que puedes contestar sin tocar el servidor. Si la interfaz de gestión responde desde internet, ciérrala ahora mismo a los rangos internos o a la VPN. Esto vale tanto si has parcheado como si no, y habría valido también en 2023.
• ¿Qué versión exacta tienes? No «la última que instalamos», el número. Si es 24, 25 o 26, hay parche de emergencia y tiene que ser el de la segunda tanda. Cuidado aquí, porque es fácil equivocarse: los números de compilación que circulan para la rama 25 en Windows —25.0.12.76497 (NG) y 25.0.12.76496 (MF)— son los del primer parche, no los de la Release 2. Para la segunda tanda, PaperCut no publica número de compilación, solo el SHA256 de cada instalador en el propio boletín: verifica contra ese hash y no contra un número de versión. Si vas por la 23 o anterior, no hay parche: te toca planificar el salto de versión, y mientras tanto el punto anterior es tu único control real.
• ¿Y el resto de servidores? No basta con el Application Server principal. PaperCut dice que los Site Servers y los servidores secundarios o de impresión también hay que llevarlos a una versión parcheada. En cambio, Print Deploy y Mobility Print no están afectados y no hay que tocarlos; sobre este último el fabricante es explícito hasta con los puertos: Mobility Print corre sobre una arquitectura separada y no está impactado, así que puedes dejar sus puertos abiertos. Saber qué NO hay que tocar ahorra tanto tiempo como saber qué sí.
• ¿Con qué cuenta corre el servicio? Míralo en los servicios de Windows, no lo supongas. Si es SYSTEM, ya sabes cuánto vale un fallo de ejecución de código ahí dentro. Bajar privilegios en un servidor de impresión no siempre es trivial, pero al menos que sea una decisión tomada y no una casilla que vino marcada del instalador.
• Busca las huellas antes de reiniciar nada. Los indicadores que ha publicado Huntress son muy concretos: la cadena DB URL: jdbc:derby:memory:pwn en el server.log; entradas con nombres de base de datos irregulares en /data/internal/derby.log; ficheros .class inesperados en el directorio server/lib/; un server.log ausente o truncado; los errores No suitable driver found for jdbc:no:x y DatabaseUtils - Database error looking up cardID: VALUES CAST; y cualquier shell o utilidad de descubrimiento lanzada como hija de pc-app.exe. Y aquí un aviso que hoy no está en ninguna cobertura: esta misma mañana, PaperCut ha abierto en su boletín una nota sobre problemas posteriores al parche en la búsqueda de número de tarjeta/ID contra base de datos externa y en SAML. Traducido: ese último error puede aparecerte por haber parcheado, no por haber sido atacado. Si usas búsqueda de tarjeta contra una base de datos externa —el fabricante dice que es una función poco usada—, hay que añadir security.card-number-lookup.enabled=Y a server/security.properties y reiniciar el Application Server; sin esa clave, PaperCut ignora en silencio las consultas externas aunque la interfaz siga mostrando la función como configurada.
• ¿Ese servidor lo ve tu EDR? Un antivirus de firmas no marca charmap.exe: es un binario legítimo de Windows. Lo que delata la intrusión es la relación —un proceso hijo raro colgando del servicio de impresión— y eso lo ve una herramienta que mira comportamiento y linaje de procesos. Y ojo con darlo por hecho: el agente no siempre está donde crees, como contamos cuando alguien apagó un EDR con un reinicio en modo seguro.
• ¿Quién es el dueño? Escribe un nombre al lado de ese servidor. No un departamento: un nombre. Es la única de las seis cosas de esta lista que sigue sirviendo dentro de tres años, cuando salga el siguiente aviso.

Cuándo esto no va contigo

Si no usas PaperCut, esta noticia concreta no te toca y no vamos a fingir lo contrario para alargar el post. Y si lo usas, y estás en una rama con parche, y su interfaz de gestión nunca ha visto internet, tienes un rato de trabajo y poco más: aplica la segunda tanda, revisa los indicadores y sigue con tu día. Tampoco te vamos a decir que corras a comprar nada: en este incidente, el control que más ha valido —restringir el acceso a la consola— no cuesta dinero, cuesta media hora de alguien con permisos en el cortafuegos.

Y hay una cosa que no te podemos prometer, ni nosotros ni nadie: que hubieras parcheado a tiempo. La explotación se vio el 26; el aviso salió el 27; el parche bueno, el 28. Contra esa ventana no hay proceso de parcheo que gane. Lo que sí decide el desenlace es todo lo demás: si la consola estaba en internet, si el servicio corría como SYSTEM, si alguien mira los logs de ese servidor y si hay una herramienta que se hubiera fijado en un proceso hijo extraño a las tres de la mañana. Y si la respuesta a todo eso es mala, la salida que recomienda el propio fabricante no es agradable pero es la honesta: asegurar las copias actuales, arrasar y reconstruir el Application Server y restaurar una copia limpia anterior a cualquier comportamiento sospechoso. Fíjate en lo que hay debajo de esa frase: hace falta tener copias, saber de qué día es cada una y poder decir a partir de cuándo dejaron de ser de fiar.

La puerta de servicio también es una puerta

En nuestro trabajo diario, la diferencia entre las casas donde esto se resuelve en una tarde y las casas donde se convierte en una semana mala no es el presupuesto ni el fabricante del cortafuegos. Es si existe un inventario donde ese servidor tiene una fila, una versión escrita y un nombre al lado. Eso es, sin adornos, lo que hacemos en mantenimiento informático: no «parchear», sino sostener el estado de un parque completo, incluidos los servidores que no instalamos nosotros y los que nadie clasificaría como críticos.

La otra mitad es aceptar que habrá días en que el parche llegue tarde, porque en este caso llegó tarde para todo el mundo. Ahí la pregunta ya no es «¿estaba parcheado?», sino «¿cuánto tiempo estuvo alguien dentro antes de que nos enteráramos?». Esa la contesta una vigilancia que mira comportamiento y linaje de procesos: EDR y MDR gestionado. Y el conjunto —qué exponemos, con qué privilegios y quién lo mira— es de lo que hablamos cuando hablamos de ciberseguridad: un montón de decisiones pequeñas tomadas antes de que hagan falta.

Dentro de tres años habrá otro aviso urgente, y no será de PaperCut. Será de otro trasto discreto que lleva años funcionando sin dar guerra, instalado por alguien que ya no trabaja aquí, corriendo con más privilegios de los que necesita. Lo único que sirve contra ese futuro es aburrido y no se vende: que ese trasto tenga una fila en una lista, con una versión al lado y un nombre detrás.

Fuentes (verificadas una a una, consultadas el 29 de agosto de 2026): la cadena de explotación paso a paso, la actividad observada los días 26 y 27 de agosto, los comandos whoami & ver y whoami & ver & tasklist, los ficheros .class, la prueba de concepto en la que charmap.exe se ejecuta como SYSTEM bajo pc-app.exe (es su laboratorio, no una intrusión observada: lo señalamos porque en varias coberturas se mezcla), la lista de indicadores de compromiso, las compilaciones 25.0.12.76497 (NG) y 25.0.12.76496 (MF) —que son las del primer parche—, el dato de que el 47 % de las aproximadamente 2.500 instalaciones de PaperCut que Huntress sigue van por la v23 o anterior, el incidente de menos de dos minutos en total y la recomendación de la VPN — Huntress, «PaperCut Actively Exploited: A Pre-Auth RCE Chain». La sección Immediate action required y su «hazlo ahora aunque no hayas visto nada raro», la cronología completa con horas AEST, la Emergency Patch Release 2 y los SHA256 de los instaladores, la FAQ sobre la v23 y anteriores, la clave security.card-number-lookup.enabled=Y, el aviso del 29 de agosto sobre fallos posteriores al parche en Card/ID y SAML, el alcance a Site Servers y servidores secundarios, que Mobility Print no está afectado, la recomendación de reconstruir el servidor y restaurar copia limpia si se sospecha compromiso, y que la información vino del equipo de seguridad y los forenses de un cliente universitario — boletín de seguridad de PaperCut. Los identificadores CVE-2026-81578 (CVSS 8.8) y CVE-2026-82078 (CVSS 9.4) y la cita sobre restringir el acceso web a direcciones de confianza — Rapid7, análisis del día cero. Los bypasses de los parches originales hallados por watchTowr y Huntress y el fallo adicional de salto de autenticación — BleepingComputer, 28 de agosto de 2026. El precedente de 2023, la explotación desde mediados de abril, la Bl00dy Ransomware Gang contra el subsector educativo y los servidores expuestos a internet — aviso conjunto CISA/FBI AA23-131A, 11 de mayo de 2023. Son nuestras, y las marcamos como criterio y no como hechos publicados: la lectura del 47 % como problema de propiedad del servidor y no de negligencia, la idea de que un parche es un estado y no un evento, y las seis comprobaciones de la lista. El orden «cerrar el acceso antes que parchear» no es nuestro: es de PaperCut, que lo puso primero en su boletín.