CVE-2024-13904 is a medium severity (CVSS 5.3) blind server-side request forgery in the Platform.ly for WooCommerce plugin, in versions up to and including 1.1.6, through the hooks function. Unauthenticated attackers can make the server send requests. Update past 1.1.6. Check the changelog for the fixed release.
What's affected
- Platform.ly for WooCommerce, all versions up to and including 1.1.6.
The record does not name a fixed version, but it links a code changeset. Check the plugin page for a release newer than 1.1.6.
How to check if you're exposed
Run the command below from the WordPress root with WP-CLI, or check the Plugins or Themes screen in the dashboard. Check staging, development and multisite networks too.
wp plugin list --format=table | grep -i platform
Compare the version shown to the affected range above. If you manage many sites, run the same check on each one.
What to do now
- Update the plugin to a release newer than 1.1.6.
- Restrict outbound traffic from the web server to what the site needs.
- If you do not use Platform.ly, remove the plugin.
- Look up CVE-2024-13904 on its Gold page to see the current details and any fix information.
- Scan your sites again after changes. Our free in-browser dependency scan covers package manifests such as package.json and requirements.txt, so use it for the build tooling around your site as well.
Why it matters
Blind SSRF means the attacker does not see the response directly, but the server still makes the request. The record says this can be used to query and modify information from internal services. That depends on what internal services accept unauthenticated requests.
Egress filtering is the strongest defense, and it works for every plugin on the host at once.
This CVE is a server-side request forgery flaw (CWE-918, Server-Side Request Forgery). Nothing in the record says it is exploited in the wild, and it is not marked as listed in CISA's Known Exploited Vulnerabilities catalog. That is a snapshot, so keep checking.
Server-side request forgery turns your web application into a proxy. The attacker supplies an address and your server makes the request, from inside your network, with your network permissions.
That matters because internal services often trust anything on the inside. Cloud metadata endpoints, admin panels bound to localhost and internal APIs may all answer a request that would never be allowed from the internet. The defenses are allowlisting the hosts a feature may contact, blocking private and link-local address ranges, and restricting outbound traffic from web servers at the network level.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What does blind mean?
The attacker does not get the response body back, but the request is still sent.
Which function is affected?
The hooks function.
Sources
Note: these pages could not be retrieved when this post was written, so statements rest on the CVE record text. Check the vendor pages for the latest version information.
Last reviewed: 19 October 2026.
