Regression: cannot create webhooks targeting internal services after SSRF fix

[tandiljuan]

Describe the bug

A regression introduced after the fix for the "SSRF in Webhooks" vulnerability (GHSA-vwq2-jx9q-9h9f). The fix prevents creating webhooks that target internal services, private networks, or similar endpoints.

While the security fix is correct and fully appreciated, it also blocks valid use cases where webhooks need to reach internal services in controlled environments.

To Reproduce

Steps to reproduce the behavior:

1. Run Soft Serve on a recent version (after the SSRF fix from Nov 10, 2025)
2. Attempt to create a webhook pointing to an internal service (e.g., http://localhost or a private network address)
3. Observe that the webhook is rejected or not allowed

Expected behavior

It should be possible (optionally) to create webhooks targeting internal services when explicitly allowed by the user, for example via a configuration flag.

Environment (please complete the following information):

• OS: Linux
• Terminal: any
• Version: latest (post SSRF fix)

Additional context

A real-world example where internal webhooks are required can be found here: https://github.com/tandiljuan/dsd/tree/master/teal#test-whole-flow

Currently, the only workaround is to use a version prior to the SSRF fix: https://github.com/tandiljuan/dsd/blob/master/teal/swarm/repo.yaml#L17

Proposal

I fully support the security fix and have no objections to the default behavior.

However, I would like to propose adding an explicit opt-in mechanism (for example, a flag like --allow-internal) to allow webhook creation targeting internal services in trusted environments.

This would preserve secure defaults while enabling advanced or self-hosted use cases.

Thanks a lot for this wonderful project and all the work you put into it!

[aymanbagabas]

Hey @tandiljuan, thank you for reporting this one!

I am open to new proposals given that we discuss them first and discuss their ups and downs. A --allow-internal flag would work, but that would also affect the lfs package and make it vulnerable. I think instead, we can have an ssrf config section with default allow and deny lists. What do you think?

[tandiljuan]

Hi @aymanbagabas !

Of course, I totally agree with that. The --allow-internal was just an example to share the idea. IMHO, I think that webhooks to internal services should be denied by default and, if needed, must be explicitly enabled in the ssrf config section.

Something like?

ssh -p 23231 localhost settings webhook-internal true

[aymanbagabas]

I think something that affects security like SSRF should be part of the static configs in the config.yaml file and environment variables. If we implement that via ssh commands, then that implies runtime changes.

Instead, perhaps we can define a new SSRF section in the config with default allow list and deny list that gets populated when the config is missing the ssrf key.

ssrf:
  allow:
    - localhost
    - 127.0.0.1
  deny:
    - example.com
    - evil.com
    - 10.0.0.0/24

[tandiljuan]

Sounds great to me 👍

[ryannoblett]

Just adding +1, this breaks my use case. I need to be able to webhook to other internal systems. Whitelisting or manually enabling them is fine, but I need this functionality.