Broken Access Control in Paytium (Mollie Payment Forms & Donations) — What Every WordPress Site Owner Needs to Know

On 17 February 2026 a publicly reported vulnerability affecting the Paytium WordPress plugin (Mollie payment forms & donations) was disclosed. The issue — tracked as CVE-2023-7291 — is a broken access control (missing authorization) in an endpoint named create_mollie_account. The vulnerability affects plugin versions up to and including 4.3.7 and was assigned a medium severity (CVSS 7.1). The vendor released a fix in version 4.4.

This write-up explains the vulnerability from first principles, describes likely real-world impacts, provides detection and mitigation steps site owners and hosts can apply immediately, and gives developer-level guidance to prevent similar mistakes. The tone reflects practical guidance commonly shared among Hong Kong security practitioners who handle WordPress payment integrations.

Key facts at a glance

• Affected plugin: Paytium — Mollie payment forms & donations
• Affected versions: ≤ 4.3.7
• Fixed in: 4.4
• Vulnerability type: Broken Access Control — missing authorization in create_mollie_account
• CVE: CVE-2023-7291
• Patch status: Fix available (update to 4.4+)

Why this matters

Payment plugins interact with financial processors and often store API credentials, merchant settings, and transactional workflows. A missing authorization check in a function that can create or configure the payment connector is high risk: low-privileged users (or unauthenticated callers, depending on registration) may be able to change payment configuration, inject credentials, or alter webhook endpoints.

Even if no API secrets are directly leaked, unauthorized configuration changes can enable fraud, redirect funds, break payment flows, or be used as a foothold for further compromise. Access control errors in payment plugins therefore require urgent attention.

What “missing authorization in create_mollie_account” means (technical summary)

At a high level, a “missing authorization” means the code handling the create_mollie_account action does not verify that the caller has the expected privileges (for example, using current_user_can('manage_options')) or the required nonce/token. In WordPress this commonly manifests with:

• AJAX handlers (via admin-ajax.php) registered with add_action('wp_ajax_...') or add_action('wp_ajax_nopriv_...') but lacking capability or nonce checks.
• REST API endpoints registered without a permission_callback.
• Form handlers or custom endpoints that assume only administrators will call them.

When authorization is missing, attackers can call endpoints that perform sensitive actions (create/update payment accounts, store API keys, change settings) without proper checks. The reported vulnerable function create_mollie_account appears callable by unauthorized actors because the plugin did not enforce capability checks or verify request nonces — a classic broken access control pattern.

Possible real-world impacts and exploitation scenarios

Depending on the plugin internals and site configuration, an attacker exploiting this could:

• Create fraudulent payment accounts or inject attacker-controlled processor credentials that route funds away from the site owner.
• Modify payment settings (webhooks, callback URLs) to intercept or hijack notifications and transactions.
• Trigger payment-related actions that subvert business logic (e.g., mark payments complete, create refunds).
• Add persistent malicious configuration that persists in the database across updates.
• Combine with other weaknesses (weak file permissions, outdated core/themes/plugins) to escalate access or plant backdoors.

Importantly: exploitation may not require administrator privileges. If the endpoint is registered for nopriv access, unauthenticated requests may succeed. If it is callable by low-privilege authenticated users, an attacker may only need to register an account to exploit the flaw.

Exploitability: how easy is it?

Exploitability is moderate to high when one or more of the following are true:

• User registration is enabled (attackers can create subscriber accounts).
• The endpoint is registered as nopriv (accessible without authentication).
• No server-side nonce, capability, or CSRF protections exist.

Because the action name create_mollie_account is predictable, an attacker can craft POST requests to the exposed handler (admin-ajax.php?action=create_mollie_account) or to a registered REST route and observe results. No special network access beyond normal HTTP(S) is needed.

Immediate actions for site owners (ordered priority)

1. Update the plugin to the fixed version (4.4 or later). This is the definitive fix. Test in staging where possible, then deploy to production.
2. If you cannot update immediately, apply temporary blocking measures. Use server-level rules (nginx or .htaccess) or implement a quick PHP-level interception to block calls to the vulnerable action.
3. Rotate Mollie API keys and any stored credentials if compromise is suspected. Regenerate API tokens from the Mollie dashboard and update the plugin configuration only after you have secured the endpoint.
4. Audit payments and logs. Review payment logs, webhooks, recent transactions, and plugin settings for anomalies or newly added webhook endpoints.
5. Audit users and roles. Remove suspicious accounts, enforce least privilege, and consider disabling public registration if not needed.
6. Run malware scans and file-integrity checks. Look for recently modified files, unexpected PHP files, or injected code.
7. Monitor and block suspicious IPs. Use server or firewall rules to block abusive sources.

