Control de Acceso Roto en Paytium (Formularios de Pago Mollie y Donaciones) — Lo que Todo Propietario de un Sitio de WordPress Necesita Saber

El 17 de febrero de 2026 se divulgó una vulnerabilidad reportada públicamente que afecta al plugin de WordPress Paytium (formularios de pago Mollie y donaciones). El problema — rastreado como CVE-2023-7291 — es un control de acceso roto (falta de autorización) en un endpoint llamado crear_cuenta_mollie. La vulnerabilidad afecta a las versiones del plugin hasta e incluyendo 4.3.7 y se le asignó una severidad media (CVSS 7.1). El proveedor lanzó una solución en la versión 4.4.

Este informe explica la vulnerabilidad desde los primeros principios, describe los posibles impactos en el mundo real, proporciona pasos de detección y mitigación que los propietarios de sitios y los hosts pueden aplicar de inmediato, y ofrece orientación a nivel de desarrollador para prevenir errores similares. El tono refleja la orientación práctica comúnmente compartida entre los profesionales de seguridad de Hong Kong que manejan integraciones de pago en WordPress.

Datos clave de un vistazo

• Plugin afectado: Paytium — Formularios de Pago Mollie y Donaciones
• Versiones afectadas: ≤ 4.3.7
• Solucionado en: 4.4
• Tipo de vulnerabilidad: Control de Acceso Roto — falta de autorización en crear_cuenta_mollie
• CVE: CVE-2023-7291
• Estado del parche: Solución disponible (actualizar a 4.4+)

Por qué esto es importante

Los plugins de pago interactúan con procesadores financieros y a menudo almacenan credenciales de API, configuraciones de comerciante y flujos de trabajo transaccionales. Una verificación de autorización faltante en una función que puede crear o configurar el conector de pago es de alto riesgo: usuarios de bajo privilegio (o llamadores no autenticados, dependiendo del registro) pueden ser capaces de cambiar la configuración de pago, inyectar credenciales o alterar endpoints de webhook.

Incluso si no se filtran secretos de API directamente, los cambios de configuración no autorizados pueden habilitar fraudes, redirigir fondos, romper flujos de pago, o ser utilizados como un punto de apoyo para un compromiso adicional. Por lo tanto, los errores de control de acceso en los plugins de pago requieren atención urgente.

Lo que significa “falta de autorización en create_mollie_account” (resumen técnico)

A un alto nivel, una “falta de autorización” significa que el código que maneja la crear_cuenta_mollie acción no verifica que el llamador tenga los privilegios esperados (por ejemplo, usando current_user_can('manage_options')) o el nonce/token requerido. En WordPress, esto se manifiesta comúnmente con:

• Controladores AJAX (a través de admin-ajax.php) registrados con add_action('wp_ajax_...') or add_action('wp_ajax_nopriv_...') pero que carecen de comprobaciones de capacidad o nonce.
• Puntos finales de la API REST registrados sin un permiso_callback.
• Controladores de formularios o puntos finales personalizados que asumen que solo los administradores los llamarán.

Cuando falta la autorización, los atacantes pueden llamar a puntos finales que realizan acciones sensibles (crear/actualizar cuentas de pago, almacenar claves API, cambiar configuraciones) sin las comprobaciones adecuadas. La función vulnerable reportada crear_cuenta_mollie parece ser invocable por actores no autorizados porque el complemento no aplicó comprobaciones de capacidad ni verificó los nonces de solicitud, un patrón clásico de control de acceso roto.

Posibles impactos en el mundo real y escenarios de explotación

Dependiendo de la estructura interna del complemento y la configuración del sitio, un atacante que explote esto podría:

• Crear cuentas de pago fraudulentas o inyectar credenciales de procesador controladas por el atacante que desvíen fondos del propietario del sitio.
• Modificar configuraciones de pago (webhooks, URLs de callback) para interceptar o secuestrar notificaciones y transacciones.
• Activar acciones relacionadas con el pago que subviertan la lógica comercial (por ejemplo, marcar pagos como completos, crear reembolsos).
• Agregar una configuración maliciosa persistente que persista en la base de datos a través de actualizaciones.
• Combinar con otras debilidades (permisos de archivo débiles, núcleo/temas/complementos desactualizados) para escalar el acceso o plantar puertas traseras.

Importante: la explotación puede no requerir privilegios de administrador. Si el punto final está registrado para nopriv acceso, las solicitudes no autenticadas pueden tener éxito. Si es invocable por usuarios autenticados de bajo privilegio, un atacante puede necesitar solo registrar una cuenta para explotar la falla.

Explotabilidad: ¿qué tan fácil es?

La explotabilidad es moderada a alta cuando uno o más de los siguientes son ciertos:

• El registro de usuarios está habilitado (los atacantes pueden crear cuentas de suscriptores).
• El punto final está registrado como nopriv (accesible sin autenticación).
• No existen nonce del lado del servidor, capacidad o protecciones CSRF.

