Analysis Report Folder Analysis cache/cost-calculator-builder_3.6.9 → cache/cost-calculator-builder_3.6.10 - CVE-2025-14757

I'll analyze this code diff for security vulnerabilities.

**Analysis Result:**

Vulnerability Existed: **no**

No CWE - N/A - cost-calculator-builder.php (lines 11, 20, 23)

Old Code:
```
* Version: 3.6.9
define( 'CALC_VERSION', '3.6.9' );
define( 'CALC_DB_VERSION', '3.6.9' );
```

Fixed Code:
```
* Version: 3.6.10
define( 'CALC_VERSION', '3.6.10' );
define( 'CALC_DB_VERSION', '3.6.10' );
```

Explanation:
This diff contains only version number updates from 3.6.9 to 3.6.10 across three locations in the plugin header and constant definitions. These are simple string replacements with no security implications. The changes do not:
- Modify any input validation or sanitization logic
- Alter authentication or authorization mechanisms
- Change data handling or storage practices
- Affect code execution paths or security controls
- Introduce or remove any potentially vulnerable code patterns

This is a routine version bump with no security fixes or security regressions introduced.

Let me analyze the provided code diff:

---

**Vulnerability 1:**

Vulnerability Existed: yes
FALSE POSITIVE

**Regular Expression Denial of Service (ReDoS) / Improper Input Validation - CWE-1025** - File: includes/classes/CCBFrontController.php - Lines 109-112

Old Code:
```
(No pattern matching existed in this version)
```

Fixed Code:
```php
preg_match_all(
    '/\[stm-calc\s+id="(\d+)"\]/',
    $post->post_content,
    $matches
);
```

Explanation:
This change introduces a potential ReDoS (Regular Expression Denial of Service) vulnerability if `$post->post_content` can contain untrusted or adversarial input. The regex pattern `/\[stm-calc\s+id="(\d+)"\]/` uses `\s+` which could be exploited with specially crafted content to cause excessive backtracking. However, the pattern itself is relatively simple and the risk is mitigated by the fact that this is WordPress post content (typically controlled by site administrators). The actual vulnerability risk is moderate because while the regex is safe from catastrophic backtracking, there's no validation or sanitization of the matched shortcode ID before casting it to int.

---

**Vulnerability 2:**

Vulnerability Existed: not sure

**Type Juggling / Weak Type Comparison - CWE-1025** - File: includes/classes/CCBFrontController.php - Lines 117-119

Old Code:
```
(New comparison in updated code)
```

Fixed Code:
```php
if ( (int) $shortcode_id === (int) $calculator->ID ) {
    $has_embed_calc = true;
    break;
}
```

Explanation:
The comparison uses strict equality (`===`) after explicit int casting, which is secure. The `preg_match_all()` returns string matches that are properly cast to integers before comparison. This is actually a security improvement as it prevents type juggling vulnerabilities. No vulnerability exists here - this is secure code.

---

**Vulnerability 3:**

Vulnerability Existed: no

**Removal of Stylesheet - Potential Security Improvement - CWE-829** - File: includes/classes/CCBFrontController.php - Line 93

Old Code:
```php
wp_enqueue_style( 'ccb-bootstrap-css', CALC_URL . '/frontend/dist/css/modal.bootstrap.css', array(), CALC_VERSION );
```

Fixed Code:
```
(Line removed)
```

Explanation:
The removal of the bootstrap CSS enqueue is a security improvement rather than a vulnerability fix. Reducing dependencies and enqueued resources decreases the attack surface. This is a positive security change, not a vulnerability being fixed.

Based on the provided diff, here is the security analysis:

---

**Vulnerability Existed: yes**
FALSE POSITIVE

**Improper Input Validation and Authorization - CWE-352 (Cross-Site Request Forgery (CSRF)) and CWE-434 (Unrestricted Upload of File with Dangerous Type) - includes/classes/CCBOrderController.php [424-494]**

