0

Symptoms:

In WordPress admin menu we cannot see any pages or products listed any more,
even thoguh the pages and products are still accessible through weblinks for example.

Tracing the issue:

On one hand as far as I can see in query monitor is that an invalid empty array parameter is provided for NOT IN():
"AND wp_posts.post_author NOT IN ()"
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax The caller line is long, seemingly it originates somewhere in WooCommerce or WooCommerce-payments plugins. Unfortunately the problem does not go away if I disable such plugins (and most others also).
The problem however DOES go away if I disable the i-excel THEME.
Obviously I need the theme to be turned back on.
it had no issues this far, and we did not update anything in the system really. So I'm stuck in here.

Updates 2:

I have traced down everything in the callstack. up until "get_option('wp_custom_filters');" I want to know what is/what is insidewp_custom_filters to see if that can be amended on the user interface/database level maybe. I did not find anything about it in google yet.

function customFiltersSettings() {
    $settings = get_option('wp_custom_filters');

    if (!$settings) {
        return null;
    }

    return unserialize(base64_decode($settings));
}

There is a criterium for sending null if the list is empty, and wp_posts.post_author NOT IN (null) would create no error, but for some reason wp_posts.post_author NOT IN () runs instead at the end.

Appendix

This is the shortest query error out of the 4 thta I can see in query monitor:

SELECT wp_posts.ID
FROM wp_posts
WHERE 1=1
AND wp_posts.post_type = 'shop_subscription'
AND wp_posts.post_author NOT IN ()
ORDER BY wp_posts.post_date DESC
LIMIT 0, 1

The caller for that shows this:

WP_Query->get_posts()
wp-includes/class-wp-query.php:3219
WP_Query->query()
wp-includes/class-wp-query.php:3800
WP_Query->__construct()
wp-includes/class-wp-query.php:3932
WC_Order_Data_Store_CPT->query()
wp-content/plugins/woocommerce/includes/data-stores/class-wc-order-data-store-cpt.php:965
WC_Data_Store->__call()
wp-content/plugins/woocommerce/includes/class-wc-data-store.php:207
WC_Order_Query->get_orders()
wp-content/plugins/woocommerce/includes/class-wc-order-query.php:87
wc_get_orders()
wp-content/plugins/woocommerce/includes/wc-order-functions.php:66
wcs_do_subscriptions_exist()
wp-content/plugins/woocommerce-payments/vendor/woocommerce/subscriptions-core/wcs-functions.php:62
WC_Payments_Subscriptions_Empty_State_Manager->replace_subscriptions_empty_state()
wp-content/plugins/woocommerce-payments/includes/subscriptions/class-wc-payments-subscriptions-empty-state-manager.php:93
apply_filters('woocommerce_subscriptions_not_found_label')
wp-includes/plugin.php:205
WC_Subscriptions_Core_Plugin->register_order_types()
wp-content/plugins/woocommerce-payments/vendor/woocommerce/subscriptions-core/includes/class-wc-subscriptions-core-plugin.php:341
do_action('init')
wp-includes/plugin.php:517
2
  • One furthe UPDATE: It seems that unfortuunately WordPress auto-updated itself recently to the latest release. That at least explains where the change comes from. What can be the next best steps knowing that? Maybe rolling back to a backup and trying to turn aouto-updat off somehow? Commented Oct 26, 2023 at 15:21
  • You'll need to check with the theme's support team about this. Third-party theme support is off topic here.
    – Pat J
    Commented Oct 26, 2023 at 16:36

1 Answer 1

0

I have resolved it eventually.
I suspect this was an injection attack on the system by a bot that managed to create a user account for itself.
One lesson learned is to govern user creation more strictly.
But it's still not fully clear what/how the intruder acted,
so if somebody has a clue, share in the comments please...

This is what I conlcluded and mitigated:
In the AND wp_posts.post_author NOT IN (), the () was receiving it's value from:

function customFiltersSettings() {
    $settings = get_option('wp_custom_filters');

    if (!$settings) {
        return null;
    }

    return unserialize(base64_decode($settings));
}

I looked up the database's wp_options table to see what the wp_custom_filters entry contains,
and it contained 'YTowOnt9' a.k.a a:0:{} translated from base64.
This way the !$settings protection could not replace the empty array with a suitable null,
because at the time of checking it was a real value in base64.
So simply deleting the content of wp_custom_filters entry in the wp_options table of the database, resolved the error.

Theme/Plugin/WPDevelopers need to check, but I think this might be a live vulnerability in i-excel and also in twentytwenty theme I think. (maybe even more).

I would suggest a correction that would expand the if !$settings part with some extra code that also validates the decoded value of unserialize(base64_decode($settings) ...

What I don't know among many things yet is what wp_custom_filters originates from, and how can somebody from the UI modify it's content?! (eg. where was the intrusion point, AND where can I use this option for something actually useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.