Debido a que el nombre de la acción crear_cuenta_mollie es predecible, un atacante puede crear solicitudes POST al controlador expuesto (admin-ajax.php?action=create_mollie_account) o a una ruta REST registrada y observar los resultados. No se necesita acceso a la red especial más allá del HTTP(S) normal.

Acciones inmediatas para los propietarios del sitio (prioridad ordenada)

1. Actualiza el plugin a la versión corregida (4.4 o posterior). Esta es la solución definitiva. Prueba en un entorno de staging cuando sea posible, luego despliega en producción.
2. Si no puedes actualizar de inmediato, aplica medidas de bloqueo temporales. Usa reglas a nivel de servidor (nginx o .htaccess) o implementa una rápida interceptación a nivel de PHP para bloquear llamadas a la acción vulnerable.
3. Rota las claves de API de Mollie y cualquier credencial almacenada si se sospecha de un compromiso. Regenera los tokens de API desde el panel de Mollie y actualiza la configuración del plugin solo después de haber asegurado el endpoint.
4. Audita pagos y registros. Revisa los registros de pagos, webhooks, transacciones recientes y configuraciones del plugin en busca de anomalías o endpoints de webhook recién añadidos.
5. Audita usuarios y roles. Elimina cuentas sospechosas, aplica el principio de menor privilegio y considera deshabilitar el registro público si no es necesario.
6. Realice análisis de malware y verificaciones de integridad de archivos. Busca archivos modificados recientemente, archivos PHP inesperados o código inyectado.
7. Monitorea y bloquea IPs sospechosas. Usa reglas de servidor o firewall para bloquear fuentes abusivas.

Reglas prácticas y ejemplos de código (aplica con cuidado)

Prueba cualquier cambio en staging primero y asegúrate de tener copias de seguridad actuales de los archivos y la base de datos.

1) Bloquea la acción en .htaccess (Apache / mod_rewrite)

# Bloquea las solicitudes que llaman a la acción vulnerable a través de admin-ajax.php

Esto devuelve HTTP 403 para solicitudes coincidentes y es un bloqueo conservador del lado del servidor si el plugin depende de admin-ajax.php?action=create_mollie_account.

2) Regla de Nginx para bloquear la misma solicitud

# Bloquea llamadas directas a admin-ajax.php para la acción vulnerable

Si no puedes editar la configuración de nginx en un hosting gestionado, utiliza mitigaciones alternativas como parches virtuales o reglas WAF proporcionadas por tu proveedor de hosting.

3) Parche virtual — fragmento PHP temporal para deshabilitar el manejo no autenticado

Agrega esto como un plugin de uso obligatorio (wp-content/mu-plugins/) o un pequeño plugin específico del sitio que se ejecute temprano. Ajusta los nombres de los manejadores si el plugin utiliza diferentes llamadas.

<?php;

Notas: ajusta los nombres de los llamados si son diferentes y elimina este código temporal después de actualizar a la versión corregida del plugin.

4) Ejemplo de regla WAF (conceptual)

Si tienes capacidades WAF (alojadas o en el borde), bloquea solicitudes donde:

• La ruta es /wp-admin/admin-ajax.php y el parámetro action=crear_cuenta_mollie.
• O se llama a la ruta específica del endpoint REST.

Lógica de pseudo-firma:

si request.path == "/wp-admin/admin-ajax.php" y param("action") == "create_mollie_account":

Cómo detectar si su sitio fue atacado o explotado

Busque en los registros de acceso HTTP, registros de aplicaciones y auditorías los siguientes indicadores:

• Solicitudes a /wp-admin/admin-ajax.php?action=create_mollie_account o cualquier ruta REST que contenga crear_cuenta_mollie.
• solicitudes POST con cargas útiles o JSON que hagan referencia a crear_cuenta_mollie.
• nuevas cuentas de pago o inesperadas, claves API o puntos finales de webhook en la configuración del plugin.
• Cambios inesperados en la base de datos en las opciones del plugin (wp_options), especialmente actualizaciones recientes.
• POSTs provenientes de cuentas de bajo privilegio o llamadores no autenticados.

Ejemplo de verificaciones en la línea de comandos:

# Busque en los registros de acceso el nombre de la acción"

Si hay llamadas presentes antes de aplicar el parche, asuma posible compromiso hasta que se valide lo contrario.

Lista de verificación de respuesta a incidentes (concisa)

