La mayoría de los fallos de inyección de correo cubiertos aquí empiezan en un rincón estrecho de internet: un plugin de WordPress, una librería de Java. CVE-2026-50659 no. Está dentro de System.Net.Mail, el cliente SMTP incorporado en cada versión de .NET durante las últimas dos décadas, todavía conectado a incontables formularios de contacto, sistemas de tickets y servicios de notificación que no tienen ningún motivo para ser reescritos.
Qué es realmente CVE-2026-50659
Revelado como parte de las actualizaciones de seguridad de .NET de julio de 2026, CVE-2026-50659 es una vulnerabilidad de suplantación en la implementación de SmtpClient incluida en System.Net.Mail. Afecta a .NET 8.0.0 hasta 8.0.28, .NET 9.0.0 hasta 9.0.17 y .NET 10.0.0 hasta 10.0.9, además de la línea .NET 6.0, que llegó al fin de su vida útil y no recibirá corrección. Las versiones parcheadas son 8.0.29, 9.0.18 y 10.0.10. Microsoft lo califica con CVSS 6.5, severidad media, y lo clasifica como CWE-116, codificación o escape incorrecto de la salida.
Microsoft lleva años diciéndoles a los desarrolladores que System.Net.Mail no se recomienda para proyectos nuevos. Esa recomendación no hizo nada por retirarlo de producción. Sigue siendo una de las formas más comunes en que una aplicación .NET envía correo, precisamente porque funciona, viene incluido de fábrica y nadie destina tiempo a reemplazar código que ya funciona.
Cómo un error de duplicación de puntos se convierte en un error de contrabando de correo
SMTP marca el final del cuerpo de un mensaje con una línea que contiene un único punto. Para evitar que una línea legítima que empieza con un punto se confunda con ese marcador de fin, el protocolo exige la duplicación de puntos: cualquier línea del cuerpo del mensaje que empiece con un punto recibe un punto adicional al principio antes de transmitirse, y se elimina de nuevo al recibirse.
El codificador de SmtpClient rastrea en qué punto de la línea actual se encuentra para saber cuándo aplicar esa duplicación. El fallo está en cómo maneja el contenido entregado en más de una llamada de escritura. Cuando un retorno de carro termina una escritura y el salto de línea correspondiente llega al inicio de la siguiente, el codificador no logra trasladar correctamente su seguimiento de posición de línea a través de ese límite. Una línea que empieza con un punto justo después de una división así no queda duplicada.
Una aplicación que construye un mensaje saliente a partir de texto influenciado por un atacante, el cuerpo de un ticket de soporte, un campo de “mensaje” en un formulario de contacto, un comentario reenviado por correo, y lo escribe al flujo SMTP en más de una llamada, puede ser inducida a colocar precisamente ese tipo de división en un punto que el atacante controla. El resultado es que una línea con un solo . llega al servidor como un marcador real de fin de mensaje en medio de lo que debía ser un único correo. Todo lo que el atacante suministró después de ese punto deja de ser contenido del mensaje. Se convierte en un nuevo conjunto de comandos SMTP, incluyendo un segundo MAIL FROM, RCPT TO y bloque DATA, colado en la misma sesión que un mensaje que la aplicación nunca tuvo intención de enviar.
Dónde encaja DMARC en esta cadena
Este es el detalle que más importa para quien administra una política de autenticación. El mensaje colado no se envía falsificando encabezados en una conexión separada. Viaja por la misma sesión SMTP saliente que la aplicación vulnerable ya había abierto, hacia el mismo relé que la aplicación ya está autorizada a usar, ya sea un servidor Exchange interno, Amazon SES, SendGrid o cualquier otro proveedor al que la app se autentique normalmente.
SPF verifica la IP de conexión contra el dominio del remitente del sobre. DKIM verifica una firma criptográfica aplicada por la infraestructura emisora. DMARC verifica que ambas coincidan. Ninguna de esas verificaciones mira dentro de la sesión SMTP para preguntar si en secreto contiene dos mensajes en lugar de uno. Si el relé firma y reenvía el mensaje colado de la misma manera que firma y reenvía el legítimo, porque desde el punto de vista del relé no hay diferencia visible, el mensaje colado pasa SPF, DKIM y DMARC sin problema. No al vencerlos. Sino al nunca entrar en su campo de visión como otra cosa que no sea correo saliente ordinario y autorizado.
Es el mismo patrón detrás de los fallos de inyección de Netty y de plugins de WordPress cubiertos aquí antes, ahora un nivel más arriba, dentro del framework del que dependen silenciosamente millones de aplicaciones .NET empresariales para enviar correo en nombre de su organización.
Qué significa esto para tu programa
Parchea primero, esta es una actualización directa. Migra a .NET 8.0.29, 9.0.18 o 10.0.10, o a las versiones de SDK correspondientes. Si mantienes un despliegue autocontenido, debe recompilarse y redesplegarse contra el runtime parcheado; actualizar solo el runtime compartido no lo tocará.
Audita cada lugar donde tus aplicaciones construyen correos a partir de entrada de usuario. Los formularios de contacto, portales de soporte, sistemas de invitación y cualquier cosa que reenvíe por correo texto enviado por usuarios son las aplicaciones que importan aquí. Confirma que el cuerpo del mensaje se escribe al flujo SMTP de una manera que tu librería maneja de forma segura, y trata cualquier código que siga en .NET 6.0 como algo que necesita un plan de migración, no solo la espera de un parche que no va a llegar.
No esperes que el monitoreo de DMARC detecte esto por sí solo. Un mensaje colado enviado a través de tu propio relé autenticado se ve, en tus reportes agregados de DMARC, idéntico a un mensaje que sí querías enviar. Detectar este abuso depende de atraparlo en la capa de la aplicación, mediante validación de entrada y actualización de librerías, no mediante tus reportes de autenticación.
Trata el código de correo “antiguo pero funcional” como superficie de ataque, no como infraestructura resuelta. System.Net.Mail lleva mucho tiempo marcado como no recomendado para proyectos nuevos. Esta vulnerabilidad es un recordatorio de que el código que ya corre en producción es exactamente donde un fallo así hace más daño, porque es el código que nadie está mirando.
La conclusión
CVE-2026-50659 no es un fallo de SPF, DKIM ni DMARC. Es un recordatorio de que los protocolos de autenticación protegen la relación entre un dominio y su infraestructura de envío autorizada, no la integridad de lo que se le pide a esa infraestructura que envíe. Un solo salto de línea mal manejado en un cliente SMTP de dos décadas de antigüedad bastó para que texto suministrado por un atacante se convirtiera en un segundo correo, completamente autenticado, saliendo por la puerta principal que tu propia aplicación ya tenía abierta.
Excello Mail te da visibilidad continua sobre tus reportes DMARC, para que sepas siempre qué infraestructura se está autenticando bajo tu dominio, incluso cuando las aplicaciones que envían ese correo cargan vulnerabilidades que la autenticación por sí sola nunca fue diseñada para detectar. Regístrate gratis en Excello Mail y respalda con monitoreo real la capa de autenticación que sí controlas.