How to address an invalid "NOT IN ()" query?

Question

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

Answer 1

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.