Una confusión entre segundos y milisegundos en el código de throttling dejó tres endpoints de autenticación sin protección efectiva contra ataques automatizados.
Pingvin Share X, plataforma de código abierto para compartir archivos, corrigió en su versión 1.22.0 una vulnerabilidad catalogada como CVE-2026-108163 que permitía a atacantes no autenticados ejecutar ataques de fuerza bruta contra credenciales sin enfrentar limitación de velocidad real. El problema radicaba en una discrepancia de unidades de tiempo: el sistema de throttling esperaba valores en milisegundos pero los desarrolladores los habían especificado en segundos, multiplicando por mil el intervalo entre bloqueos y dejando los endpoints prácticamente sin protección.
La Base de Datos Nacional de Vulnerabilidades de Estados Unidos (NVD) clasificó la falla con severidad media. Aunque no permite ejecución remota de código ni escalada de privilegios directa, su explotación exitosa entrega acceso completo a cuentas de usuario — el activo más valioso en cualquier plataforma de intercambio de archivos donde pueden residir documentos corporativos, credenciales de terceros o información personal sensible.
Tres vectores de ataque contra el mismo mecanismo roto
La vulnerabilidad afectaba específicamente a tres endpoints del sistema de autenticación: /api/auth/signIn para inicio de sesión estándar, /api/auth/signIn/totp para validación de segundo factor mediante códigos temporales, y /api/auth/resetPassword para recuperación de cuentas. En los tres casos, el mecanismo de rate limiting — diseñado para bloquear temporalmente a un atacante después de cierto número de intentos fallidos — interpretaba los valores de tiempo de vida (TTL) como milisegundos cuando habían sido configurados en segundos.
El resultado práctico: si el código especificaba un bloqueo de 60 segundos tras cinco intentos fallidos, el sistema lo aplicaba como 60 milisegundos — una fracción de segundo imperceptible. Un atacante podía enviar miles de combinaciones de usuario y contraseña por minuto sin encontrar resistencia técnica, convirtiendo el throttling en un control meramente decorativo. La misma lógica defectuosa se aplicaba a los códigos TOTP de seis dígitos, que en condiciones normales rotan cada 30 segundos y deberían ser prácticamente imposibles de adivinar por fuerza bruta si el rate limiting funciona.
Investigadores de seguridad que reportaron la falla al proyecto no publicaron código de explotación, pero la naturaleza del error hace que cualquier script básico de fuerza bruta — herramientas disponibles públicamente como Hydra o Medusa — pueda aprovecharla sin modificaciones especiales. La barrera de entrada técnica es mínima: basta conocer un nombre de usuario válido o una dirección de correo registrada en la plataforma.
Por qué un error de tres órdenes de magnitud pasó desapercibido
La confusión entre segundos y milisegundos es un error clásico en desarrollo de software, especialmente en ecosistemas donde diferentes bibliotecas y APIs adoptan convenciones distintas. JavaScript, lenguaje predominante en aplicaciones web modernas, maneja tiempos en milisegundos en funciones nativas como setTimeout, mientras que muchas configuraciones de infraestructura (servidores web, bases de datos) esperan segundos. Pingvin Share X está construido sobre Node.js, donde esta dualidad es particularmente común.
Lo notable del caso no es que el error haya ocurrido — ocurre con frecuencia en proyectos de cualquier tamaño — sino que haya llegado a producción en un componente crítico de seguridad sin detección previa. Los controles de rate limiting son verificables mediante pruebas automatizadas básicas: un test que envíe diez solicitudes consecutivas al endpoint de login y mida si la décima es bloqueada habría revelado la falla en segundos. La ausencia de esa prueba en el pipeline de desarrollo sugiere que el throttling se implementó sin validación funcional específica, confiando en que la configuración declarativa funcionaría según lo esperado.
Proyectos de código abierto con equipos pequeños enfrentan este dilema estructuralmente: la cobertura de pruebas automatizadas requiere tiempo y experiencia que no siempre están disponibles, y los controles de seguridad — que por definición solo se activan en condiciones de ataque — son los más difíciles de validar en desarrollo normal. El resultado es que vulnerabilidades como CVE-2026-108163 permanecen latentes hasta que alguien las busca deliberadamente o un atacante las encuentra en producción.
Exposición en América Latina: instalaciones autoalojadas sin monitoreo centralizado
Pingvin Share X se distribuye como software autoalojado — las organizaciones lo instalan en su propia infraestructura en lugar de usar un servicio en la nube gestionado por el desarrollador. Este modelo es particularmente popular en América Latina entre empresas medianas, instituciones educativas y dependencias gubernamentales que priorizan control sobre sus datos o enfrentan restricciones presupuestarias para servicios comerciales de intercambio de archivos. Según patrones de adopción de plataformas similares, Brasil, México, Argentina y Chile concentran la mayor parte de instalaciones regionales.
La naturaleza autoalojada de la plataforma significa que no existe un punto centralizado desde donde el desarrollador pueda forzar actualizaciones o notificar a administradores sobre parches críticos. Cada instalación opera de forma independiente, y la responsabilidad de monitorear avisos de seguridad y aplicar actualizaciones recae completamente en el equipo local. En organizaciones sin procesos formales de gestión de vulnerabilidades — una realidad común en el segmento de empresas medianas latinoamericanas — las instancias pueden permanecer sin parchear durante meses después de que una corrección esté disponible.
El riesgo se amplifica porque Pingvin Share X suele utilizarse para intercambiar documentos entre equipos internos y colaboradores externos, lo que significa que los endpoints de autenticación están expuestos a internet público por diseño. Un atacante no necesita acceso previo a la red corporativa: puede enumerar instancias vulnerables mediante búsquedas en Shodan o Censys (motores que indexan servicios expuestos en internet) y lanzar ataques de fuerza bruta directamente desde cualquier ubicación. Para organizaciones que reutilizan contraseñas entre sistemas o tienen políticas de complejidad débiles, la explotación exitosa de CVE-2026-108163 puede convertirse en el punto de entrada a infraestructura más crítica.
Nuestro análisis
CVE-2026-108163 pertenece a una categoría de vulnerabilidades que no requieren sofisticación técnica para explotar pero que entregan impacto desproporcionado cuando se combinan con debilidades organizacionales comunes. La falla en sí es trivial — un error de unidades que cualquier desarrollador senior habría detectado en revisión de código — pero su ubicación en el mecanismo de rate limiting la convierte en un multiplicador de riesgo para todas las demás debilidades de autenticación: contraseñas débiles, reutilización de credenciales, ausencia de autenticación multifactor obligatoria.
El patrón se repite en proyectos de código abierto con recursos limitados: los controles de seguridad se implementan siguiendo documentación o ejemplos de terceros, pero sin validación funcional rigurosa que confirme que operan según lo esperado bajo condiciones adversas. El throttling es particularmente vulnerable a este problema porque su comportamiento correcto — bloquear solicitudes después de cierto umbral — solo se manifiesta cuando alguien intenta deliberadamente exceder ese umbral, algo que no ocurre en uso normal ni en pruebas básicas de funcionalidad. Sin un test automatizado que simule un ataque de fuerza bruta, el control puede estar roto durante meses sin que nadie lo note.
Para instalaciones en América Latina, la pregunta crítica no es si la vulnerabilidad existió — ya fue corregida en la versión 1.22.0 — sino cuántas instancias permanecen sin actualizar y cuánto tiempo transcurrirá antes de que sus administradores se enteren de que necesitan parchear. En ausencia de un mecanismo de notificación centralizado, la velocidad de adopción de parches de seguridad en software autoalojado depende casi exclusivamente de la madurez de los procesos internos de cada organización. ¿Cuántas de esas instancias tienen alguien monitoreando activamente los avisos de seguridad del proyecto, y cuántas descubrirán la vulnerabilidad solo cuando aparezca un acceso no autorizado en sus logs?