Open Redirect in deconf Analytics Insights for Google Analytics 4 (AIWP)

The Analytics Insights for Google Analytics 4 (AIWP) WordPress plugin before 6.3 is vulnerable to Open Redirect due to insufficient validation on the redirect oauth2callback.php file. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if they can successfully trick them into performing an action.

• deconf Analytics Insights for Google Analytics 4 (AIWP): versions before 6.3 are marked affected.
• WPScan identifies 6.3 as fixed. This is a fixed-release statement for the documented branch, not an open-ended claim covering every later or parallel branch that has not been separately verified.
• Vendor attribution is inconsistent: the normalized record and NVD CPE use deconf, while the CNA affected entry lists the vendor as Unknown. The product name and version boundary are otherwise consistent.

This is a CWE-601 URL Redirection to Untrusted Site weakness in deconf Analytics Insights for Google Analytics 4 (AIWP). The affected component is the oauth2callback.php callback file, where insufficient validation of the redirect destination allows attacker-controlled data to influence the target URL. The PoC published by WPScan shows the state parameter being supplied with data pointing to an external destination, but the available evidence does not document the complete validation rule or code path. The flaw is network reachable, requires no authentication, and requires the target user to perform an action. The direct result is redirection to a potentially malicious site; credential theft or other downstream harm depends on user behavior and is a possible consequence, not a confirmed server-side effect.

• Reachability: Network.
• Authentication: Not required.
• User interaction: Required. The attacker must persuade the user to perform an action.
• Complexity: Low according to the supplied assessment data.
• Exploitation status: WPScan publishes a proof of concept for the flaw, so public exploit material exists. The available evidence does not identify a campaign, victim, or successful exploitation in the wild.

The flaw allows an unauthenticated remote request to influence the user's redirect destination when the user performs an action after being socially engineered. The direct technical outcome is that a user can be sent from a trusted WordPress site to a potentially malicious website. This could increase the effectiveness of phishing, credential harvesting, or malicious content delivery, but those consequences depend on the destination and user behavior. The available evidence does not show that the flaw itself enables remote code execution, server takeover, or service disruption.

• A WordPress site can be abused as a trusted launch point that sends users to a phishing or malicious website.
• If users trust the originating site, the flaw could support credential harvesting, phishing, or delivery of unsafe content.
• Organizations may face reputational harm and increased support or incident-response workload.
• Confidentiality and integrity impact are possible downstream consequences after redirection; the supplied assessment does not identify a direct availability impact on the server.

1. Upgrade Analytics Insights for Google Analytics 4 (AIWP) to 6.3, which WPScan identifies as fixed.
2. Check all WordPress sites, secondary servers, and staging environments to ensure that no affected plugin copy remains deployed.
3. After updating, verify the installed version on the server and test the OAuth callback in a controlled environment to confirm that redirect behavior matches the application design.
4. The available evidence does not document a separate vendor workaround. Do not treat blocking one request pattern or checking only the administrative interface as a substitute for updating.

1. Inventory WordPress sites that have the analytics-insights plugin installed and record the version deployed on each server.
2. Compare inventoried versions with the fixed-release boundary in the affected summary, including copies deployed in staging environments, restorable backups, and secondary servers.
3. Review web server and application logs for requests to tools/oauth2callback.php, especially unusual state values or external redirect destinations. This is precautionary monitoring, not a confirmed indicator of compromise.
4. In a controlled test environment, verify that the OAuth callback redirects only to destinations allowed by the application design and does not send users to unintended external sites.
5. The absence of matching log entries does not prove that a system is safe. Exposure should be determined first from software inventory and plugin version.