**Old Code:**
```php
public static function complete() {
    check_ajax_referer( 'ccb_complete_payment', 'nonce' );
    
    $result = array(
        'status'  => 'error',
        'success' => false,
        'message' => __( 'Invalid data', 'cost-calculator-builder' ),
    );
    
    if ( empty( $_POST['data'] ) ) {
        wp_send_json( $result );
    }
    
    $data = null;
    if ( isset( $_POST['data'] ) ) {
        $data = ccb_convert_from_btoa( $_POST['data'], true );
    }
    
    $order_id = ! empty( $data['orderId'] ) ? sanitize_text_field( $data['orderId'] ) : null;
    // ... order completion logic
}
```

**Fixed Code:**
```
[Function completely removed]
```

**Explanation:**

The `complete()` function was vulnerable to multiple security issues:

1. **Insufficient Input Validation**: While the function checks for a nonce (`check_ajax_referer`), the order completion logic relies on user-supplied data from `$_POST['data']` that is decoded via `ccb_convert_from_btoa()`. The `order_id` is only sanitized with `sanitize_text_field()`, which is insufficient for numeric validation before database operations.

2. **Authorization Issues**: The function lacks proper capability checks (`current_user_can()`) to verify that the authenticated user has permission to complete a specific order. Any logged-in user could potentially complete any order by manipulating the `orderId` parameter.

3. **Information Disclosure**: The exception message is directly sent back to the client via `$e->getMessage()`, potentially exposing sensitive system information.

By removing this function entirely, the application eliminates these security risks. This suggests the order completion functionality was either deprecated, replaced with a more secure implementation elsewhere, or no longer needed in version 3.6.10.

Vulnerability Existed: yes
TRUE POSITIVE
Improper Input Validation (Type Confusion/Array Merge) - CWE-1025 - includes/classes/models/CalcOrders.php - Lines 1215

Old Code:
```php
return array_merge( $result, $calc_settings['formFields']['customEmailAddresses'] );
```

Fixed Code:
```php
if ( ! empty( $calc_settings['formFields']['customEmailAddresses'] ) ) {
    $result = array_merge( $result, $calc_settings['formFields']['customEmailAddresses'] );
}

return $result;
```

Explanation:
The original code was vulnerable to a type confusion/improper input validation vulnerability. The `array_merge()` function would fail or produce unexpected behavior if `$calc_settings['formFields']['customEmailAddresses']` was not an array (e.g., if it was null, a string, or another non-array type). Additionally, without the empty check, attempting to merge with potentially undefined or malformed data could cause runtime errors or unexpected behavior.

The fix adds a guard clause using `empty()` to verify that `customEmailAddresses` exists and is not empty before attempting the merge. This prevents type errors and ensures only valid array data is processed. The function now safely returns the `$result` array with only validated custom email addresses merged in, protecting against cases where the configuration data might be malformed or missing.

```
Vulnerability Existed: no
[No Vulnerability Detected]

Explanation:
This diff shows the removal of a nonce creation line for 'ccb_complete_payment'. The change itself is not introducing a vulnerability—it is removing nonce generation code.

However, this removal could potentially CREATE a vulnerability if:
1. The 'ccb_complete_payment' nonce was being used to validate payment completion requests
2. Removing its generation without updating the corresponding verification code would leave payment endpoints unprotected against CSRF attacks

Without seeing the complete context (whether the nonce verification code for this action was also removed, and what the payment flow looks like), this appears to be either:
- A legitimate cleanup of unused nonce generation, OR
- An incomplete fix that creates a CSRF vulnerability in payment handling

The diff alone shows code removal, not a vulnerable code pattern being introduced or fixed.
```

**Note:** To properly assess if this creates a vulnerability, I would need to see:
1. Whether `wp_verify_nonce( $_REQUEST['ccb_complete_payment'] )` or similar verification still exists in the codebase
2. What endpoints use the payment completion action
3. Whether this nonce was actually being validated in payment processing

If the nonce verification for 'ccb_complete_payment' still exists in the code but the generation was removed, this would be a **Cross-Site Request Forgery (CSRF) - CWE-352** vulnerability.