En pocas palabras: CVE-2026-110285 afecta a WP Stripe Checkout en versiones anteriores a 1.2.2.62: al no verificar la firma del webhook de Stripe en su configuración por defecto, cualquier atacante sin cuenta puede forjar notificaciones y generar pedidos marcados como pagados sin pagar. Ya existe parche disponible.

WPScan reveló CVE-2026-110285, una falla en el plugin WP Stripe Checkout que permite a atacantes sin cuenta ni credenciales falsificar notificaciones de pago y crear pedidos marcados como pagados sin que exista ningún cobro real. Afecta a todas las versiones anteriores a 1.2.2.62.

WP Stripe Checkout es un plugin de WordPress que integra Stripe como método de pago. CVE-2026-110285 es una vulnerabilidad CWE-287 (autenticación insuficiente) que afecta a las versiones previas a 1.2.2.62: el plugin no verifica la firma de los webhooks de Stripe cuando no hay un secreto de firma configurado, que es su estado por defecto de fábrica.

En 30 segundos

  • CVE-2026-110285 afecta a WP Stripe Checkout en todas las versiones anteriores a 1.2.2.62, según el aviso publicado en wpscan.com.
  • El problema es CWE-287: sin signing secret configurado (su estado por defecto), el plugin acepta cualquier webhook como legítimo.
  • Un atacante sin cuenta ni acceso al panel de WordPress puede forjar una notificación de «pago completado».
  • WPScan calificó la severidad como alta; no figura en el catálogo CISA KEV y no hay explotación activa reportada al 25 de octubre de 2026, según Threat Radar.
  • La versión 1.2.2.62 corrige la validación de firma y cierra el agujero.

¿Qué versiones de WP Stripe Checkout están afectadas por CVE-2026-110285?

Todas las versiones anteriores a 1.2.2.62 de WP Stripe Checkout son vulnerables. El aviso, con fecha de publicación 25 de octubre de 2026 y reserva del 13 de octubre, fue coordinado por WPScan como CNA y el hallazgo se le atribuye al investigador Naoki Kawahigashi, según el registro de cve.threatint.com.

El problema está mapeado como CWE-287 (Improper Authentication) y, según el marco OWASP Top 10, cae dentro de la categoría A07:2025 de fallas de autenticación. No es un bug exótico: es el tipo de error que aparece cuando un plugin confía en el formato de una petición en vez de verificar criptográficamente quién la envió.

¿Por qué la falta de secreto de firma permite falsificar pagos?

Sin un signing secret configurado (que es el estado por defecto del plugin), WP Stripe Checkout no verifica que la notificación de pago venga realmente de los servidores de Stripe. Cualquier petición HTTP con el formato esperado por el endpoint del webhook se acepta como legítima, sin chequeo criptográfico de por medio. Ya lo cubrimos antes en nuestra comparación de dos herramientas para detectar fallas en plugins.

Ponele que tenés una tienda chica y nunca tocaste la configuración avanzada del checkout (algo bastante común, la verdad). Si nunca pegaste el whsec_… en los ajustes del plugin, tu tienda queda escuchando en un endpoint abierto que confía en cualquiera que le toque la puerta con el mensaje correcto.

El fallo, según describe el reporte de Threat Radar, está clasificado con «likelihood of exploit: high». Eso no significa que ya lo estén explotando en masa, pero sí que la barrera técnica para hacerlo es baja.

¿Cómo funciona el fraude de pago falso en WP Stripe Checkout?

El atacante envía una petición falsificada al endpoint del webhook simulando un evento de pago completado, sin necesidad de credenciales, cuenta de usuario ni acceso al panel de WordPress. El plugin, al no validar la firma, procesa esa notificación igual que procesaría una real de Stripe.

¿Hace falta explotar alguna otra parte del sitio para que esto funcione? No. Alcanza con conocer la URL del endpoint y el formato del payload que espera el plugin, datos que no son secretos y que cualquiera puede inferir leyendo el código del plugin (que es público en el repositorio de WordPress).

¿Qué riesgo económico implica esta vulnerabilidad de WP Stripe Checkout para una tienda online?

El riesgo es pérdida económica directa: pedidos marcados como pagados sin que haya entrado un peso, lo que puede derivar en entrega de productos físicos, activación de licencias digitales o desbloqueo de contenido sin ninguna contraprestación real. Más contexto en nuestra nota sobre otra vulnerabilidad crítica en WordPress.

Pensalo en cadena: alguien detecta el endpoint abierto, manda la notificación falsa, el sistema marca el pedido como pagado, se dispara el fulfillment automático (mail de confirmación, activación de descarga, envío a depósito) y recién ahí, si alguien se pone a revisar conciliación bancaria contra el dashboard de Stripe, se nota que ese dinero nunca llegó. El impacto, según resume el análisis de Threat Radar, incluye tanto pérdida financiera como «problemas de fulfillment de pedidos» para los comerciantes afectados.

DatoDetalle
ProductoWP Stripe Checkout (plugin WordPress)
Versiones afectadasAnteriores a 1.2.2.62
Versión corregida1.2.2.62
CWECWE-287 (Improper Authentication)
SeveridadAlta (calificada por WPScan como CNA)
Explotación conocidaNo reportada en CISA KEV al 25/10/2026
Fecha de publicación25 de octubre de 2026
wp stripe checkout vulnerabilidad diagrama explicativo

¿Cómo se corrige: alcanza con actualizar a la versión 1.2.2.62?

