# Refuse cloud-metadata requests in WordPress: the fix that starts on

How to refuse plugin requests to cloud-metadata addresses in WordPress, let your own services through, check it is working, and undo it.

By M Asif Rahman, Oct 25, 2026. Updated Nov 2, 2026.

To stop plugins from reaching a cloud server’s credentials, refuse their requests to the cloud-metadata address. BetterShield does it with one fix, **Server detail protection**, and it is the only hardening fix that is on from the start. This guide covers what a metadata address is, what the fix refuses and what it lets through, the one option it has, how to check it is working, and how to undo it.

It sits with the other server-level changes in [WordPress hardening](/blog/wordpress-hardening/), which explains how every fix previews, applies and undoes. This post goes deeper on the one that needs nothing from you, and it pairs with [what a WordPress security plugin sends and receives](/blog/what-wordpress-security-plugins-send/), which covers the other direction: what leaves your site.

## Quick summary

- **Server detail protection** refuses a request made through WordPress to the addresses where a cloud server keeps facts about itself, and on several clouds its credentials, whichever plugin makes the request.
- It is on from the start: switched on when BetterShield is activated, and by the update that brought it on sites that already ran BetterShield. Every other hardening fix starts off.
- It lets requests into your server’s own network through and notes each one in the activity log, so a search or cache service on a private address keeps working.
- It sees only requests made through WordPress. A plugin that opens its own connection goes around it.
- It is under **What the site reveals** on **BetterShield › Protection › Hardening**, and the undo never expires.

## Why a metadata address matters

A cloud server answers a request to its metadata address with facts about itself. On several clouds that includes the credentials the server runs under. Nothing on the internet can reach that address, but the server itself can.

