NoticiasNews

El primer parche duró 48 horas: PaperCut publica una segunda corrección de emergencia tras confirmarse que la primera se podía evadirThe First Patch Lasted 48 Hours: PaperCut Issues a Second Emergency Fix After the First One Was Bypassed

2026-09-01

El 27 de agosto de 2026, PaperCut divulgó en un boletín de seguridad urgente dos vulnerabilidades de día cero que ya estaban siendo explotadas en ataques reales: CVE-2026-81578 y CVE-2026-82078. Encadenadas, permiten ejecución remota de código antes de la autenticación.

Qué falla

CVE-2026-82078 es un problema crítico de carga dinámica insegura de clases en las utilidades de conexión a base de datos del producto. Si un atacante logra manipular parámetros de configuración del sistema, puede provocar la ejecución de bytecode Java arbitrario ya presente en el classpath de la aplicación, con el contexto de seguridad del propio proceso del servidor PaperCut. Combinada con CVE-2026-81578, la cadena completa habilita RCE sin credenciales.

La parte incómoda: el parche se pudo evadir

El primer parche de emergencia cerró la vía de acceso inicial de la cadena. En aproximadamente 48 horas, PaperCut confirmó que la corrección podía ser evadida y publicó una segunda. El giro vino de investigación externa: el equipo de watchTowr reprodujo completamente las vulnerabilidades y descubrió múltiples maneras de saltarse el parche inicial. Huntress, por su parte, reprodujo la cadena completa de RCE preautenticación y observó explotación en dos entornos de clientes, donde los atacantes parecían estar realizando reconocimiento.

La segunda corrección, Emergency Patch Release 2, está disponible para PaperCut NG y MF versiones 24, 25 y 26 en Windows, Linux y macOS. Las vulnerabilidades fueron incorporadas al catálogo KEV de CISA.

Por qué un servidor de impresión es un objetivo tan bueno

Es tentador clasificar esto como “un problema de la impresora”. No lo es. Un servidor de gestión de impresión suele tener tres características que lo vuelven un punto de pivote ideal:

Está en la red interna, con visibilidad hacia estaciones de trabajo y a veces hacia directorio.
Corre con privilegios elevados porque necesita gestionar colas, dispositivos y cuentas de usuario.
Nadie lo trata como infraestructura crítica, así que rara vez está en el primer grupo de parcheo y casi nunca está en el inventario del que se ocupa el equipo de seguridad.

Esa combinación —privilegios altos, exposición interna y baja prioridad organizacional— es exactamente el perfil que un atacante busca.

Lo que este caso enseña sobre gestión de parches

La secuencia parche → bypass → segundo parche en cuestión de días desmonta un supuesto operativo común: que aplicar la actualización cierra el tema. Tres implicaciones prácticas:

Parchear no es un evento, es un estado. Si su proceso trata el parche como una tarea que se marca como completada, va a perder el segundo aviso. Necesita un mecanismo que reevalúe los activos afectados cuando el proveedor vuelve a publicar.
Si estuvo expuesto, asuma compromiso hasta probar lo contrario. Con explotación activa confirmada antes del parche, la pregunta correcta no es “¿ya actualicé?” sino “¿qué pasó en ese servidor entre la fecha de explotación conocida y la fecha de mi parche?”. Eso exige logs que existan y se conserven.
El inventario es el control base. Nadie parchea lo que no sabe que tiene. La razón más común por la que una organización queda expuesta semanas después de un aviso no es negligencia: es que ese servidor no estaba en ninguna lista.

El hilo conductor con el cumplimiento

Para una entidad financiera dominicana o latinoamericana sujeta a reglamentación de seguridad cibernética, un incidente de este tipo no termina con la restauración del servicio. Termina cuando se puede documentar la línea de tiempo completa: cuándo se conoció el aviso, qué activos se identificaron como afectados, cuándo se aplicó cada parche, qué se revisó para descartar compromiso y quién aprobó el cierre. Sin ese registro, la respuesta técnica correcta se convierte en un hallazgo de auditoría.

En TEKFENIX trabajamos ese lado del problema. Con Servigo365, cada aviso de seguridad puede convertirse en tickets con responsable, plazo y evidencia adjunta, de modo que “aplicamos el parche” deje de ser una afirmación verbal y pase a ser un rastro verificable. Y con CumplimientoControl, esa trazabilidad se organiza en el formato que un supervisor espera encontrar cuando pregunta qué hizo la institución, y cuándo.

On August 27, 2026, PaperCut disclosed in an urgent security bulletin two zero-day vulnerabilities already being exploited in real attacks: CVE-2026-81578 and CVE-2026-82078. Chained together, they enable remote code execution before authentication.

What Breaks

CVE-2026-82078 is a critical unsafe dynamic class loading issue in the product’s database connection utilities. If an attacker can manipulate system configuration parameters, it enables execution of arbitrary Java bytecode already residing on the application classpath, under the security context of the PaperCut server process itself. Combined with CVE-2026-81578, the full chain enables unauthenticated RCE.

The Uncomfortable Part: The Patch Was Bypassable

The first emergency patch closed the initial access path in the chain. Within roughly 48 hours, PaperCut confirmed the fix could be bypassed and released a second one. The turn came from outside research: watchTowr fully reproduced the vulnerabilities and found multiple ways around the initial patch. Huntress separately reproduced the complete pre-authentication RCE chain and observed exploitation in two customer environments, where attackers appeared to be conducting reconnaissance.

The second fix, Emergency Patch Release 2, is available for PaperCut NG and MF versions 24, 25 and 26 on Windows, Linux and macOS. The vulnerabilities were added to CISA’s KEV catalog.

Why a Print Server Is Such a Good Target

It is tempting to file this as “a printer problem.” It is not. A print management server typically has three properties that make it an ideal pivot point:

It sits on the internal network, with visibility into workstations and sometimes into directory services.
It runs with elevated privileges because it must manage queues, devices and user accounts.
Nobody treats it as critical infrastructure, so it is rarely in the first patching wave and almost never in the inventory the security team watches.

That combination — high privilege, internal exposure and low organizational priority — is exactly the profile an attacker looks for.

What This Case Teaches About Patch Management

The patch → bypass → second patch sequence within days dismantles a common operating assumption: that applying the update closes the matter. Three practical implications:

Patching is a state, not an event. If your process treats a patch as a task to be marked done, you will miss the second advisory. You need a mechanism that re-evaluates affected assets when the vendor publishes again.
If you were exposed, assume compromise until proven otherwise. With exploitation confirmed before the patch, the right question is not “did I update?” but “what happened on that server between the known exploitation date and my patch date?” That requires logs that exist and are retained.
Inventory is the base control. Nobody patches what they don’t know they have. The most common reason an organization is still exposed weeks after an advisory is not negligence: that server was on no list.

The Thread Back to Compliance

For a Dominican or Latin American financial institution subject to cybersecurity regulation, an incident like this does not end when service is restored. It ends when the full timeline can be documented: when the advisory became known, which assets were identified as affected, when each patch was applied, what was reviewed to rule out compromise, and who approved closure. Without that record, a technically correct response becomes an audit finding.

At TEKFENIX we work that side of the problem. With Servigo365, each security advisory can become tickets with an owner, a deadline and attached evidence, so “we applied the patch” stops being a verbal claim and becomes a verifiable trail. And with CumplimientoControl, that traceability is organized in the format a supervisor expects when asking what the institution did, and when.

← Volver al blog← Back to blog