El problema no es el editor WYSIWYG. Son el código del lado del cliente. El problema con estos editores es cuando se integran con el servidor para publicar contenido o realizar una carga de imagen.
Gran parte de la mala reputación proviene de cuando se incluyen en un complemento de CMS. Esos se integran con el código base del servidor y no siempre están codificados de forma segura o el exploit se encuentra en un código no relacionado con el editor WYSIWYG. Dado que el ataque al lado del servidor se origina en el editor WYSIWYG, se le echa la culpa a pesar de que el mismo ataque se pudo realizar desde un área de texto o una solicitud POST al script vulnerable.
Tenga en cuenta que pueden proporcionar tutoriales para integrarse con un idioma del lado del servidor. Pero estos son solo ejemplos y no deben usarse como scripts listos para producción. Desafortunadamente la gente toma estos scripts y corre con ellos. Así que, nuevamente, la culpa se pone en el editor WYSIWYG a pesar de que la falla tiene que ser asignada a un desarrollador perezoso.
Los dos editores que mencionaste están bastante bien mantenidos y tampoco puedes equivocarte. Sin embargo, si no está utilizando un complemento de CMS, la codificación segura depende de usted.
Editar: Con la mención de los ataques XSS en el lado del cliente se aplica lo mismo. Su servidor está enviando esos datos al editor WYSIWYG. Espera que lo que envíes sea lo que deseas que se muestre. El saneamiento del código malicioso debe realizarse de su lado antes de que se alimente del lado del cliente.