fix: prevent use of local ips on webhooks

[Marc-Roig]

Fix for GHSA-v8wj-f5c7-pvxf

Prevents local ips to be used on webhooks.

User will see the following error if trying to use one:

Notes

V5 migration should be straightforward on the BE side, but we will need to check on the FE side if errors are being displayed on the Webhooks settings page

[Marc-Roig]

Let me know your opinion on this approach before I commit on some UI changes and api tests

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
contributor-docs	❌ Failed (Inspect)			Jun 18, 2024 10:36am

[derrickmehaffy]

I'll run some tests tomorrow but if nothing is on the internal IP+port it may not have a status code

[Marc-Roig]

@derrickmehaffy I believe the fetch api returns a 500 by default if the port is not found, or at least guarantees the status code is present on the response.

[Marc-Roig]

After a discussion with Alex , we decided to just prevent local ips to be used on webhook settings.

[Marc-Roig]

I am now working on some api tests, but logic should be ready (thank you Remi! 🚀 )

[remidej]

Tested ✅

[alexandrebodin]

Aren't we supposed to prevent this only in production env ?

[Marc-Roig]

oops, yes! I added the if case

[alexandrebodin]

🤔 I think we might want !== production in case we are doing tests for ex

[Marc-Roig]

done!

[ekozliaev]

Hi guys! I have a problem with Strapi 4.25.2 and above, seems to be due to this change.
If we use internal company addresses, they stop working as webhooks. For example, we have a test environment with an internal address like ourwebsite.test.int.ourcompany.com with an IP address like 10.123.324.11:443 and Strapi deployed to ourheadlesscms.test.int.ourcompany.com with the same IP address. In this case I cannot use webhooks in the test environment.

[Marc-Roig]

