cPanel parchó la falla crítica el 28 de abril. Meses después, seguían cayendo servidores por "Sorry": el problema nunca fue el ransomware

Vale la pena repasar la cronología completa de CVE-2026-41940, porque es la que desmiente la excusa favorita de cualquier administrador de servidores cuando algo sale mal: "nos tomaron por sorpresa". Los primeros intentos de explotación de esta falla en cPanel y WHM empezaron a detectarse desde finales de febrero de 2026. cPanel publicó el parche oficial el 28 de abril — dos meses después, cuando ya era públicamente sabido que la vulnerabilidad se estaba usando activamente. Y aun así, semanas más tarde, Shadowserver reportó al menos 44.000 direcciones IP con cPanel comprometidas por el ransomware "Sorry", que cifra archivos con ChaCha20 y deja notas de rescate en cada carpeta. El parche existía. La vulnerabilidad era de conocimiento público. Y decenas de miles de servidores lo pagaron de todas formas.

Esto no es una historia sobre lo sofisticados que se han vuelto los atacantes. Es una historia sobre lo predecible que sigue siendo la ventana entre "existe un parche" y "lo aplico" en la mayoría de los servidores del mundo. Cuando una vulnerabilidad crítica en un software tan extendido como cPanel se hace pública, no hace falta ser un atacante brillante para aprovecharla — hace falta escanear internet buscando versiones sin actualizar, algo que cualquier script automatizado hace en horas, no en semanas. La pregunta que cualquier administrador debería hacerse no es "¿soy un objetivo interesante para un atacante?" — es "¿cuánto tiempo tarda mi servidor entre que sale un parche crítico y yo lo aplico?". Si la respuesta es "cuando tenga tiempo" o "el próximo fin de semana", la respuesta correcta es que ya perdiste esa carrera antes de empezarla.

La parte incómoda de esto es que actualizar no es glamoroso ni se siente como "hacer seguridad". Configurar un firewall se siente como una decisión activa. Instalar un WAF se siente como una inversión. Aplicar una actualización de seguridad se siente como una tarea administrativa aburrida que se puede posponer un día más sin que pase nada — hasta que ese "un día más" se convierte en dos meses y apareces en la lista de Shadowserver. La mayoría de las brechas que se vuelven noticia no explotan agujeros desconocidos y misteriosos. Explotan software que alguien no actualizó a tiempo, exactamente como pasó aquí.

Si administras servidores con cPanel —los tuyos o los de tus clientes— la lección de este caso no es "revisa las actualizaciones de vez en cuando". Es que las actualizaciones de seguridad críticas necesitan un proceso que no dependa de que alguien se acuerde: notificaciones automáticas de CVE críticos para el software que corres, una ventana de mantenimiento definida de antemano para aplicar parches urgentes en menos de 48 horas (no "cuando haya tiempo"), y —si tu volumen de servidores lo justifica— actualizaciones automáticas para parches de seguridad, dejando solo las actualizaciones mayores para revisión manual. Nada de esto es sofisticado ni caro. Es exactamente el tipo de disciplina aburrida que nunca sale en un caso de estudio de ciberseguridad hasta que falla, y entonces sale en todos.

44.000 servidores no cayeron porque el ransomware Sorry fuera especialmente ingenioso. Cayeron porque, entre el parche disponible y el ataque real, hubo semanas de margen que nadie usó. La próxima vulnerabilidad crítica en tu stack ya tiene esa misma ventana esperando — la única variable que controlas de verdad es qué tan rápido la cierras.