← Volver al blog

Resumen de seguridad, 5 de mayo de 2026: RCE de Weaver, Copy Fail, puerta trasera en PyTorch Lightning y phishing con Amazon SES

El patrón de esta mañana es claro: los atacantes están aprovechando tuberías de confianza. Software de workflow, kernels Linux, dependencias de desarrollo y correo cloud legítimo se volvieron rutas rápidas en cuanto los equipos asumieron que el canal era seguro por sí mismo.

---

---

1. Weaver E-cology demuestra otra vez que los endpoints de depuración acaban siendo puertas reales de intrusión

BleepingComputer informa de que CVE-2026-22679 en Weaver E-cology se explota desde mediados de marzo. Vega describe una RCE no autenticada a través de una API de debug expuesta que permitía que parámetros controlados por el atacante llegaran a funciones RPC backend y a comandos del sistema. La actividad observada incluyó reconocimiento, cargas PowerShell y descargas repetidas de scripts sin archivos.

• Actualiza de inmediato cualquier build de Weaver E-cology 10.0 anterior al fix del 12 de marzo.
• Busca en los servidores afectados actividad de whoami, ipconfig, tasklist, ping y PowerShell lanzada por java.exe.
• Trata los sistemas colaborativos expuestos como puntos de apoyo para movimiento lateral, no solo como plataformas documentales.

---

2. Copy Fail ya saltó de paper técnico a riesgo real de root

CISA añadió CVE-2026-31431, conocida como Copy Fail, a su catálogo KEV un día después de la divulgación pública. El fallo está en la interfaz algif_aead y permite a usuarios locales sin privilegios obtener root escribiendo bytes controlados en la page cache de cualquier archivo legible. Theori afirma que el mismo exploit funcionó de forma fiable en Ubuntu, Amazon Linux, RHEL y SUSE.

• Prioriza actualizaciones de kernel en sistemas Linux expuestos a internet y en servidores multiusuario.
• Considera sospechosa cualquier distribución construida en la ventana vulnerable desde 2017 hasta que esté parcheada.
• No descartes el fallo como una simple escalada local; una vez dentro, root es el premio real.

---

3. PyTorch Lightning 2.6.3 convirtió una dependencia popular de IA en una trampa de secretos al importar

Una versión maliciosa de lightning 2.6.3 en PyPI descargaba Bun automáticamente y ejecutaba una carga JavaScript ofuscada en el momento de la importación. Según el reporte, la carga apuntaba a datos de navegador, archivos .env, claves API, credenciales cloud y permitía ejecución arbitraria de comandos. Con más de 11 millones de descargas mensuales, no hace falta una infección masiva para provocar un problema serio de confianza.

• Elimina de inmediato lightning 2.6.3 y fija una versión conocida como segura.
• Rota tokens, claves API, credenciales cloud y secretos en cualquier sistema que haya importado la versión maliciosa.
• Revisa los pipelines de build por supuestos ciegos sobre dependencias, sobre todo cuando la ejecución en import puede esconderse.

---

4. El phishing con Amazon SES muestra cómo la confianza en la nube neutraliza defensas basadas en reputación

Kaspersky observa un aumento de phishing enviado mediante Amazon SES, a menudo habilitado por claves AWS IAM filtradas en repositorios públicos, archivos .env, backups, imágenes o buckets S3 expuestos. Como los mensajes salen desde infraestructura legítima de SES, pueden superar SPF, DKIM y DMARC y hacer mucho menos eficaces los bloqueos tradicionales.

• Audita claves AWS expuestas y reduce permisos de SES al mínimo necesario.
• Rota claves, fuerza MFA y añade restricciones por IP cuando sea posible para identidades de envío.
• Amplía la detección de phishing más allá de la reputación del remitente y revisa comportamiento, enlaces y patrones inusuales de envío.

---

Qué deben hacer hoy los equipos de seguridad

1. Parchear Weaver E-cology y los kernels Linux vulnerables antes de cualquier trabajo de higiene de menor prioridad.
2. Comprobar inventarios de software y pipelines CI en busca de lightning 2.6.3 y luego rotar cada secreto afectado.
3. Revisar rutas de exposición de AWS IAM y tratar el abuso de SES como un fallo de identidad y gestión de secretos.
4. Alinear a los responders con el tema de hoy: la infraestructura de confianza también debe verificarse, ya sean endpoints de debug, kernels, paquetes o correo cloud.

---

---

Conclusión: El fallo común de hoy es confiar demasiado en canales que parecen legítimos. La respuesta es poco glamourosa pero correcta: parchear rápido, rotar secretos sin debate y verificar cada plataforma de confianza como si ya formara parte de la ruta de ataque.