650 Pages Reference the Supsystic Popup Plugin; That Is a Clue, Not an Install Count
WordPress plugin inventories are hard to measure from outside. Plugins can be inactive, hidden behind asset optimization or loaded only on a subset of pages. A body-content query can still provide a useful clue, as long as the team reads it as a clue rather than an installation census.
On 28 October 2026, ZoomEye returned 650 assets for http.body="popup-by-supsystic" with sub_type=all. The string identifies pages whose HTTP body contains the plugin slug. It does not prove that the plugin is active, that it is vulnerable or that the site uses MailChimp integration.
Why this plugin is in the review queue
CVE-2026-115225 affects Customer Engagement System, also known as Smart Popup by Supsystic, before version 2.0.2. An unauthenticated MailChimp interest-group lookup can be used to make the server open connections to arbitrary internal hosts and ports. The attacker may infer reachability from response timing even when the internal content is not returned.
The request path is part of a WordPress site that many organisations treat as marketing infrastructure. That site may sit inside a shared hosting account, a content delivery network or a corporate network with access to internal APIs. The plugin flaw becomes a network problem when the web server can reach more than its intended integration endpoints.
Use the body match to ask better questions
For each observed domain, identify the site owner and confirm the plugin version through the content management system. Do not install a plugin merely to make an external test work, and do not send an exploit request to a third-party site. If the site belongs to an external organisation, treat the observation as context only.
For owned sites, check the plugin file version, activation state and whether the MailChimp interest-group route is reachable without authentication. Upgrade to 2.0.2 or later. If the plugin is not needed, remove it and clear any cached assets that might keep the old route or slug visible.
A body match may disappear after a cache purge even when the plugin remains installed. That is another reason to keep the CMS inventory and the external observation separate. The site owner should verify the vulnerability state; the search result cannot do that verification.
Reduce the SSRF blast radius
Restrict outbound traffic from the WordPress host. Allow only the mail, payment, update and CDN destinations required by the site, preferably through a proxy that resolves and validates every destination. Block loopback, private, link-local and cloud metadata address ranges.
If the site uses a shared hosting platform, ask the provider what egress controls apply. A plugin update protects the specific request path. Network policy protects against other extensions and future code that makes an outbound request with a user-controlled destination.
Log the destination, status and timing of outbound requests. A successful internal probe may leave no useful response in the web log, but the proxy can show a connection attempt. Retain those records long enough to investigate unusual bursts around a plugin update or a suspicious administrator login.
Turn the clue into a repeatable review
Keep the dork, scope, timestamp and result with the site inventory. Repeat the same body query after remediation and compare owned domains, not only the total. A count of 650 can rise while a specific organisation removes the plugin if unrelated sites publish the same slug. Aggregate movement is not proof that the vulnerable population changed in the expected direction.
The useful goal is a list of owned sites, plugin versions, network egress policies and owners for the public-facing integration. The 650 matches help start that conversation. They do not replace it.
Top comments (0)