- 🇺🇸United States TomTech
Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.
IPN processing function has the following signature:
commerce_paypal_process_ipn($payment_method = NULL, $debug_ipn = array())
Menu items following to this function are:
$items['commerce_paypal/ipn'] = array(
'page callback' => 'commerce_paypal_process_ipn',
'page arguments' => array(),
'access callback' => TRUE,
'type' => MENU_CALLBACK,
);
$items['commerce_paypal/ipn/%commerce_payment_method_instance'] = array(
'page callback' => 'commerce_paypal_process_ipn',
'page arguments' => array(2),
'access callback' => TRUE,
'type' => MENU_CALLBACK,
);
Since page argument for $debug_ipn is not set on the second menu item, any string can be passed to this function. And the function gives full trust to this value, omitting PayPal validation, passing this string to the payment methods callbacks, etc.
For example, using the following URL with valid payment method instance results in "test" string passed as an IPN without any validation to payment method callbacks:
/commerce_paypal/ipn/paypal_wps|commerce_payment_paypal_wps/test
I'm not sure if that's a security issue on default configuration, but custom payment methods may be vulnerable or produce really unexpected results because of this issue.
Patch explicitly sets default value for the $debug_ipn argument to avoid passing any strings to it.
This was reported by Dmitriy.trt to the security team tracker. The security team and rszrama decided it could be handled in public.
Closed: outdated
2.0
PayPal / IPN
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.