Everest Forms Pro RCE (CVE 2026)

How form logic led to code execution on the server

At the end of March 2026, a critical Remote Code Execution vulnerability was disclosed in the Everest Forms Pro plugin (up to version 1.9.12). The flaw received a CVSS score of 9.8 and was patched in version 1.9.13.

At the CVE description level, this is another RCE case in the WordPress ecosystem. In practice, however, this vulnerability originates in the application’s business logic layer, not in classic input mechanisms.

As part of our security testing, we analyzed this vulnerability, reproduced its mechanism, and built a working exploit confirming the possibility of server-side code execution.

Context: functionality designed to simplify business operations

Everest Forms Pro offers a Complex Calculation feature that enables dynamic recalculation of form values based on user-provided input.

From a business user’s perspective, this is a typical feature set:

• automatic calculations

• dynamic forms

• logic dependent on input data

From a security perspective, however, this is an area where user data begins to influence how the application behaves.

Where the vulnerability appears

In the analyzed case, user input is not treated solely as values used in calculations.

Instead:

• it is embedded into the expression structure built on the server side

• it affects the final form of that expression

• it is interpreted in an execution context

This creates a situation where the boundary between data and code no longer exists.

In practice, this means it becomes possible to:

• modify the logic executed by the application

• inject a controlled fragment into the execution context

• achieve server-side code execution

Vulnerability analysis and exploit development

The public CVE description pointed to an issue in the Complex Calculation mechanism, but it did not include a ready-to-use exploitation scenario.

The analysis process covered several stages.

First, identifying entry points where user data reaches the calculation mechanism.

Then, observing application behavior for unusual input:

• syntax errors

• unexpected responses

• differences in data processing

At this stage, there was no direct code execution yet, but indicators emerged suggesting that data was being interpreted in an execution context.

Further test iterations made it possible to:

• determine how expressions are assembled on the server side

• identify the execution context

• prepare input data that enables control over this process

As a result, we developed a working exploit that confirms the possibility of unauthenticated code execution on the server.

Technical impact of the vulnerability

The confirmed scenario means that an external user can:

• influence how the application logic is executed

• cause code execution in the server environment

• gain access to application resources

Depending on the environment configuration, this may lead to:

• reading application data

• access to system files

• taking over the application context

• maintaining persistent access

Business impact

From an organizational perspective, the key point is that the vulnerability:

• exists in a publicly accessible function

• does not require authentication

• is difficult to detect in standard functional tests

In practice, this creates real risk of:

• data leakage

• disruption of business continuity

• system compromise

It is also important that this vulnerability is not in the infrastructure layer, but in business logic, which is rarely tested from a security perspective.

Why such vulnerabilities are overlooked

This case clearly highlights a systemic issue.

Features such as dynamic calculations are perceived as UX or business automation elements, not as potential attack vectors.

As a result:

• they are not covered by security testing

• they are implemented without full separation of data and logic

• they reach production without execution-context analysis

These are exactly the places where the most critical vulnerabilities emerge.

Recommendations

Short-term actions:

• update Everest Forms Pro to version 1.9.13 or later

• verify usage of the Complex Calculation feature

System-level actions:

• identify places where user data influences application logic

• eliminate dynamic execution of expressions based on input data

• introduce security testing that includes business logic

The key is to treat such mechanisms not as auxiliary functionality, but as potential code execution vectors.

Conclusions

The analyzed vulnerability is not an exception, but an example of a broader issue.

The boundary between data and code is one of the most important elements of application security. Breaching it leads directly to the most critical scenarios, such as Remote Code Execution.

In our testing, we confirmed that in this case that boundary was crossed, and the form mechanism can be used as an entry point for server-side code execution.

This shows that an effective security approach requires not only reacting to CVEs, but above all understanding how applications process data and where non-obvious attack vectors can arise.

About us

We specialize in application security testing, with a particular focus on business logic and non-standard attack scenarios.

Cases like the one described above are not isolated. In practice, we regularly identify vulnerabilities that stem not from infrastructure errors, but from non-obvious dependencies in application logic.

If you are interested in how such vulnerabilities are found in practice and what the analysis process looks like, we discuss this in more detail during our webinars.

Upcoming webinar on application security testing will take place on April 10, 2026.

If you would like to receive the recording or learn more, write to us.