The Forminator vulnerability is another strong example of why WordPress security cannot be treated as simply keeping the core platform patched. In practice, the larger attack surface often comes from plugins, especially plugins that process forms, payments, uploads, exports and other user-controlled data.
In this case, the issue is particularly serious because Forminator sits directly in the path of information submitted by website visitors. Depending on how a site uses the plugin, that information may include names, email addresses, phone numbers, enquiries, registration details or even business-sensitive data. A weakness in authorization or export functionality therefore does not merely affect the website itself; it can become a route to the information collected through that website.
The underlying lesson is familiar but important: authentication and authorization are not the same thing. A user may be legitimately logged in to WordPress, but that does not mean the user should automatically be permitted to export form submissions, modify modules or perform other sensitive administrative operations. Every privileged action needs an independent capability check on the server side.
This becomes even more important in WordPress environments because organisations often create multiple roles for editors, contributors, customer-support personnel, marketing teams and external agencies. A low-privilege account may seem relatively harmless, but a plugin vulnerability can sometimes allow that account to perform actions far beyond the permissions originally intended.
The security impact is therefore not limited to compromise through unauthenticated attackers. Organisations also need to consider what happens if a subscriber-level or otherwise restricted account is compromised. An attacker who obtains a weak password, reused credential or stolen session may be able to combine that access with an authorization flaw and reach data that should have remained inaccessible.
Form plugins deserve additional attention because they frequently become informal repositories of sensitive data. Businesses create a form for sales enquiries, job applications, support requests, registrations or customer onboarding and then allow submissions to accumulate indefinitely. Months or years later, the database may contain far more personal information than anyone originally intended to retain.
That makes data minimisation an important defensive measure. Even when a vulnerability cannot be prevented entirely, its impact can be substantially reduced if the organisation is not retaining thousands of unnecessary historical submissions. Sensitive information should be collected only when required and deleted when its legitimate purpose has expired.
Another lesson is that security monitoring should include administrative actions performed through plugins. Exporting hundreds or thousands of form submissions, creating scheduled exports, cloning modules or changing plugin configuration may all be legitimate operations, but they should also be auditable. If a normally low-privilege account suddenly begins performing such actions, security teams should be able to detect it.
For internet-facing WordPress deployments, plugin inventory becomes equally important. Many organisations know their WordPress version but cannot immediately identify which plugins are installed across all their sites or which versions are running. That makes emergency vulnerability response unnecessarily difficult. When a serious plugin flaw is disclosed, the first question should not be “where do we use this?” because that information should already be available.
Automatic updates can help, but they should not replace vulnerability management. Critical business websites often delay plugin updates because administrators fear compatibility problems, which is understandable but creates its own risk. Organisations should have a process for quickly testing and deploying security updates when vulnerabilities affect exposed components.
A web application firewall can provide an additional layer of protection, especially while patches are being tested, but it should not be treated as a substitute for correcting the vulnerable application. Authorization flaws are particularly difficult to solve entirely at the network layer because the malicious request may be syntactically valid and originate from an authenticated user.
The broader problem is that WordPress plugins effectively become part of the application’s trusted codebase. Installing a plugin means giving that software access to the WordPress database, user sessions and often sensitive information. Organisations should therefore evaluate plugins not only for functionality but also for maintenance quality, update history and security responsiveness.
This Forminator issue also reinforces a larger cybersecurity principle: security controls must exist where the decision is actually made. Hiding an administrative function in the interface, restricting a menu item or assuming that only administrators will know how to invoke an action is not sufficient. The backend must verify permissions every time a sensitive operation is requested.
For organisations using Forminator, the priority should be to ensure the plugin is updated to a fixed version, review user roles and plugin permissions, check for unusual export activity and reconsider how long form submissions are retained.
The recurring lesson is simple. WordPress itself may be secure, but every plugin extends both its functionality and its attack surface. The more sensitive the information a plugin handles, the more seriously its authorization, logging, update and data-retention controls need to be treated.

A critical security flaw has been disclosed in Forminator Forms, a WordPress plugin with more than 600,000 active installations, that could be exploited to achieve arbitrary code execution on susceptible sites. The vulnerability, tracked as CVE-2026-15748, is rated 9.8 out of 10.0 on the CVSS scoring system. It was discovered and reported by a security researcher who goes by the online alias "
Source: Forminator WordPress Flaw Can Enable Unauthenticated RCE via Malicious PHP Uploads via The Hacker News — published 17 Aug 2026.
Was this article helpful?
Your feedback helps us improve the knowledge base.