CVE-2026-97074 in Newsletters Email Marketing SMS and Popups Plugin
Summary
by MITRE • 09/30/2026
Subscriber Insecure Direct Object References (IDOR) in Newsletters, Email Marketing, SMS and Popups by Omnisend <= 1.9.0 versions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified as an insecure direct object reference within the Omnisend plugin for WordPress, affecting versions up to 1.9.0, represents a critical authentication bypass mechanism that allows unauthorized access to sensitive subscriber data and marketing assets. This flaw stems from insufficient server-side validation of input parameters used to identify specific resources such as newsletter campaigns, email templates, SMS messages, or popup configurations. In secure application design, identifiers for objects should be opaque or require explicit authorization checks against the current user's permissions; however, in this implementation, the system relies on predictable or directly manipulatable object IDs without verifying that the requesting subscriber account has legitimate ownership or administrative rights to view or modify these items. This architectural weakness enables an attacker who possesses valid credentials for a low-privilege subscriber account to enumerate and access resources belonging to other subscribers or even administrative users by simply altering numerical identifiers in HTTP requests, thereby bypassing intended access controls entirely.
From a technical perspective, this vulnerability aligns with the Common Weakness Enumeration category CWE-639, which describes issues related to authorization bypass through direct object references. The exploitation vector typically involves intercepting network traffic via tools such as Burp Suite or OWASP ZAP and modifying parameters like campaign_id, template_id, or subscriber_list_id in API calls or form submissions. Because the backend logic fails to cross-reference these identifiers with a session-based permission matrix that restricts access based on user roles, any authenticated user can retrieve private data including email addresses, personal details, purchase history, and engagement metrics of other users. This lack of proper object-level authorization transforms what should be isolated customer records into publicly accessible information within the context of an authenticated session, creating a significant privacy violation and potential compliance breach under regulations such as GDPR or CCPA due to the exposure of personally identifiable information without consent.
The operational impact of this vulnerability is severe for both end-users and business owners utilizing Omnisend for their marketing operations. For subscribers, it results in the complete compromise of personal data integrity and confidentiality, potentially leading to identity theft, targeted phishing attacks, or harassment based on exposed behavioral patterns and contact details. For businesses, the consequences extend beyond privacy concerns to include reputational damage, loss of customer trust, and potential legal liabilities arising from non-compliance with data protection laws. Furthermore, if administrative functions are also susceptible due to similar IDOR flaws in higher-privilege endpoints, attackers could escalate their access to modify marketing content, send unauthorized communications on behalf of the brand, or delete critical campaign configurations, effectively disrupting business continuity and causing financial loss through compromised advertising spend and damaged brand equity.
Mitigation strategies must prioritize immediate patching alongside robust defensive coding practices. The primary remediation step is to upgrade the Omnisend plugin to a version newer than 1.9.0 where these authorization checks have been corrected by the developers. In addition to updating, administrators should implement strict server-side validation for all object identifiers, ensuring that every request includes an explicit check against the authenticated user's permissions before returning data or performing actions. It is also advisable to employ indirect reference maps rather than exposing sequential database IDs directly in URLs or API payloads where possible, although this alone does not replace proper authorization logic. Security monitoring should be enhanced by logging and alerting on unusual patterns of resource access that deviate from typical user behavior, such as a single subscriber account rapidly accessing multiple distinct campaign records belonging to different entities. Regular penetration testing focusing on broken access control scenarios is recommended to identify similar vulnerabilities in other integrated marketing tools within the WordPress ecosystem.