Sí: actualizar WP Stripe Checkout a la versión 1.2.2.62 o posterior corrige el fallo de validación de firma, según confirma el registro técnico citado en Threat Radar. La actualización se hace desde el panel de plugins de WordPress, sin pasos adicionales.

Eso sí: actualizar no te exime de revisar la configuración del webhook. Es el paso obligatorio, pero no el único que conviene tomar.

¿Cómo configurar correctamente el secreto de firma de webhooks de Stripe?

El secreto de firma (el whsec_… que Stripe genera por cada endpoint de webhook) se configura en dos lugares: en el panel de Stripe, dentro de la sección de webhooks, y en los ajustes del plugin WP Stripe Checkout dentro de WordPress. Sin esa pieza pegada en ambos lados, la verificación de firma queda desactivada aunque ya hayas actualizado.

  • Entrá al dashboard de Stripe y ubicá la sección de Developers > Webhooks.
  • Copiá el signing secret del endpoint que apunta a tu tienda.
  • Pegalo en los ajustes de WP Stripe Checkout, en el campo correspondiente a webhook secret.
  • Guardá y probá con un pago de prueba en modo test de Stripe antes de asumir que quedó bien.

Si administrás varias tiendas en un hosting propio, vale la pena pedirle al equipo de soporte que verifique este punto en cada sitio con checkout de Stripe activo. Proveedores de hosting para WordPress como donweb.com ofrecen soporte técnico al que podés consultar este tipo de dudas de configuración.

¿Cómo detectar si ya existieron pedidos fraudulentos antes del parche?

La forma de detectarlo es cruzar manualmente los pedidos marcados como pagados en tu tienda contra las transacciones reales que aparecen en el panel de Stripe. Si un pedido dice «pagado» en WordPress pero no tiene un cargo correspondiente en Stripe, ese pedido es sospechoso.

Como criterio práctico (propuesta editorial, no algo que la fuente indique), conviene filtrar los pedidos de los últimos meses por estado «completado» o «pagado» y exportar esa lista para compararla línea por línea con el historial de pagos de Stripe. No hace falta software especial, un par de planillas alcanza para empezar a detectar discrepancias. Relacionado: una falla que afecta instalaciones desde hace años.

Errores comunes al manejar esta vulnerabilidad

  • Actualizar y no revisar el secreto de firma: la versión 1.2.2.62 corrige el código, pero si nunca configuraste el whsec_…, conviene confirmar que quedó bien seteado.
  • Asumir que «nadie va a encontrar mi endpoint»: la URL del webhook no es secreta, está en el código público del plugin.
  • No revisar pedidos históricos: actualizar hacia adelante no borra el riesgo de fraudes que ya pasaron antes del parche.
  • Confundir modo test con modo producción de Stripe al probar la corrección, lo que da una falsa sensación de que todo funciona.

Qué está confirmado y qué no sobre CVE-2026-110285

Confirmado: la vulnerabilidad existe en versiones anteriores a 1.2.2.62, está clasificada como CWE-287, WPScan la calificó de severidad alta y la versión 1.2.2.62 la corrige, según los avisos técnicos consultados.

No confirmado: no hay registro público de explotación activa en el momento de publicación de este artículo, ni figura en el catálogo CISA KEV. Tampoco hay un CVSS asignado por NVD todavía, según indica Threat Radar.

Preguntas Frecuentes

¿Qué es CVE-2026-110285?

CVE-2026-110285 es una vulnerabilidad de autenticación insuficiente (CWE-287) en el plugin WP Stripe Checkout para WordPress, que permite falsificar notificaciones de pago cuando no hay un secreto de firma de webhook configurado. Mirá también entender las diferencias entre tipos de escaneo.

¿Qué versiones de WP Stripe Checkout están afectadas?

Todas las versiones anteriores a 1.2.2.62 están afectadas. La versión 1.2.2.62, disponible desde octubre de 2026, incluye la corrección de la validación de firma. Ampliamos el tema en verificar qué versiones ya están parchadas.

¿Necesito estar autenticado para explotar esta falla?

No. El ataque lo puede ejecutar cualquiera sin cuenta ni acceso al panel de WordPress, enviando directamente una petición falsificada al endpoint del webhook. Esto se conecta con lo que analizamos en podés escanear tu sitio en busca de fallas.

¿Cómo sé si mi tienda tuvo pedidos fraudulentos por esta falla?

Comparando manualmente los pedidos marcados como pagados en tu tienda contra las transacciones reales registradas en el panel de Stripe. Cualquier pedido «pagado» sin cargo correspondiente en Stripe es sospechoso.

¿Alcanza con actualizar el plugin para estar protegido?

Actualizar a la versión 1.2.2.62 corrige el código vulnerable, pero conviene además verificar que el secreto de firma de webhook esté configurado tanto en Stripe como en el plugin.

Conclusión

CVE-2026-110285 muestra algo que se repite seguido en plugins de pago para WordPress: una opción de seguridad que debería venir activada por defecto, no lo está. Mientras no haya evidencia de explotación masiva, el riesgo real depende de cuántas tiendas corran versiones viejas sin el signing secret configurado.

Si tenés WP Stripe Checkout instalado, el paso inmediato es actualizar a 1.2.2.62 y confirmar que el whsec_… esté pegado en ambos lados. Después, dedicá media hora a cruzar pedidos recientes contra el dashboard de Stripe. Es la única forma de saber si el fraude ya pasó antes de que vos te enteraras.

Fuentes