En pocas palabras: CVE-2026-109218 (CVSS 9.8) afecta al plugin kleor Contact Manager hasta la versión 9.1.2 y permite a atacantes no autenticados subir archivos ejecutables mediante un nombre con punto final que evade la lista negra de extensiones, logrando ejecución remota de código en servidores Apache con libapache2-mod-php. Reportado por Wordfence el 28 de octubre de 2026.

Un bug en la función add_message del plugin kleor Contact Manager para WordPress permite subir archivos ejecutables sin autenticarse. Se registró como CVE-2026-109218, con CVSS 9.8, y afecta a todas las versiones hasta la 9.1.2 inclusive. El fallo lo reportó Wordfence el 28 de octubre de 2026.

La vulnerabilidad de Contact Manager para WordPress es una subida de archivos sin restricción (CWE-434) en el plugin kleor Contact Manager, usado para gestionar formularios de contacto. Permite a un atacante no autenticado subir archivos con extensiones peligrosas aprovechando un punto final en el nombre, lo que puede terminar en ejecución remota de código si el servidor usa Apache con libapache2-mod-php.

En 30 segundos

  • CVE-2026-109218 tiene CVSS 9.8 (crítico) y afecta a kleor Contact Manager hasta la versión 9.1.2.
  • El bypass usa un nombre de archivo con punto final para evadir la lista negra de extensiones.
  • La RCE solo se concreta en servidores Apache con libapache2-mod-php, que mapea .phar a PHP.
  • Según Threat Radar de OffSeq, al 28/10/2026 no hay explotación confirmada en CISA KEV ni tráfico de ataque registrado.
  • No hay versión parcheada identificada en las fuentes más allá de un changeset hacia 9.1.3.

¿Cómo funciona el bypass de la lista negra con un punto final en el nombre del archivo?

El bypass funciona porque la función de extracción de extensión del plugin devuelve un string vacío cuando el nombre de archivo termina en punto, y WordPress borra ese punto antes de guardar el archivo.

Ejemplo hipotético (no un caso documentado, es solo para entender el mecanismo): supongamos que alguien sube un archivo llamado «shell.phar.». La rutina de add_message intenta sacar la extensión después del último punto, pero como no hay nada después (el punto es el último carácter), el resultado es un string vacío. La lista negra de extensiones peligrosas compara contra ese string vacío, no contra «.phar», así que nunca detecta nada sospechoso. Después, sanitize_file_name() de WordPress limpia el nombre y elimina el punto final de forma silenciosa, dejando el archivo guardado como «shell.phar» con la extensión intacta.

Es un caso de libro de CWE-434: subida de archivo con tipo peligroso sin restricción real, porque la validación ocurre en el momento equivocado del pipeline —compara antes de que el nombre termine de normalizarse. ¿Dónde está el código exacto? En el archivo add-message.php de la versión 9.1.2, según documentó Strix.ai al analizar el CVE. Más contexto sobre fallas de este tipo en otra vulnerabilidad crítica con score 9.8.

¿Qué versiones de kleor Contact Manager están afectadas y qué tan grave es el CVSS 9.8?

Todas las versiones de Contact Manager hasta la 9.1.2 inclusive están afectadas, sin versión parcheada confirmada en las fuentes disponibles. El vector CVSS completo es AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, y cada letra importa acá.

Atacable por red (AV:N), complejidad baja (AC:L), sin privilegios (PR:N), sin interacción del usuario (UI:N). Impacto total en confidencialidad, integridad y disponibilidad. No hace falta que nadie haga clic en nada ni que el atacante tenga cuenta en el sitio.

¿Por qué 9.8 y no 10? Porque el scope queda «Unchanged» (S:U), es decir, el daño se limita al componente vulnerable sin escalar formalmente fuera de su dominio de seguridad, aunque en la práctica comprometer el servidor web ya es bastante.

Métrica CVSS 3.1ValorQué significa
Attack VectorNetworkExplotable de forma remota, sin acceso físico ni local
Attack ComplexityLowNo requiere condiciones especiales, es repetible
Privileges RequiredNoneEl atacante no necesita cuenta ni login
User InteractionNoneNo depende de que alguien haga clic o abra algo
Confidentiality/Integrity/AvailabilityHigh/High/HighCompromiso total si se da la RCE
vulnerabilidad contact manager wordpress diagrama explicativo

¿Qué condiciones del servidor son necesarias para que esto termine en ejecución remota de código?