@ekozliaev would it be possible for you to set a host alias in the machine you have your strapi app deployed? A "solution" from our side would be to allow a flag to be set, but I would prefer avoiding so. This behaviour is disabled if running the app on development (NODE_ENV="development" or running yarn dev , but allowing local ips on production environments can lead to security issues.

[ekozliaev]

@Marc-Roig Sorry, I don't really understand what you mean by host alias. Do you mean "etc/hosts"? We run all this in k8s. Yes, I know about NODE_ENV as a workaround, for test environments it might still work somehow. How about a specific configuration of allowed domains for the URL field?

[ekozliaev]

Just to clarify. We have Strapi deployed inside the company network for all environments including production. The url that we trigger via webhook restarts the build in the container in which our frontend is deployed (something like a preview of changes in the CMS). This frontend is also deployed inside the company network.

[strapi-bot]

This pull request has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/webhook-validators-url-is-not-supported-because-it-isnt-reachable-over-the-public-internet/40361/4

[MrMarci666]

Hi all,

Why would you do this kind of validation? It doesn't really make sense in my eyes. We are using Strapi to communicate with the CI / CD software using host.docker.internal "magic" host. Now it is not possible anymore. Is there a way to undo this? I don't think that this would be helpful for anyone.

After a discussion with Alex , we decided to just prevent local ips to be used on webhook settings.

@Marc-Roig Why is that? I don't want to publish the CI / CD software's endpoints to the public internet, it doesn't make any sense.

Update:
Btw, after saving with a dummy URL, you can actually edit the url column in the strapi_webhooks table, so you can make it work with local IPs as well. I don't understand this frontend validation that you built there, but maybe I am missing something here.
Update 2:
Editing in the DB unfortunately didn't work; the webhook was never called so workaround was creating a public endpoint on the CI / CD software with an IP filter... This is my worst case scenario btw. because now this endpoint is also a security risk, and it shouldn't exist.

[alexandrebodin]

@MrMarci666 This was done for security reasons only. you can read the overall concept of the attack vector this leaves open if you allow anyone to put localhost domains here https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

Registering a webhook programmatically avoids the Human factor and allows you to be as safe/unsafe as you decide to. It's controlled by you and you can set the url you want like that. that's why we only validate UI user inputs

[MrMarci666]

@alexandrebodin Thank you for explaining the decision! 😄

We will register a webhook programmatically then.

[adconk]

@alexandrebodin For security reasons? I had to create a new public url just to get around this. No other reason. I now have less security by exposing more of my private hosted network.

[alexandrebodin]

@adconk Can you share your usecase ?

Here are a few options depending on whether you really want to expose internal access or not

• As suggested above you can programmatically register the webhook if you really want to use an internal ip as it's unsafe when users can do it themselves from the UI.

• You can configure private hostnames to do routing inside local private networks. you can then make sure request will go to a specific ip that you can protect correctly.

• You can programmaticaly listen to events to do whatever you want

[adconk]

Hi, we run Strapi as one container in an AWS ECS cluster. It's a backend to our web application and Unity3d application that runs on an AR headset. We use it for authentication, data schema API, and the webhooks trigger other python flask services related to medical image segmentation and machine learning also in our ECS cluster. We store de-identified medical images that were segmented and converted to 3d mesh files that we use with Neurosurgeons with our Augmented Reality headsets and client application that talks to our backend. I imagine you don't see too many uses like this, and we've been on the fence about whether to keep using Strapi. We do not store any PHI data in Strapi.

…

On Wed, Oct 16, 2024 at 7:55 AM Alexandre BODIN ***@***.***> wrote: @adconk <https://github.com/adconk> Can you share your usecase ? Here are a few options depending on whether you really want to expose internal access or not - As suggested above you can programmatically register the webhook if you really want to use an internal ip as it's unsafe when users can do it themselves from the UI. - You can configure private hostnames to do routing inside local private networks. you can then make sure request will go to a specific ip that you can protect correctly. - You can programmaticaly listen to events to do whatever you want — Reply to this email directly, view it on GitHub <#20487 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOLLQNFFKTV5VZSYBYBXPLZ3ZH3FAVCNFSM6AAAAABJCSCA2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWGU4TQNZVGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alexandrebodin]

Hi, we run Strapi as one container in an AWS ECS cluster. It's a backend to our web application and Unity3d application that runs on an AR headset. We use it for authentication, data schema API, and the webhooks trigger other python flask services related to medical image segmentation and machine learning also in our ECS cluster. We store de-identified medical images that were segmented and converted to 3d mesh files that we use with Neurosurgeons with our Augmented Reality headsets and client application that talks to our backend. I imagine you don't see too many uses like this, and we've been on the fence about whether to keep using Strapi. We do not store any PHI data in Strapi.
…
On Wed, Oct 16, 2024 at 7:55 AM Alexandre BODIN @.> wrote: @adconk <@adconk> Can you share your usecase ? Here are a few options depending on whether you really want to expose internal access or not - As suggested above you can programmatically register the webhook if you really want to use an internal ip as it's unsafe when users can do it themselves from the UI. - You can configure private hostnames to do routing inside local private networks. you can then make sure request will go to a specific ip that you can protect correctly. - You can programmaticaly listen to events to do whatever you want — Reply to this email directly, view it on GitHub <#20487 (comment)>, or unsubscribe <github.com/notifications/unsubscribe-auth/AAOLLQNFFKTV5VZSYBYBXPLZ3ZH3FAVCNFSM6AAAAABJCSCA2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWGU4TQNZVGA> . You are receiving this because you were mentioned.Message ID: @.>

Hooo indeed that's pretty uncommon but very interesting.

So with Service discovery on AWS you can create custom private domain names for your private network service. if you do that then you can use those domain names in the webhook urls instead of ips. If you are confident no user would try to mess up the config this will work and also make url config more readable and less brittle to IP changes

Edit: this solution will not work correctly. Using programmaticaly registered webhooks will be the only way to set unsafe URLs in a safe way

[lhsanghcmus]

Seem create the private domain name is not the solution because we are using isLocalhostIp from package is-localhost-ip (

strapi/packages/core/admin/server/src/controllers/webhooks.ts

Line 41 in 8341690

const isLocalUrl = await isLocalhostIp(parsedUrl.hostname);

). If we put the domain, the package function will query dns (https://github.com/tinovyatkin/is-localhost-ip/blob/master/index.js#L85) to get the ip address from domain and check the ip whether local ip

[alexandrebodin]

@lhsanghcmus very good point.that's not a valid workaround actually you are totally right and As I said earlier it makes sense as it would still be unsafe 👍

So except from programmaticaly registring to avoid the attack vector or using a webhook delivery service (but opens your service to the internet) there are no other obvious workaround that would be considered safe in production.

[skifahrer]

Hello @alexandrebodin

I tracked down this PR to figure out why our Strapi admins (non-coders) were unable to add new local webhooks.

I’m concerned that this change is a breaking change for many users and it is not just a bugfix. Particularly for those deploying Strapi locally in environments like Kubernetes. This restriction now prevents Strapi from contacting local services via webhooks, which is crucial like for us, as we use Strapi webhooks to notify Next.js when content is updated. Now we have to "hack" our setup by directly changing the url in database to bypass the validation.

While I have read your previous responses and understand that there can be security risks, it would be nice to have an option (for example, in Strapi security policies) to bypass this restriction.

[alexandrebodin]

It's a fair point @skifahrer, sadly it was the only way to fix the critical security issue and all appplication doing this (even if intentionnaly) are considered unsafe.

I'm on the fence about adding an option to allow sth that is considered a cirtical security issue even if the users wants it. Right now I think it would be unresponsible from us to allow it 😞.

I think we could allow a "custom validation" function instead so we delegate the validation responsibility instead of allowing sth unsafe. it would be safer by default and would require a bit more of intentional work to skip this validation.

In the meantime, here is a example to do it programmaticaly to avoid doing messy things.

  const webhook = await strapi.db.query('strapi::webhook').findOne({
      where: {
        name: 'some_internal_webhook',
      },
    });

    if (!webhook) {
      strapi.get('webhookStore').createWebhook({
        name: 'some_internal_webhook',
        url: 'http://localhost:1337/webhook',
        events: ['entry.create', 'entry.update'],
        headers: {},
        enabled: true,
      });
    }

[axelpezzo]

@alexandrebodin the solution you suggested not works, I got the error "strapi::webhook" not found.
I can't find any occurrence of createWebhook method inside the documentation, could you please add more info?

I really need this: I have the target website over VPN for security reason. Now as workaround we need to disable the entire cache of the frontend because we can't do it manually triggering the webhook, pretty bad and I'm not the only one as I can see.

*** UPDATE ***

I published the URL over the public Web but unfortunally I can still see the error.
The CMS is over a VPN and is not public, but the Frontend now it is so why I still see the error?
Is due to the fact that all the infrastructure is over k8n?

[alexandrebodin]

@axelpezzo What version of strapi are you using ? this code snippet should go into your boostrap function in your strapi app. We validated it's working as expected in v5 latested versions.

[axelpezzo]

I'm using the 4.25 and I got this error runnig your script inside the bootstrap:

Error: Model strapi::webhook not found

[alexandrebodin]

const webhook = await strapi.db.query('strapi::webhook').findOne({
      where: {
        name: 'some_internal_webhook',
      },
    });

in v4 it would be query('webhook') directly

[bennyhoyer]

@alexandrebodin For security reasons? I had to create a new public url just to get around this. No other reason. I now have less security by exposing more of my private hosted network.

This is really funny because in this case the error message is also not precise.
Because if you create a new URL the test will also block your URL, because if it still resolves to the same local IP the error will still occur.
I assume the strapi team wanted to block IP addresses and localhost with port, but somehow missed the case that multiple domains can point to the same server and IP address.

[cwilso03]

I'm hitting this problem, too. In my use case, I have Strapi in a Docker container, and a web server (Astro) running in another container. I'm trying to use the webhook functionality to have Strapi kick off an Astro build, by calling to the Docker service name.

Ok, so I have to use a public URL. Well, I changed the webhook to use the public URL (which will then route the webhook call to the NGINX reverse proxy which is also running as a Docker container) but I still get the error about the URL not being reachable on the public Internet. Digging through the code of this pull request, I can see why, in packages/core/admin/server/src/controllers/webhooks.ts, on line 41:

            const isLocalUrl = await isLocalhostIp(parsedUrl.hostname);

The isLocalHost() method (from the is-localhost-ip NPM package) checks (among other things) to see if the hostname resolves to a non-routable (i.e., private) IP address. In my case it does, because I configured a Docker network alias to my NGINX reverse proxy to match the public-facing FQDN. I did this so the various Docker containers in my application stack don't need to hairpin route outside of and then back into NGINX. But, since the Docker-internal subnet is non-routable, isLocalUrl() returns true.

So, the test is flawed, as it doesn't check to see if the URL is also publicly routable. That aside, the code informs a simple workaround, on lines 35-37, just above the culprit line 41:

          if (process.env.NODE_ENV !== 'production') {
            return true;
          }

The workaround is to simply set NODE_ENV to any value other than production, which I'm now doing in my docker-compose.yml file.

[MrMarci666]

@cwilso03 I understand the frustration, but I really recommend not running Strapi with NODE_ENV !== 'production' just to get around this validation.

That environment flag controls much more than just a simple check — it affects error handling, caching, logging, and general runtime behavior across the entire Node.js ecosystem. Running production systems in non-prod mode introduces security and stability risks that are much harder to detect later on.

And to the @strapi team: this is a clear example of what happens when a security fix is implemented too rigidly and without flexibility.

Many of us are using Strapi in isolated environments — Docker networks, Kubernetes clusters, private VPCs, etc. Blocking internal URLs from the UI with no config option or escape route breaks essential workflows for CI/CD, build processes, preview deployments, and more.

I understand the SSRF concerns — they’re valid. But the solution shouldn’t force teams to compromise the architecture of their infrastructure. In fact, workarounds like editing the database directly, exposing internal services publicly, or disabling production mode create more serious vulnerabilities than the one you were trying to prevent.

If the goal is secure defaults, that’s great — but please give us a way to override them responsibly. A configuration setting, environment variable, or custom validation hook would solve this cleanly without encouraging unsafe practices.

At the end of the day, we need a balance between security and usability. This change, as it stands now, doesn’t provide that.

[cwilso03]

@MrMarci666 I agree; it's a sub-optimal solution.

The only way an attacker could leverage this for SSRF is if they could modify the webhook URL. Unless I'm missing something obvious, the only way they could do that is if they had already hacked an admin account, at which point the site admins have bigger problems.

If the concern is a new webhook could be created via ReST (which, apparently, this PR doesn't even address), then just provide an admin option to disable that API endpoint. Problem solved.

[adconk]

I concur with @MrMarci666 and @cwilso03. If I could go back and make my services that are triggered by webhook non-public again, I would in a second. They shouldn’t be public but I had to make that change as a workaround. I found this change very disruptive and detrimental to my tech stack. Not just usability, but overall security.

[derrickmehaffy]

Cc @alexandrebodin