Las detenciones de TeamPCP, desde dentro

Cinco meses después de las oleadas de marzo, la cascada seguía causando víctimas en npm, PyPI y GitHub Actions. El 26 de agosto de 2026, la Policía Federal Australiana imputó a dos hombres en Perth, en colaboración con el FBI y la Policía de Australia Occidental, tras recibir información de empresas especializadas en la evaluación de amenazas cibernéticas. En esta sesión se repasa todo el proceso y se explica cómo cambia la forma de modelar la confianza en tus propios flujos de trabajo.

Temas clave:

• Cómo funcionó realmente la cascada. Ola tras ola, desde el compromiso de una cuenta de servicio hasta 76 de las 77 etiquetas de versión contaminadas y las publicaciones maliciosas en PyPI, y por qué la carga útil fue la credencial y no el CVE.
• Por qué una rotación incompleta lo explicaba todo. Una brecha de seguridad de febrero de 2026 se corrigió, pero no se completó la rotación. Esa única brecha es lo que hizo posible lo ocurrido en marzo, y es la versión más habitual de este fallo.
• Cómo se traduce en la práctica el concepto de «sigue en funcionamiento». Las vulnerabilidades que se detectaron tras el cierre del ciclo de informes de marzo, y por qué aplicar un parche a un paquete no elimina el riesgo cuando el acceso se realiza a través de tokens robados.
• Una lista de comprobación concreta. Las versiones específicas de los paquetes, las etiquetas de acción y las ventanas de exposición que hay que comprobar, así como qué se debe considerar como comprometido, independientemente de si se ha ejecutado la herramienta.
• Cómo debería redefinirse el perímetro de confianza. Una herramienta de seguridad se encuentra dentro del perímetro de confianza de cada canalización en la que se ejecuta. Son muy pocas las organizaciones que lo plantean así, y este es el caso práctico para cambiar esa situación.

Ponentes:

Ben Kapon

Vicepresidente de Marketing

Jimmy

Analista sénior en KELA