Practical rules and code examples (apply carefully)

Test any change on staging first and ensure you have current backups of files and database.

1) Block the action in .htaccess (Apache / mod_rewrite)

# Block requests that call the vulnerable action via admin-ajax.php
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} (?:admin-ajax\.php)$ [NC]
  RewriteCond %{QUERY_STRING} (?:^|&)action=create_mollie_account(?:&|$) [NC]
  RewriteRule .* - [F,L]
</IfModule>

This returns HTTP 403 for matching requests and is a conservative server-side block if the plugin relies on admin-ajax.php?action=create_mollie_account.

2) Nginx rule to block the same request

# Block direct calls to admin-ajax.php for the vulnerable action
location ~* /wp-admin/admin-ajax\.php$ {
    if ($args ~* "(^|&)action=create_mollie_account(&|$)") {
        return 403;
    }
    # pass to php-fpm otherwise
    fastcgi_pass   unix:/run/php/php7.4-fpm.sock;
    # ... other fastcgi config ...
}

If you cannot edit nginx config on managed hosting, use alternative mitigations such as virtual patching or WAF rules provided by your hosting provider.

3) Virtual patch — temporary PHP snippet to disable unauthenticated handling

Add this as a must-use plugin (wp-content/mu-plugins/) or a short site-specific plugin that runs early. Adjust handler names if the plugin uses different callables.

<?php
/**
 * Temporary mitigation: prevent unauthenticated create_mollie_account calls
 * Place in wp-content/mu-plugins/disable-create-mollie.php
 */

add_action('init', function() {
    // Remove any unauthenticated handler to block public access
    if (has_action('wp_ajax_nopriv_create_mollie_account')) {
        remove_action('wp_ajax_nopriv_create_mollie_account', 'create_mollie_account');
    }

    // Replace authenticated handler with a safe wrapper that enforces capability checks
    if (has_action('wp_ajax_create_mollie_account')) {
        remove_action('wp_ajax_create_mollie_account', 'create_mollie_account');

        add_action('wp_ajax_create_mollie_account', function() {
            if (!is_user_logged_in() || !current_user_can('manage_options')) {
                wp_send_json_error(array('error' => 'Unauthorized'), 403);
            }

            // Optional: verify nonce if the plugin uses one
            if (!empty($_REQUEST['security'])) {
                check_ajax_referer('paytium_nonce', 'security', true); // adjust nonce name if necessary
            }

            // For mitigation, reject or log the attempt. Do not call original handler here.
            wp_send_json_success(array('message' => 'Action disabled for safety'));
        });
    }
}, 5);

Notes: adjust callable names if different, and remove this temporary code after updating to the fixed plugin release.

4) WAF rule example (conceptual)

If you have WAF capabilities (hosted or edge), block requests where:

• Path is /wp-admin/admin-ajax.php and parameter action=create_mollie_account.
• Or the specific REST endpoint path is called.

Pseudo-signature logic:

if request.path == "/wp-admin/admin-ajax.php" and param("action") == "create_mollie_account":
    block()

How to detect if your site was targeted or exploited

Search HTTP access logs, application logs and audit trails for the following indicators:

• Requests to /wp-admin/admin-ajax.php?action=create_mollie_account or any REST route containing create_mollie_account.
• POST requests with payloads or JSON referencing create_mollie_account.
• New or unexpected payment accounts, API keys, or webhook endpoints in plugin settings.
• Unexpected database changes to plugin options (wp_options), especially recent updates.
• POSTs coming from low-privilege accounts or unauthenticated callers.

Example command-line checks:

# Search access logs for the action name
grep -i "create_mollie_account" /var/log/nginx/access.log* | less

# Find recent POSTs to admin-ajax.php with the action
awk '$6 ~ /POST/ && $7 ~ /admin-ajax.php/ {print $0}' /var/log/nginx/access.log | grep -i "create_mollie_account"

If calls are present prior to applying the patch, assume possible compromise until validated otherwise.

Incident response checklist (concise)