That is the catch. A plugin that fetches whatever address it is handed, a link preview, an image importer or a webhook tester, can be pointed at the metadata address by someone who types it into the field. The server then asks itself, and the answer goes to the person who typed. Security teams call this class of mistake server-side request forgery, and [OWASP’s page on server-side request forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) describes it in full. The common address, 169.254.169.254, belongs to the range that [Wikipedia’s entry on link-local addresses](https://en.wikipedia.org/wiki/Link-local_address) explains: a range meant to be reached only from the same machine or network segment.

The fix does not try to find the weak plugin. It removes the destination, whichever plugin makes the request.

## What the fix refuses, and what it lets through

- **A request to a cloud-metadata address,** made through WordPress by any plugin. In the fix’s own words, that is “169.254.169.254 and the rest of the link-local ranges, 100.100.100.200, fd00:ec2::254 and metadata.google.internal, written out, spelled another way, or as a name that resolves to one of them.”
- **A redirect that leads to one of them,** so an address that answers “go there instead” does not get around it.
- **Requests into this server’s own network are let through.** They are never refused, so a search, cache or other service on a private address keeps working. Each is noted in the activity log once a day for each address and plugin. Requests to this site’s own address, which WordPress makes to run its schedule, are left alone.
- **The plugin is told why.** The refused request gets a message that says it was going to a cloud-metadata address, where a cloud server keeps its credentials, and that the activity log names the plugin that made it.
- **The store’s cart and checkout are left alone,** and it stands aside in safe mode.

It writes no files, so it works on any web server. That is the difference from the fixes that write rules into .htaccess, such as [hiding sensitive files](/blog/hide-sensitive-files-wordpress/).

What it does not reach is just as plain: it sees only requests made through WordPress. A plugin that opens its own connection goes around it, so treat it as one layer, next to keeping plugins updated and removing the ones you do not use.

## Set it up

There is nothing to do to turn it on. Open **BetterShield › Protection › Hardening** and find **Server detail protection** under **What the site reveals**. The row shows **On since** and **Undo never expires**. After the update that brought it, the release panel on the Overview says one of the things it added is already switched on, and lists this fix first: “On after this update.”

The one option is a list of addresses to let through. The field shows only while the switch is off, so to change it:

1. Turn the switch off.
2. Type the addresses in **Addresses to let through**.
3. Press **Preview the change**. It lists what applying would do, including “Lets these through, neither refused nor noted:” with your list. Nothing changes.
4. Turn the switch on again.

| Option | What it does | Default |
|---|---|---|
| **Addresses to let through** | Host names, addresses or ranges such as 10.0.0.0/24, separated by commas, for something you run that a plugin has to reach. What is listed is neither refused nor noted. Up to 50 entries, a range no wider than a /8 (a /16 for IPv6), and no wildcards. | Empty |

An entry it cannot use is named before anything changes, with a message that it is not a host name, an address or a range that can be let through.

**Monitor first** cannot watch this fix in advance. While it is off, its panel points you to the preview instead.

You can also change it from other places:

- **WP-CLI:** `wp bettershield harden cloud_metadata --undo --user=admin` switches it off, and `wp bettershield harden cloud_metadata --allow=search.internal,10.0.0.0/24 --user=admin` switches it on with a list. Add `--dry-run` to preview. To change the list from the terminal, undo it first. The [WP-CLI commands](/docs/wp-cli-commands/) guide has the rest, and [WordPress security from the command line](/blog/wordpress-security-wp-cli/) walks through them.
- **An AI assistant** allowed to make changes can apply it. Taking it off needs a plan you agree to.

## What it can break, and how to undo

- **A plugin that needs one of these addresses.** Its request is refused with the message above, and the activity log names it. Let the address through (switch off, list it, switch on), or leave the fix off.
- **Requests into your server’s own network** are not broken. They go through and are only noted.
- **The store’s cart and checkout** are not touched, because the fix stands aside there.

To undo, turn the switch off. A request to a cloud-metadata address then goes out again, and requests into your server’s own network are no longer noted. “Hardening undone” is logged, rated High because it was switched off by hand, so [email alerts](/docs/email-alerts/) send it as it happens. With **Ask for my password before removing a protection** on, undoing it asks for your password.

Once you switch it off, it stays off: later updates and reactivating BetterShield do not switch it on again. Safe mode pauses it, and deactivating BetterShield stops it.

## Check it is working

- **The row.** **On since**, **Undo never expires**, and the note that this fix “has no effect a page view can check, so it is reported from your settings.”
- **The activity log.** “Hardening applied” when it was switched on, at activation or at the update. “Request to a cloud-metadata address refused” (Medium) names the plugin that made the request, and “Request into this server’s own network” notes one that was let through. See [Activity log](/docs/activity-log/).
- **Findings.** It has no finding of its own. While it is on, **Some protections that are switched on are not working** (Medium) names it if it reads as on but is no longer in force, for example because another plugin took it off.
- **From the terminal.** `wp eval 'var_dump( wp_remote_get( "http://169.254.169.254/" ) );'` prints an error carrying the refusal straight away, and the activity log records it.

On a network of sites, each site has its own switch.

## Recommended settings

We recommend leaving it on for every site. If one plugin really needs a metadata address, list that address under **Addresses to let through** rather than switching the whole fix off.

| Site | What we recommend |
|---|---|
| A site on a cloud server | Leave it on. These addresses are where the server keeps its credentials. |
| A site whose search, cache or other service runs on a private address | Leave it on. Those requests already go through; list the address if you would rather they were not noted. |
| Agency or many sites | Leave it on everywhere, and read the activity log for refused requests after adding a new plugin. |

## Frequently asked questions

### Do I need to turn this on?

No. It is switched on when BetterShield is activated, and by the update that brought it on sites that already ran BetterShield. Open **BetterShield › Protection › Hardening** and look for **On since** on the row to confirm.

### Will it stop my search or cache service on a private address?

No. Requests into your server’s own network are never refused. They go through, and each is noted in the activity log once a day for each address and plugin.

### Does it block every plugin from reaching those addresses?

Every plugin that makes its request through WordPress. A plugin that opens its own connection goes around it, which is why we describe it as one layer and not a complete answer.

### A plugin stopped working after the update. What do I check?

Open the activity log and look for “Request to a cloud-metadata address refused”. It names the plugin. If that plugin really needs the address, add the address under **Addresses to let through**, or leave the fix off.

### Can I switch it off for good?

Yes. Turn the switch off, and it stays off: later updates and reactivating BetterShield do not switch it on again.

## Conclusion

One fix that is already on closes a quiet route to a cloud server’s credentials: plugin requests to a metadata address are refused, your own services are let through, and the activity log names any plugin that tried. Check the row for **On since**, glance at the activity log after adding a new plugin, and list an address only if something you run needs it.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The docs cover the fix in full: [Cloud-metadata block](/docs/refuse-cloud-metadata-requests/) and [Hardening](/docs/hardening/).