El formulario de contacto de tu web puede ser la puerta de entrada al servidor

El 19 de agosto se publicó la corrección de una falla en Elementor Pro, el constructor de páginas más usado de WordPress. Permite que cualquiera, desde internet y sin usuario ni contraseña, suba un archivo al servidor de tu sitio y lo ejecute. La puerta de entrada es el formulario de contacto.

La falla se identifica como CVE-2026-32475 y tiene un puntaje de severidad de 9 sobre 10. No es una nota para desarrolladores: si la web de tu empresa está hecha en WordPress —y hay muchas probabilidades de que sí—, esto se revisa esta semana.

Qué pasó, en criollo

Elementor es el plugin con el que se arma visualmente la mayoría de los sitios en WordPress: más de diez millones de instalaciones activas. Su versión paga, Elementor Pro, incluye un widget de formularios que permite que el visitante adjunte un archivo. Un CV, un plano, una foto del producto que quiere cotizar. Nada raro.

Ese formulario revisa lo que le mandan para que nadie suba, por ejemplo, un archivo PHP —que es código que el servidor ejecuta—. El problema es que quien controla el envío y quien lo guarda no leen los datos igual. Un atacante arma un envío con dos partes: la primera vacía y la segunda con el código malicioso. El control mira la primera, la descarta y da el visto bueno. El que guarda mira la segunda y la escribe en una carpeta pública del sitio.

Después solo hace falta abrir esa dirección en el navegador para que el código corra. Y ahí ya no estamos hablando de "hackearon la web": estamos hablando de que alguien tiene una consola dentro del servidor donde vive tu sitio.

¿Te afecta a vos?

La respuesta corta: te afecta si tu sitio corre WordPress con Elementor Pro en una versión anterior a la 4.2.2, y tenés al menos un formulario con campo de carga de archivos.

• Elementor gratuito no está afectado. El widget de formularios es exclusivo de la versión Pro.
• Si tenés Pro pero ningún formulario acepta adjuntos, no sos explotable hoy. Igual actualizá: alcanza con que mañana alguien agregue el campo.
• No hace falta que el atacante tenga cuenta. Ni usuario, ni contraseña, ni un enlace especial. Solo la dirección de tu sitio.

Hasta ahora no se detectaron ataques usando esta falla. Eso no es un consuelo: es un plazo. La corrección ya está publicada, y publicar la corrección es también publicar el mapa. Los escaneos automáticos que barren internet buscando sitios en WordPress sin actualizar no tardan días en incorporar una falla nueva; tardan horas.

Qué hacer, en orden

1. Actualizá Elementor Pro a la versión 4.2.2 o superior. Es lo primero y lo más urgente. Entrá al panel de WordPress, sección Plugins, y fijate qué versión tenés.
2. Revisá la carpeta donde se guardan los adjuntos: wp-content/uploads/elementor/forms/. El parche tapa el agujero, pero no borra lo que ya haya entrado. Si ahí hay algún archivo .php, tenés un problema anterior a la actualización y hay que tratarlo como un incidente, no como un archivo raro.
3. Mirá la lista de usuarios administradores del sitio. Si aparece alguno que nadie reconoce, o uno viejo de un proveedor que ya no trabaja con vos, sacalo.
4. Cambiá las contraseñas del panel de WordPress, del hosting y de la base de datos si tenés alguna sospecha.
5. Confirmá que tenés un backup del sitio y de la base, y que alguna vez se probó restaurarlo. Escribimos sobre por qué esto importa en el backup que nadie probó restaurar.

El problema de fondo: la web también es infraestructura

La falla la reportó un investigador en julio y el fabricante la corrigió al día siguiente. El circuito funcionó. Donde se corta la cadena es después: en la empresa que tiene el sitio y no tiene a nadie a cargo de actualizarlo.

El patrón que vemos una y otra vez es el mismo. La web la armó una agencia o un conocido hace tres o cuatro años. Quedó andando, que era lo que se pedía. Nadie definió quién actualiza los plugins, quién revisa el hosting, quién mira si el certificado vence. Y sobre todo: nadie sabe con exactitud qué plugins tiene instalados el sitio. Veinte, treinta, algunos que ya no se usan y quedaron ahí, desactivados pero presentes —y un plugin desactivado con una falla sigue siendo código en el servidor.

Ese sitio es, para la empresa, la cara pública y muchas veces el canal por donde entran las consultas. Pero técnicamente es un servidor con software que envejece, exactamente igual que el servidor de archivos de la oficina. La diferencia es que este está expuesto a internet las veinticuatro horas.

Lo que hay que dejar escrito

No se trata de que el dueño de la pyme aprenda WordPress. Se trata de que tres preguntas tengan una respuesta con nombre y apellido:

• ¿Quién actualiza el sitio y cada cuánto? Una revisión mensual de núcleo, plugins y temas alcanza para el noventa por ciento de los casos.
• ¿Dónde está alojado y quién tiene los accesos? Si el único que puede entrar al hosting es alguien que ya no trabaja con vos, ese es el hallazgo del día.
• ¿Hay backup del sitio, separado del hosting? Un backup que vive en el mismo servidor que el sitio no es un backup.

Es la misma lógica que aplicamos al parcheo de servidores cuando salió el paquete de actualizaciones de Microsoft de este mes, del que escribimos hace unos días. Cambia el software, no cambia el problema: la corrección casi siempre es gratis y ya está disponible. Lo que falta es que alguien tenga la tarea asignada.

Si tu sitio está en WordPress y no sabés en qué versión están los plugins, esta semana es un buen momento para averiguarlo. Y si al abrir el panel te encontrás con que ni siquiera tenés la contraseña, ahí tenés la respuesta a la primera pregunta.