1. Patch: Update Paytium to version 4.4 or later on all environments.
2. Isolate: If abuse is ongoing, disable the plugin or restrict site access temporarily.
3. Virtual patch: Apply server-level blocking rules or the PHP mu-plugin snippet until patching is complete.
4. Credentials: Rotate Mollie API keys and any other payment-related secrets. Reset admin passwords and rotate service tokens where applicable.
5. Audit: Review transactions, webhook endpoints, plugin settings, and database options for suspicious changes.
6. Scan: Run full file-integrity and malware scans; check for new files, modified core files, or unfamiliar cron jobs.
7. Restore: If you find malicious changes, restore from a known-good backup taken before the suspicious activity.
8. Monitor: Increase monitoring of admin-ajax, REST API calls, login attempts and payment activity for several weeks after remediation.
9. Notify: If customer payments were affected, notify your payment provider and follow legal/contractual reporting obligations.

Developer guidance: preventing this class of vulnerability

Developers should assume every administrative action requires explicit server-side authorization. Practical safeguards:

• Enforce capability checks with current_user_can() before performing sensitive operations.
• Use nonces for AJAX and form submissions (check_ajax_referer(), wp_verify_nonce()).
• For REST routes, always include a permission_callback when calling register_rest_route.
• Avoid registering wp_ajax_nopriv_* handlers for administrative or configuration tasks.
• Sanitize and validate all inputs regardless of authorization presence.
• Follow the principle of least privilege: only expose functionality to the minimal role required.

Example REST registration with explicit permission check:

register_rest_route('paytium/v1', '/create_mollie_account', array(
    'methods' => 'POST',
    'callback' => 'paytium_create_mollie_account',
    'permission_callback' => function() {
        return current_user_can('manage_options') && check_admin_referer('paytium_admin_action', '_wpnonce');
    }
));

Detection and hardening checklist for hosts and agencies

• Maintain rapid patching processes for plugins and provide a standard virtual-patch workflow for critical fixes.
• Deploy centralized blocking rules or WAF signatures that can be applied to fleets (e.g., block action=create_mollie_account).
• Monitor admin-ajax.php usage and alert on anomalous spikes or unexpected endpoints.
• Provide hardened WordPress images that include MU-plugins for common mitigations and allow staged updates.
• Enforce strict HTTP security headers and implement content security where appropriate.

Frequently asked questions (FAQ)

Q: I updated to 4.4 — do I still need to do anything?

A: Updating is the primary fix. After updating, rotate any payment API keys if you suspect prior compromise and verify plugin settings, payment accounts and webhooks for unauthorized changes.

Q: My site uses caching/CDN — could exploits be cached?

A: The vulnerable action is typically dynamic (POST to admin-ajax.php), so caches and CDNs usually do not serve cached responses. However, edge WAF rules can block offending requests at the CDN level; logs still need review.

Q: I do not use Mollie — am I still affected?

A: If the Paytium plugin is installed (even if Mollie is not configured), your site is affected if the version is ≤ 4.3.7. Update or uninstall the plugin.

Q: I have no registered users — am I safe?

A: If the endpoint is exposed to unauthenticated users (nopriv), attackers can call it without accounts. If not, an attacker may register an account (if registration is enabled) and exploit the endpoint. Update or block until patched.

General protective measures

Beyond the immediate mitigations described above, apply layered defenses to reduce exposure time and blast radius for future vulnerabilities:

• Ensure timely plugin updates and a documented rollback plan.
• Centralize logs and alerts for admin-ajax and REST API activity.
• Use IP allowlists for administrative endpoints where practical.
• Maintain regular backups, and periodically test restoration procedures.
• Educate site maintainers on the importance of capability checks and nonce usage in WordPress development.

Final words: urgency and practical summary

1. Update the plugin to version 4.4 or later now — this is the definitive fix.
2. If you cannot update immediately, apply the server/WAF mitigations or the virtual patch snippet described above.
3. Rotate any potentially exposed payment credentials and audit payment logs and settings.
4. Increase monitoring and review user accounts, especially if registration is enabled.

Payment integrations touch money and customer trust. Treat any access-control failures in payment-related plugins as high priority and follow the steps above to reduce risk. If you need further technical assistance, engage a trusted security professional to perform a focused incident review and remediation.

Stay vigilant,
Hong Kong Security Expert