Atomic Edge analysis of CVE-2026-42668:
This vulnerability allows an unauthenticated attacker to take over the Omnisend integration for any WooCommerce store running plugin version 1.18.0 or earlier. The flaw resides in the OAuth connect token generation mechanism, which uses a predictable value derived solely from the current Unix timestamp. This enables a brute-force attack against the connect REST API endpoint, ultimately letting the attacker replace the store’s Omnisend API key and brand ID with their own values.
The root cause is in the `generate_install_url()` function within `omnisend-connect/includes/class-omnisend-install.php` (line 234 in the vulnerable version). The token was generated as `hash(‘sha256’, time())`, producing a 64-character hex string based only on the current Unix timestamp. Since `time()` returns an integer with one-second granularity, there are at most 86,400 possible values per day. The token is stored in the `omnisend_connect_token` WordPress option and used to authorize the `/wp-json/omnisend-api/v1/connect` REST API endpoint. The `omnisend_rest_api_authorization()` function in `omnisend-api.php` compares the provided token with the stored value using `!==`, which is timing-safe enough but does not mitigate the fundamental weakness of the token space.
An attacker can exploit this by first determining the approximate server time (via HTTP headers, timestamps in responses, or other means). They then brute-force the 86,400 possible SHA-256 hashes of Unix timestamps around that time window. The attack sends POST requests to `/wp-json/omnisend-api/v1/connect` with a JSON body containing `connect_token` (the guessed hash) and `api_key` and `brand_id` parameters controlled by the attacker. A successful guess (HTTP 200 instead of 401/403) means the attacker can replace the store’s Omnisend credentials. The attack is entirely unauthenticated and requires only network access to the target WordPress site.
The patch in version 1.18.1 changes the token generation in `class-omnisend-install.php` (line 234) from `hash(‘sha256’, time())` to `bin2hex(random_bytes(32))`. This produces a 64-character hex string from a cryptographically secure random source, yielding 2^256 possible values. The token is now unpredictable and cannot be brute-forced. Additionally, the patch refactors the error handling in `omnisend-api.php` to use a unified `omnisend_connect_token_invalid_error()` function, which returns a 403 status for all token validation failures (missing token, empty stored token, or token mismatch). This prevents information leakage about which specific validation step failed. The comparison also switched to `hash_equals()` for timing-safe comparison, though the real security gain is from the random token generation.
The impact is critical: an attacker who successfully guesses the connect token can replace the store’s Omnisend API key and brand ID. This redirects all customer data synchronization (names, emails, orders), order webhook notifications, and marketing email/SMS communications to the attacker’s Omnisend account. The store loses control over its marketing automation, and customer PII is exposed to the attacker. Since the attack requires no authentication and can be automated, any site running the vulnerable plugin is at risk until patched.