La RCE requiere específicamente un servidor Apache con libapache2-mod-php, que es el módulo que mapea la extensión .phar a PHP por defecto. Si tu stack es Nginx con PHP-FPM, por ejemplo, el archivo .phar subido no se ejecuta como script aunque esté ahí.

Pero ojo, hay una segunda condición que complica las cosas para el atacante: tiene que acceder al archivo subido antes de que unlink() lo borre al final del request. Es una ventana de tiempo corta, no instantánea, pero tampoco cómoda. Subís el archivo, el servidor procesa el mensaje de contacto, y en algún punto de ese ciclo el atacante necesita hacer una segunda request para ejecutar el .phar antes de que el proceso de limpieza lo elimine.

¿Cómo saber rápido si tu sitio queda del lado riesgoso? Si administrás el hosting vos mismo, revisá qué módulo PHP corre tu Apache (prefork con mod_php vs. FPM). Si no lo sabés con certeza, preguntale directamente a tu proveedor de hosting qué combinación usa el servidor donde está tu WordPress; es un dato que cualquier soporte técnico serio te puede confirmar sin vueltas.

Esto no significa que sitios fuera de esa combinación exacta estén «a salvo»: la subida de archivos arbitrarios sin restricción ya es, por sí misma, un problema de integridad, incluso sin que se llegue a la ejecución inmediata.

¿Esta vulnerabilidad ya fue explotada en ataques reales?

No hay evidencia pública de explotación activa al 28 de octubre de 2026. Según Threat Radar de OffSeq, el CVE no figura en el catálogo CISA KEV, no existe módulo público en Metasploit ni en Exploit-DB, y tampoco hay plantilla nuclei indexada.

Los sensores honeypot de OffSeq Mirage tampoco registraron tráfico de ataque dirigido a este CVE. Eso sí: ausencia de evidencia no es evidencia de ausencia. El CVE se publicó el 28/10/2026, un día antes de esta nota, así que el panorama puede cambiar rápido una vez que algún investigador publique una prueba de concepto funcional.

¿Vale la pena preocuparse ya? Sí, por el CVSS y por lo trivial que es el bypass técnico. La explotación en masa de este tipo de CVE suele acelerarse apenas aparece el primer PoC público.

Criterios para decidir si esto es urgente en tu caso

No todos los sitios con Contact Manager instalado están en el mismo nivel de riesgo. Antes de entrar en pánico (o de ignorarlo), conviene ubicarse en uno de estos escenarios:

  • Usás Contact Manager ≤9.1.2 Y tu hosting corre Apache con mod_php: prioridad alta. Las dos condiciones de la RCE están dadas, así que conviene aplicar mitigaciones hoy mismo, no la semana que viene.
  • Usás el plugin pero no sabés con certeza qué stack corre tu servidor: prioridad media-alta. Resolvé primero esa duda con tu hosting antes de decidir qué tan rápido actuar; no vale asumir que «seguro es Nginx».
  • Usás el plugin pero confirmaste que corrés Nginx con PHP-FPM: prioridad media. El .phar subido no se ejecutaría como script en ese escenario, pero la subida arbitraria de archivos sigue siendo un problema de integridad que conviene cerrar.
  • No usás Contact Manager: este CVE puntual no te afecta, pero el patrón (lista negra de extensiones mal ordenada frente a la normalización del nombre) es común a otros plugins de formularios y uploads, vale la pena tenerlo en mente al auditar otros componentes.

¿Cómo actualizo o mitigo Contact Manager mientras no hay parche confirmado?

Lo primero es revisar si tu versión instalada es 9.1.2 o anterior, y si usás Apache con libapache2-mod-php en el hosting. Las fuentes documentan un changeset hacia la versión 9.1.3, pero no confirman si ese cambio corrige puntualmente este bypass.

  • Actualizá a la última versión disponible del plugin y comparala contra el changeset de WordPress.org antes de asumir que estás parcheado.
  • Validá extensiones de forma estricta, incluyendo el manejo explícito de puntos finales en el nombre del archivo, en vez de confiar en listas negras simples.
  • Generá nombres de archivo únicos en el servidor en lugar de usar el nombre que manda el usuario, así se elimina el vector de entrada externo.
  • Guardá los uploads fuera del document root cuando sea posible, para que ni ejecutándose como PHP lleguen a correr en el contexto web.
  • Restringí el mapeo de extensiones peligrosas en Apache si administrás el servidor, para que .phar y extensiones similares no se interpreten como PHP.

