CVE-2026-0750

Overview

Drupal is an open-source content management system known for its flexibility, robust features, and strong community support. Organizations of all sizes use it to build and manage dynamic websites and web applications. The Commerce Paybox contributed module allows users to pay through the commercial Paybox service.

The compromised module allows an attacker to craft a return URL to mark a transaction as successful without a real payment. The fix ensures that this is no longer possible.

Signature forgery is a vulnerability that allows attackers to create fraudulent digital signatures that appear legitimate, often by exploiting weaknesses in cryptographic algorithms, improper verification processes (such as CWE-347: Improper Verification of Cryptographic Signature), or flaws in key management and signature validation. This can occur in contexts like JWTs, XML documents, or API tokens where signatures are used to ensure integrity and authenticity, enabling attackers to tamper with data or impersonate entities without the private key. Additional information is available at OWASP: https://owasp.org/Top10/A02_2021-Cryptographic_Failures.

Ramifications include:

• Data tampering
• Unauthorized access
• Identity spoofing
• Malware injection
• Trust erosion, and
• System compromise.

This issue affects all versions of Drupal 7 Commerce Paybox including and below 7.1.5; it is patched  in Commerce Paybox NES version 7.1.6.

‍

Details

Module Info

• Product: Drupal
• Affected code: Commerce Paybox module
• Affected versions: >=7.1.0 <=7.1.5
• Project page: http://drupal.org/project/commerce_paybox
• Fixed in:  Commerce Paybox NES 7.1.6

Vulnerability Info

This high-severity vulnerability is found in all versions of the Commerce Paybox module equal to or lower than 7.1.5.

This fix adds Paybox signature verification on the offsite return using the Paybox public key  (the sig parameter). If the IPN hasn’t confirmed the payment and the gateway returned a  non-00000 error, the redirect is rejected.

‍

Steps To Reproduce

1. On a vanilla Drupal 7 instance, install and enable a susceptible version of Commerce Paybox (any version under 7.1.6) with its basic dependencies:

ddev composer require drupal/commerce drupal/entity drupal/rules drupal/views 
ddev drush en -y commerce commerce_ui commerce_product commerce_order commerce_customer commerce_payment commerce_checkout commerce_cart commerce_paybox

‍

2. For local testing only, modify the module to add a mock return flow (not present in stock Commerce Paybox). If you add a commerce_paybox_mock_enabled variable in your local patch, enable it and clear caches:

ddev drush vset commerce_paybox_mock_enabled 1 && ddev drush cc all

‍

3. Whitelist local IPs:

ddev drush php-eval 'variable_set("commerce_paybox_paybox_servers", array("127.0.0.1","::1","::ffff:127.0.0.1","192.168.97.5"));'

‍

4. Create a pending transaction:

• Add a simple product and go through checkout, selecting Paybox (mock keeps you on-site). Stop after “Checkout complete” — the payment stays PENDING.
• In /admin/commerce/orders, open the order → Payments, and note the txnid (or order number if using order-number mode).

5. Trigger the forged return flow (vulnerable behavior) 

• Use the mock to reach the PBX_EFFECTUE-style return URL before IPN processing.
• Visit: https://drupal-base.ddev.site:8493/commerce_paybox/auto?txnid=TXNID_HERE&error=00000&sig=bogus
  • Expected on vulnerable code: the fake callback is accepted and the payment flips to SUCCESS.
  • Set commerce_paybox_mock_enabled to false and perform the steps above a second time.
  • Expected when fixed: signature check rejects it; payment remains PENDING (or FAILURE), not SUCCESS.

‍

Addressing the Issue

Users of the affected component(s) can address this exploit in one of the following ways:

• Remove/disable the Paybox payment method from checkout so orders can’t complete through it.
• Restrict the callback endpoints (/commerce_paybox/auto and the return URL) at the reverse proxy/WAF to only known Paybox IPs. Note that this reduces the attack surface but is not a fix.
• Add a temporary reverse-proxy rule to drop callbacks with missing/invalid sig parameters. Note that this reduces the attack surface but is not a fix.
• The only true mitigations are to disable the module and patching it. Consider signing up for post-EOL security support; HeroDevs customers get immediate access to a patched version of this module.

‍

Credits

• David Hernández (defr)