El formulario de cotización sigue recibiendo mensajes. Entonces llega una alerta de Drupal y aparece una duda incómoda: ¿que la página funcione significa que está protegida? No. La continuidad del servicio y la corrección de una vulnerabilidad son comprobaciones diferentes. En Webform, además, importa tanto la versión instalada como una configuración específica del formulario.
El aviso del 23 de septiembre pide una revisión concreta, no una alarma indiscriminada sobre cualquier sitio hecho con Drupal. Si tu empresa utiliza este módulo, el primer paso útil es encontrar a quien puede identificar su versión, contrastar el alcance y coordinar la corrección. No hace falta intentar reproducir un ataque para tomar esa decisión.
| Qué revisar | Cómo interpretarlo |
|---|---|
| Rama 6.2.x | Actualizar a Webform 6.2.12 conforme al aviso. |
| Rama 6.3.x | Actualizar a Webform 6.3.1 conforme al aviso. |
| Versión o configuración desconocida | Identificar instalación y responsable antes de asumir que el aviso aplica o que ya está resuelto. |
Pensemos en una situación hipotética: una empresa tiene un formulario de cotización que nadie ha modificado en meses. Ventas recibe los mensajes y da por hecho que el sitio está atendido; quien administra el alojamiento supone que los módulos los revisa el desarrollador. Cuando llega una alerta, la dificultad inicial no es instalar nada. Es descubrir quién conoce la instalación y puede hacerse cargo del cambio.
Drupal publicó el aviso SA-CONTRIB-2026-175, correspondiente a CVE-2026-96355, el 23 de septiembre. Afecta a Webform en versiones anteriores a 6.2.12 y desde 6.3.0 hasta antes de 6.3.1. Bajo determinadas configuraciones, datos enviados a un formulario pueden interpretarse como código de plantilla. Las correcciones indicadas son Webform 6.2.12 y 6.3.1, según la rama utilizada. El impacto depende de la configuración del formulario y de otros módulos habilitados.
Publicación de Drupal Security Team · 2026-09-23 (abre en otra pestaña)
Conviene separar tres responsabilidades que a veces se confunden: mantener el servidor, actualizar Drupal y conservar los módulos de la aplicación. Tener contratado alojamiento no prueba que las otras dos estén cubiertas. Una respuesta verificable debe referirse a esta instalación y a esta rama de Webform; un mensaje genérico de «servidor actualizado» deja la pregunta original sin resolver.
El recorrido completo está descrito debajo; con JavaScript también se muestra el diagrama.
{"kind":"decision","title":"Cómo ordenar la revisión de Webform","nodes":[{"label":"¿Se conoce versión y configuración?","decision":true},{"label":"Identificar instalación y responsable"},{"label":"Contrastar con el aviso oficial","decision":true},{"label":"Coordinar corrección de la rama afectada"},{"label":"Documentar por qué no aplica"},{"label":"Comprobar recepción del formulario"}],"edges":[{"from":0,"to":1,"label":"No"},{"from":1,"to":0,"label":"Revisar información"},{"from":0,"to":2,"label":"Sí"},{"from":2,"to":3,"label":"Aplica"},{"from":2,"to":4,"label":"No aplica"},{"from":3,"to":5,"label":"Después del cambio"}]}- ¿Se conoce versión y configuración? → Identificar instalación y responsable: no.
- Identificar instalación y responsable → ¿Se conoce versión y configuración?: revisar información.
- ¿Se conoce versión y configuración? → Contrastar con el aviso oficial: sí.
- Contrastar con el aviso oficial → Coordinar corrección de la rama afectada: aplica.
- Contrastar con el aviso oficial → Documentar por qué no aplica: no aplica.
- Coordinar corrección de la rama afectada → Comprobar recepción del formulario: después del cambio.
Esquema conceptual de Acinsoft para explicar el caso del artículo, no arquitectura de un cliente ni medición.
El problema puede estar debajo de un formulario que sí funciona
Volvamos al ejemplo. El formulario recibe archivos y manda una notificación al área comercial. Para quien lo usa, ambas cosas forman una sola operación; para quien lo mantiene, pueden depender de configuraciones distintas. Por eso una prueba que sólo confirme que la página abre se queda corta. Conviene seguir una solicitud ficticia desde el navegador hasta el punto donde alguien debe atenderla, sin incorporar datos de clientes ni generar una cotización real.
Ese recorrido también ayuda a preparar el cambio. Si hoy nadie sabe dónde se conservan las solicitudes, será difícil reconocer mañana si falta alguna. Registrar el funcionamiento previo no es burocracia: permite comparar y distinguir un problema nuevo de otro que ya existía. El alcance del aviso debe revisarlo quien conoce la instalación; una noticia no sustituye ese diagnóstico.
Antes de intervenir, sería útil que el equipo del ejemplo pudiera distinguir el sitio de producción de una copia de prueba y reconocer qué configuraciones necesita conservar. No son detalles que deba resolver la persona de ventas, pero sí información que alguien tiene que tener disponible. Esa preparación permite que el cambio responda al aviso concreto, en lugar de convertirse en una actualización improvisada de componentes que quizá ni siquiera están relacionados.
Qué debería quedar comprobado
Después, la comprobación puede seguir el mismo recorrido que hace una oportunidad comercial: completar los campos, adjuntar un archivo ficticio si corresponde y confirmar dónde aparece la solicitud. Si el correo de aviso no llega, la versión del módulo puede estar corregida y el trabajo comercial seguir interrumpido. Reconocer ambas cosas evita confundir la solución del problema de seguridad con la validación completa del servicio.
Una señal de cierre más útil que «ya quedó» sería poder responder qué versión se instaló, qué formularios se probaron y quién confirmó la recepción. Si alguna dependencia impide actualizar de inmediato, hace falta una decisión técnica documentada sobre el siguiente paso, no una espera indefinida ni la tranquilidad de que todavía no se ha reportado una falla.
La evidencia del cambio puede ser sencilla: versión anterior y nueva, formularios incluidos en la revisión y resultado de una solicitud ficticia. Su utilidad aparece después, cuando otra persona necesita saber qué se hizo. No guardes datos de clientes para demostrar la prueba ni confundas un registro de mantenimiento con una investigación forense.
Si la alerta deja al descubierto que nadie tiene claro quién mantiene cada componente, esa asignación es un buen punto de partida para conversar con Acinsoft (servicio relacionado; abre en otra pestaña) sobre el soporte tecnológico del sitio. Primero habría que revisar accesos, responsabilidades y alcance; después acordar quién interviene y cómo se comprueba el resultado.
El cierre tiene dos partes: atender la condición señalada por Drupal y confirmar que la solicitud sigue llegando a quien debe responderla. Si hay indicios de acceso indebido, hace falta una investigación separada. Ni un formulario que abre ni una actualización instalada permiten asegurar, por sí solos, que no ocurrió un incidente.