Si administrás el hosting vos mismo, estos cinco puntos los podés aplicar sin depender de que el plugin publique un parche específico. Si no administrás el servidor, el paso mínimo es consultarle a quien sí lo hace qué combinación de Apache/PHP corre, porque esa sola respuesta ya te dice en qué escalón de riesgo estás parado según los criterios de arriba.

Qué está confirmado y qué no

Confirmado: el CVE existe, tiene CVSS 9.8, afecta a Contact Manager hasta 9.1.2, y el mecanismo del bypass (punto final + sanitize_file_name) está documentado en el código fuente del plugin según Wordfence y Strix.ai. Tema relacionado: escanear tu sitio con WPScan.

No confirmado: si la versión 9.1.3 corrige específicamente este bug, si hay explotación activa fuera de lo que detectan los sensores de OffSeq, y qué porcentaje de instalaciones de Contact Manager corre sobre Apache con libapache2-mod-php.

Errores comunes al evaluar este tipo de vulnerabilidad

  • Asumir que «no hay exploit público» significa «no hay riesgo». El CVSS 9.8 describe el peor caso posible, y la facilidad del bypass hace que un PoC pueda aparecer en cualquier momento.
  • Confundir «subida de archivo» con «ejecución garantizada». Si tu stack no usa Apache con mod_php, el impacto baja, pero la subida arbitraria de archivos sigue siendo un problema de integridad por sí sola.
  • Actualizar el plugin sin confirmar que el changeset toca el bug específico. El changeset a 9.1.3 existe, pero nada en las fuentes dice explícitamente que ese parche cierra el bypass del punto final.

Preguntas Frecuentes

¿Qué es CVE-2026-109218?

Es una vulnerabilidad crítica de subida de archivos sin restricción (CWE-434) en el plugin kleor Contact Manager para WordPress, con CVSS 9.8. Permite a un atacante no autenticado subir archivos con extensiones peligrosas explotando un bypass en la lista negra de extensiones de la función add_message. Lo complementamos en las diferencias entre escaneo interno y externo.

¿Qué versiones de Contact Manager están afectadas por esta vulnerabilidad?

Todas las versiones hasta la 9.1.2 inclusive, según el advisory de Wordfence. No hay confirmación en las fuentes de que la versión 9.1.3 resuelva específicamente este bypass. Ampliamos el tema en verificar qué versiones quedan sin parchear.

¿Cómo se explota el bypass del punto final en nombres de archivo en WordPress?

Subiendo un archivo con nombre terminado en punto (ver el ejemplo hipotético más arriba), que hace que la función de extracción de extensión devuelva un string vacío. La lista negra nunca detecta la extensión peligrosa porque compara contra ese valor vacío, y sanitize_file_name() de WordPress borra el punto final antes de guardar el archivo en disco.

¿Esta vulnerabilidad ya fue explotada en ataques reales?

No hay evidencia pública de explotación activa al 28 de octubre de 2026, según Threat Radar de OffSeq. El CVE no está en CISA KEV, no hay módulo en Metasploit ni Exploit-DB, y los sensores honeypot de OffSeq Mirage no registraron tráfico de ataque.

¿Cómo actualizo o mitigo Contact Manager si uso este plugin?

Actualizá a la última versión disponible y verificá el changeset de WordPress.org, validá extensiones de forma estricta incluyendo puntos finales, y considerá guardar los uploads fuera del document root. Si administrás el servidor, restringí el mapeo de extensiones peligrosas en Apache. Usá los criterios de prioridad de la sección anterior para decidir qué tan rápido moverte.

Conclusión

CVE-2026-109218 muestra algo que se repite en plugins de WordPress: la validación de extensiones mal ordenada en el pipeline de procesamiento abre huecos que parecen chicos pero no lo son. Un punto final en un nombre de archivo no debería ser suficiente para esquivar una lista negra, y sin embargo acá lo es.

Si administrás un sitio con Contact Manager, el paso concreto es chequear la versión instalada, confirmar el stack del servidor (Apache con mod_php sube el riesgo real) y ubicarte en alguno de los escenarios de prioridad descritos arriba para decidir qué tan rápido aplicar las mitigaciones de nombre de archivo único y almacenamiento fuera del document root mientras no haya un parche confirmado contra este bypass específico. No hay explotación reportada todavía, pero el margen entre «CVE publicado» y «primer ataque masivo» suele ser corto.

Fuentes