1. Parchear: Actualice Paytium a la versión 4.4 o posterior en todos los entornos.
2. Aislar: Si el abuso continúa, desactive el plugin o restrinja temporalmente el acceso al sitio.
3. Parche virtual: Aplique reglas de bloqueo a nivel de servidor o el fragmento de mu-plugin de PHP hasta que se complete el parcheo.
4. Credenciales: Rote las claves API de Mollie y cualquier otro secreto relacionado con pagos. Restablezca las contraseñas de administrador y rote los tokens de servicio donde sea aplicable.
5. Auditoría: Revise las transacciones, puntos finales de webhook, configuraciones del plugin y opciones de base de datos en busca de cambios sospechosos.
6. Escanear: Realice escaneos completos de integridad de archivos y malware; verifique si hay archivos nuevos, archivos centrales modificados o trabajos cron desconocidos.
7. Restaurar: Si encuentra cambios maliciosos, restaure desde una copia de seguridad conocida y buena tomada antes de la actividad sospechosa.
8. Monitorea: Aumente la monitorización de admin-ajax, llamadas a la API REST, intentos de inicio de sesión y actividad de pago durante varias semanas después de la remediación.
9. Notificar: Si los pagos de los clientes se vieron afectados, notifique a su proveedor de pagos y siga las obligaciones de reporte legales/contractuales.

Orientación para desarrolladores: prevenir esta clase de vulnerabilidad

Los desarrolladores deben asumir que cada acción administrativa requiere autorización explícita del lado del servidor. Salvaguardas prácticas:

• Aplica verificaciones de capacidad con current_user_can() antes de realizar operaciones sensibles.
• Utilice nonces para AJAX y envíos de formularios (check_ajax_referer(), wp_verify_nonce()).
• Para rutas REST, siempre incluya un permiso_callback al llamar registrar_ruta_rest.
• Evite registrar wp_ajax_nopriv_* controladores para tareas administrativas o de configuración.
• Limpie y valide todas las entradas independientemente de la presencia de autorización.
• Siga el principio de menor privilegio: exponga solo la funcionalidad al rol mínimo requerido.

Ejemplo de registro REST con verificación de permiso explícita:

register_rest_route('paytium/v1', '/create_mollie_account', array(;

Lista de verificación de detección y endurecimiento para hosts y agencias

• Mantenga procesos de parcheo rápidos para plugins y proporcione un flujo de trabajo de parcheo virtual estándar para correcciones críticas.
• Despliegue reglas de bloqueo centralizadas o firmas WAF que se puedan aplicar a flotas (por ejemplo, bloquear action=crear_cuenta_mollie).
• Monitorear admin-ajax.php el uso y alertar sobre picos anómalos o puntos finales inesperados.
• Proporcione imágenes de WordPress endurecidas que incluyan MU-plugins para mitigaciones comunes y permitan actualizaciones escalonadas.
• Haga cumplir encabezados de seguridad HTTP estrictos e implemente seguridad de contenido donde sea apropiado.

Preguntas frecuentes (FAQ)

P: Actualicé a 4.4 — ¿todavía necesito hacer algo?

R: Actualizar es la solución principal. Después de actualizar, rote cualquier clave de API de pago si sospecha de una posible violación anterior y verifique la configuración de plugins, cuentas de pago y webhooks en busca de cambios no autorizados.

Q: Mi sitio utiliza caché/CDN — ¿podrían ser almacenadas las explotaciones?

A: La acción vulnerable es típicamente dinámica (POST a admin-ajax.php), por lo que las cachés y CDNs generalmente no sirven respuestas almacenadas. Sin embargo, las reglas de WAF en el borde pueden bloquear solicitudes ofensivas a nivel de CDN; los registros aún necesitan revisión.

Q: No uso Mollie — ¿todavía estoy afectado?

A: Si el plugin Paytium está instalado (incluso si Mollie no está configurado), su sitio está afectado si la versión es ≤ 4.3.7. Actualice o desinstale el plugin.

Q: No tengo usuarios registrados — ¿estoy a salvo?

A: Si el endpoint está expuesto a usuarios no autenticados (nopriv), los atacantes pueden llamarlo sin cuentas. Si no, un atacante puede registrar una cuenta (si el registro está habilitado) y explotar el endpoint. Actualice o bloquee hasta que se solucione.

Medidas de protección generales

Más allá de las mitigaciones inmediatas descritas anteriormente, aplique defensas en capas para reducir el tiempo de exposición y el radio de explosión para futuras vulnerabilidades:

• Asegúrese de actualizaciones oportunas de plugins y un plan de reversión documentado.
• Centralice registros y alertas para la actividad de admin-ajax y REST API.
• Utilice listas de permitidos de IP para endpoints administrativos donde sea práctico.
• Mantenga copias de seguridad regulares y pruebe periódicamente los procedimientos de restauración.
• Eduque a los mantenedores del sitio sobre la importancia de las verificaciones de capacidad y el uso de nonce en el desarrollo de WordPress.

Palabras finales: urgencia y resumen práctico

1. Actualice el plugin a la versión 4.4 o posterior ahora — esta es la solución definitiva.
2. Si no puede actualizar de inmediato, aplique las mitigaciones del servidor/WAF o el fragmento de parche virtual descrito anteriormente.
3. Rote cualquier credencial de pago potencialmente expuesta y audite los registros y configuraciones de pago.
4. Aumente la supervisión y revise las cuentas de usuario, especialmente si el registro está habilitado.

Las integraciones de pago tocan el dinero y la confianza del cliente.

Mantente alerta,
Experto en seguridad de Hong Kong