Rustls 0.23.45 corrige un fallo de TLS 1.3 desde 2024

Rustls 0.23.45 salió el 14 de septiembre de 2026 con la corrección de un fallo del saludo TLS 1.3 que llevaba unos dos años en código publicado. Están afectadas todas las versiones de 0.23.13 a 0.23.44. Quien dependa de Rustls debería comprobar a qué versión resuelve realmente su compilación. Phoronix informó de la publicación, y el proyecto registró los detalles como el aviso GHSA-2mjx-qc3c-rqvc.

Rustls es una biblioteca TLS escrita en Rust. TLS es el protocolo que hay detrás de HTTPS, y una biblioteca TLS es lo que su programa usa para establecer una conexión cifrada. Rustls es una elección habitual en servicios en Rust que quieren evitar OpenSSL.

Qué permite realmente el fallo

A mitad de un saludo TLS 1.3, ambas partes cambian de claves. Los mensajes enviados después de ese cambio deben ir cifrados con la clave nueva. Rustls no siempre lo exigía.

El aviso concreta la condición. Rustls aceptaba mensajes de saludo enviados en el nivel de cifrado equivocado cuando seguían a un mensaje que cambiaba las claves dentro del mismo registro. Un registro es el bloque que el protocolo pone de verdad en la red, así que varios mensajes de saludo pueden viajar juntos.

Leído con honestidad, el alcance es más estrecho de lo que parece al principio. "La transcripción del saludo sigue autenticada", dice el anuncio. Un atacante en posición de red no puede usar esto para alterar un saludo ni completar uno que no debería. El efecto práctico es que un par podía enviar en claro algo que el protocolo exige cifrado, y Rustls no rechazaba la conexión.

Así que es un fallo de rigor, no una comprobación de autenticación rota. Aun así importa. Una biblioteca que acepta mensajes prohibidos por la especificación se desvía del RFC 8446, y de esas desviaciones salen los fallos de interoperabilidad y los ataques posteriores.

La seguridad de memoria nunca fue todo el trabajo

Phoronix saca la conclusión útil, y conviene decirla con claridad. Rustls existe en parte porque el código TLS sin seguridad de memoria tiene una larga historia de fallos graves, y Rust elimina esa clase de defecto. Este fallo no es de esa clase.

Nada en Rust evita que una máquina de estados de protocolo acepte un mensaje que debería haber rechazado. Eso es un error de lógica, y los errores de lógica sobreviven a cualquier elección de lenguaje. Una reescritura en un lenguaje seguro le libra de desbordamientos de búfer y de usos después de liberar, no de leer mal una especificación.

Este sitio ha señalado lo mismo desde el otro lado: un paquete de Rust fue el vehículo de un ataque a la cadena de suministro en tiempo de compilación contra arrayref. El lenguaje es una capa de defensa, y solo una.

Qué versiones comprobar

Versión	Estado
0.23.13 a 0.23.44	Afectada
0.23.45	Corregida
Anterior a 0.23.13	Previa al cambio que introdujo el fallo, según el aviso

El fallo se introdujo en septiembre de 2024, y por eso el rango afectado empieza en 0.23.13 y no al principio. El problema también se sigue como GO-2026-4340.

Qué significa esto para los desarrolladores

Actualice y después averigüe qué estaba ejecutando en realidad. Son dos tareas distintas, y la segunda es la que se salta.

Ejecute cargo update -p rustls y confirme que llega a 0.23.45 o posterior. Ejecute luego cargo tree -i rustls para ver qué lo trajo. Rustls suele ser una dependencia indirecta, que llega a través de un cliente HTTP o de un marco de servidor. La versión que obtiene la deciden los rangos que permiten esos paquetes. Una fijación transitiva en una biblioteca que usted no controla es el motivo habitual de que una actualización parezca no hacer nada.

Si publica un binario y no un servicio, compruebe el archivo de bloqueo desde el que compiló de verdad, no el que hay hoy en su máquina. Conectar cargo audit a la integración continua vale la pena tanto si este fallo le afecta como si no, y señalará el aviso en cuanto su base de datos lo incluya.

Aun así, no dedique la tarde a respuesta a incidentes por esto. En ninguna de las dos fuentes hay indicios de explotación, y el propio aviso dice que la transcripción sigue autenticada, lo que descarta la lectura más alarmante. Trátelo como una subida de dependencia normal con un plazo real, no como una emergencia.

La lección más amplia es cuánto puede vivir un fallo de protocolo silencioso. Este estuvo dos años en versiones publicadas, en una biblioteca elegida precisamente por sus propiedades de seguridad, y lo encontró una revisión y no un incidente. Eso es el sistema funcionando. Y también recuerda que "escrito en Rust" es una afirmación sobre una categoría de fallo, y sobre nada más.