pr: [Nightly Fix] - Security - Enforce TLS Verification

[jewel-claw]

What

• remove the explicit sslverify => false overrides from outbound feedback and telemetry requests

Why

• these requests send user and site metadata to a remote endpoint
• disabling certificate verification weakens transport security and creates avoidable MITM exposure

Fix

• rely on WordPress default TLS verification for the deactivation and lead opt-in request paths

Confidence

• linted app/Hooks/Handlers/DeactivationHandler.php and app/Modules/Lead/LeadOptIn.php with php -l

[greptile-apps]

PR author is not in the allowed authors list.

[qodo-code-review]

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

Review Summary by Qodo

Enforce TLS verification in feedback requests

🐞 Bug fix

Walkthroughs

Description

• Remove sslverify => false overrides from outbound requests
• Enforce WordPress default TLS verification for security
• Affected deactivation feedback and lead opt-in requests
• Reduces MITM vulnerability exposure

Diagram

flowchart LR
  A["wp_remote_post requests"] -->|"Remove sslverify=false"| B["Enable default TLS verification"]
  B -->|"Applied to"| C["DeactivationHandler"]
  B -->|"Applied to"| D["LeadOptIn"]
  C -->|"Protects"| E["User metadata transmission"]
  D -->|"Protects"| E

Loading

File Changes

1. app/Hooks/Handlers/DeactivationHandler.php 🐞 Bug fix +3/-5

Remove SSL verification disables from deactivation requests

• Removed sslverify => false parameter from two wp_remote_post() calls
• First removal in handle() method for deactivation request
• Second removal in saveDeactivationFeedback() method for feedback submission
• Aligned array formatting for consistency

app/Hooks/Handlers/DeactivationHandler.php

---

2. app/Modules/Lead/LeadOptIn.php 🐞 Bug fix +2/-3

Remove SSL verification disable from lead opt-in

• Removed sslverify => false parameter from wp_remote_post() call in subscribe() method
• Enforces default WordPress TLS verification for lead opt-in requests
• Aligned array formatting for consistency

app/Modules/Lead/LeadOptIn.php

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Silent TLS request failures 🐞 Bug ✧ Quality

Description

After removing sslverify => false, these outbound requests may now fail on certificate validation,
but the code does not check wp_remote_post() results and (in the deactivation feedback AJAX path)
still returns wp_send_json_success(), silently dropping the feedback. This reduces
observability/debuggability of real-world TLS failures and makes it hard to distinguish “feedback
sent” vs “feedback skipped due to TLS error.”

Code

app/Hooks/Handlers/DeactivationHandler.php[R147-150]

        wp_remote_post(static::$apiUrl, array(
            'method' => 'POST',
-            'sslverify' => false,
-            'body' => $data
+            'body'   => $data
        ));

Evidence

The PR change removes the explicit TLS-bypass flag from the request args; if TLS verification
rejects the connection, wp_remote_post() can return an error object, but the code never inspects
the return and proceeds as if the operation succeeded (including returning JSON success for the AJAX
endpoint). The repo already demonstrates an established pattern of handling WordPress API errors via
is_wp_error() and has precedent for logging via error_log().

app/Hooks/Handlers/DeactivationHandler.php[147-155]
app/Hooks/Handlers/DeactivationHandler.php[35-39]
app/Modules/Lead/LeadOptIn.php[62-79]
app/Services/BackgroundInstaller.php[59-68]
app/Http/Controllers/ImportController.php[378-381]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Now that `sslverify => false` has been removed, outbound requests can legitimately fail on certificate validation. The current code does not check the `wp_remote_post()` return value and (for the deactivation feedback AJAX endpoint) still returns `wp_send_json_success()`, so failures are silently swallowed and feedback/opt-in events are dropped without any visibility.

### Issue Context
This PR’s intent is to re-enable default WordPress TLS verification. With verification enabled, certificate problems, missing CA bundles, or corporate TLS interception can produce `WP_Error` results.

### Fix Focus Areas
- Add response capture + `is_wp_error()` handling + lightweight logging (without blocking user flows)
 - app/Hooks/Handlers/DeactivationHandler.php[33-40]
 - app/Hooks/Handlers/DeactivationHandler.php[123-156]
 - app/Modules/Lead/LeadOptIn.php[62-79]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Overview

This PR implements a security improvement by removing sslverify => false from WordPress HTTP API calls. This change:

• Enables proper SSL/TLS certificate verification
• Protects against Man-in-the-Middle (MITM) attacks
• Uses WordPress default secure behavior

Changes Reviewed

The PR correctly removes insecure SSL verification bypass from 3 locations:

1. DeactivationHandler.php - handle() method
2. DeactivationHandler.php - saveDeactivationFeedback() method
3. LeadOptIn.php - subscribe() method

Files Reviewed (2 files)

• app/Hooks/Handlers/DeactivationHandler.php - Security fix applied correctly
• app/Modules/Lead/LeadOptIn.php - Security fix applied correctly

---

This is a security improvement. No issues found.