Must-share information (formatted with Markdown): Version: 2026.5.1 Developer Deployment: Container what are you trying to achieve: Keep project webhooks working and not introduce security risks what have you tried so far to achieve this: Turning “sonar.validateWebhooks” off Hi, the key “sonar.validateWebhooks” seems to be on by default. Now, after upgrading to 2026.5.1 LTA our project Webhooks are not working any more: 2026.10.04 16:23:17 WARN ce[377705d6-ce31-4408-bb65-2f80dgc1ca0a][o.s.s.w.WebHooksImpl] Failed to send webhook 'MyWebHook' | url=https:// | message=Invalid URL: loopback, wildcard, link-local, site-local, multicast, cloud metadata addresses and addresses of the SonarQube server itself are not allowed for webhooks. So we have to turn off the validation. However: Disabling this setting can expose the instance to security risks. Where is the option to whitelist webhook URLs? I can only find the fragile on/off switch “sonar.validateWebhooks”

Hi, Thanks for the post. Where is the option to whitelist webhook URLs There isn’t an option to override sonar.validateWebhooks=false and allow list certain Webhook URLs. sonar.validateWebhooks is intentionally binary for security and simplicity. What’s your use-case for needing an allow list?

Hi, my use-case is that I want to enable webhooks validation for security reasons. However if I enable the validation our project webhooks won’t work any more. [image]

Hi @pst, my use-case is that I want to enable webhooks validation for security reasons. What I mean is: what is your use case for needing to allow some insecure URLs, but not others?

Use-case: Our SonarQube and Jenkins is running on 10.x addresses which are considered as "cloud metadata addresses(?). So I want to whitelist the Jenkins IP as allowed-only for webhooks.

Hey there, so if I understand correctly what you want is to whitelist certain IPs for webhooks so that a webhook sent to any other IPs will fail? Or perhaps what you want is the whitelist to control IPs for which webhook validation is not performed, even when it is turned on? Why not leave the toggle off? Before the update, local webhook validation was off by default. Now it’s on by default, but if you turn it off you’re not introducing any new security risks that weren’t there before. Finally, personally I find the error message Invalid URL: [local addresses] are not allowed for webhooks a bit confusing. It suggests that these addresses just are not eligible for webhooks, however, I understand that after disabling local webhook validation, it works. Is this correct? If you confirm this, I will loop the team in so that they can clarify this.

Yes, disabling the Flag solved the issue for our Jenkins from internal subnet.

Thanks @rmontag_ap. Could you also comment on what is it exactly that you want to whitelist? if I understand correctly what you want is to whitelist certain IPs for webhooks so that a webhook sent to any other IPs will fail? Or perhaps what you want is the whitelist to control IPs for which webhook validation is not performed, even when it is turned on? I’m insisting on this because I want to understand better what you’re asking before I pass this on to the PMs.

For me personally, it is not so much on the whitelisting it is more a problem on the wording, that’s why I have not reported as a bug in first place: When updating from 2026.4.1 to 2026.5.1, the behavior broke for us. I - as a system administrator for the installation - have no issue setting the flag to False to make it work with our Jenkins in our internal network, but the "Disabling this setting can expose the instance to security risks." text for the toggle will give me some headache, if I need to explain to our IT Security why I have disabled this setting and why it is safe to do so. So having this enabled and have the Jenkins on the Whitelist is technically the same as disabling this, but I need a different kind of argueing, why I did it this (risky?) way and not the ofter way. That is my personal motivation to ask for the whitelisting in first place.

[image] Andrés García Solares: I’m insisting on this because I want to understand better what you’re asking before I pass this on to the PMs. You say “Disabling this option can cause a security issue” and at the same time you ask why we can’t just disable it. That doesn’t make much sense to me. And of course, now that we know that there is a risk, we’d expect your software to enable us to properly handle this risk, which currently isn’t the case.

Validating Webhooks breaks our CI

SonarQube Server / Community Build

pst (Patrick S.) October 9, 2026, 8:33am 5

As the admin I want to have control which URLs are used as webhooks from our dev teams.

Bug in 2026.5.1: DevOps binding of project fails with 400 when binding unbound project

Topic		Replies	Views
Upgrade from 7.9.1 to 8.9 LTS - webhook ceased to work SonarQube Server / Community Build webhooks , 8-9-lts-upgrade	2	2193	June 7, 2021
New Webhook IP Address SonarQube Cloud	5	2333	September 25, 2019
Whitelist SonarCloud IPs for webhook server SonarQube Cloud webhooks	2	1021	April 19, 2021
Can't create webhook SonarQube Server / Community Build scanner , webhooks	0	909	June 2, 2021
Unable to create webhook in sonarcloud.io SonarQube Cloud webhooks , sonarqube-cloud	1	319	September 21, 2023

Validating Webhooks breaks our CI

Related topics