WordPress 7.0.3 fixes server-side request forgery in URL validation that could allow link-local requests. Any feature that accepts a URL and fetches it from the server deserves review, especially on cloud hosts where link-local services may expose instance metadata or internal control-plane information.
Use this for WordPress imports, oEmbed, link previews, webhook testers, media sideloading, remote image tools, backups, uptime checks, migration plugins, payment integrations, custom REST endpoints, and cloud-hosted production sites.
Quick answer
Update Core, inventory server-side URL consumers, use a controlled external test service rather than real metadata endpoints, and verify that direct, redirected, DNS-resolved, encoded, IPv4, IPv6, and authenticated URL variants cannot reach loopback, private, or link-local destinations. Add network egress controls so application validation is not the only boundary.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Public allowlist | Controlled HTTPS canary | Approved destination succeeds with expected method and no secret headers |
| Redirect | Canary redirects toward a blocked address class | WordPress revalidates the destination and stops the request |
| Resolution | Hostname changes from public to disallowed address | Resolved destination is checked at connection time |
| Egress | Application attempts a disallowed private destination | Network policy denies the request even if application validation regresses |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch WordPress Core | Search Core, plugins, themes, mu-plugins, and custom endpoints for remote GET, POST, head, download, sideload, webhook-test, and preview behavior. | Every server-side URL consumer has an owner, allowed destinations, timeout, response limit, and logging path. |
| Inventory outbound URL consumers | Map allowed internet destinations, private services, proxies, DNS resolvers, redirect policy, timeout, response-size limits, and credential handling. | Direct and redirected requests to disallowed address classes fail safely. |
| Build a controlled destination fixture | Create a controlled canary endpoint that records source, method, headers, redirects, and a unique fixture ID without exposing secrets. | Allowed canary requests contain no cookies, authorization, or internal service credentials. |
| Enforce redirect and address checks | Test direct hostnames, redirects, alternate numeric forms, IPv6, DNS changes, user-info syntax, fragments, and mixed-case schemes in staging. | Independent network egress rules deny private and link-local destinations that WordPress should never reach. |
What to check first
- Search Core, plugins, themes, mu-plugins, and custom endpoints for remote GET, POST, head, download, sideload, webhook-test, and preview behavior.
- Map allowed internet destinations, private services, proxies, DNS resolvers, redirect policy, timeout, response-size limits, and credential handling.
- Create a controlled canary endpoint that records source, method, headers, redirects, and a unique fixture ID without exposing secrets.
- Test direct hostnames, redirects, alternate numeric forms, IPv6, DNS changes, user-info syntax, fragments, and mixed-case schemes in staging.
- Review firewall, proxy, DNS, cloud flow, application, and WAF logs for denied and successful outbound requests.
Field notes
- Never probe a real cloud metadata endpoint with untrusted or production content.
- Remove authorization, cookies, and internal headers before sending a canary request.
- Record the resolved address and redirect chain, not only the submitted URL.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Use a controlled canary URL in staging. Do not target real metadata services.
wp core version --extra
rg -n 'wp_remote_(get|post|head)|download_url|media_sideload' wp-content/mu-plugins wp-content/plugins wp-content/themes
# Correlate the fixture ID in proxy, DNS, firewall, and application logs.
Why this usually happens
- Validation can approve the original text while a redirect or DNS resolution leads somewhere different.
- Alternate address notation and IPv6 can bypass checks written only for familiar dotted IPv4 strings.
- Cloud link-local services are reachable from the server even though they are not reachable from a visitor's browser.
Decision rule
Do not release a URL-fetching feature when a redirect, resolution change, alternate address form, or proxy path can reach a disallowed network, or when outbound evidence cannot identify the requesting feature.
Production verification checklist
- Every server-side URL consumer has an owner, allowed destinations, timeout, response limit, and logging path.
- Direct and redirected requests to disallowed address classes fail safely.
- Allowed canary requests contain no cookies, authorization, or internal service credentials.
- Independent network egress rules deny private and link-local destinations that WordPress should never reach.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Patch WordPress Core
- Inventory outbound URL consumers
- Build a controlled destination fixture
- Enforce redirect and address checks
- Add egress policy and monitor
Mistakes to avoid
- Do not test against a real metadata service.
- Do not validate only the original URL before following redirects.
- Do not log complete URLs when they can contain tokens or personal data.
- Do not depend on a WordPress function as the only egress control.
Questions teams ask during testing
What is link-local in this context?
It is an address scope used on the local network segment and by some cloud platform services, not a normal public internet destination.
Is blocking 127.0.0.1 enough?
No. Private, link-local, IPv6, redirects, DNS behavior, proxies, and alternate address forms also matter.
Why add network egress controls after patching?
They provide a separate boundary if application validation or a plugin regresses later.
What to tell the client or owner
Share the feature and plugin version, submitted URL form, redirect chain, resolved addresses, request ID, proxy and firewall decision, headers sent, Core version, and expected allowlist.
When HandL WP should help
HandL WP can inventory URL-fetching features, build a safe canary, test redirect and resolution behavior, review cloud egress evidence, and add layered controls.
If this is active on a production site, audit WordPress outbound requests.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references