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://<my_webhook_url> | 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”
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.
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.
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.
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.
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.
'ello gals 'n guys (and everything inbetween, too, ofc )
first: to the actual technical feature at hand, that is nested in OPs posting (whitelisting specific webhook sink urls that are on local network ip ranges):
the whole concept described in the docs here is rather “coarse grained”(?) ( you could mention appropriate RFC’s, what about 192.168… or ipV6?)
i perceive this step now as a “blanket decision” (to use a binary switch that gets its default changed) which allows you to mark this topic as “covered our base” and shifts any “coarse grained” consequences of flipping the switch (back to the former default) to the customer
a “request for whitelisting specific decisions that currently cannot easily and responsibly be made by a customer” (to be able to work with the given coarse grained solution) gets met with further not optimally worded inquiries for “intentions”
i am beginning to question the reasons for further explanations in the context of LLMs … could it be a way to shift parts of the “requirements gathering phase” to the customer? If we describe everything adequately, it might be fed directly into your LLM much more easy, right? (but this surely is only a deranged afterthought of my troubled mind)
second: I arrived here (in this thread ) yesterday evening and would like to chime in, if i may. Have not been very active here the last months.
i perceive this switch of a default behaviour as a breaking change
we also, like other participants/readers, found out about this change by breaking processes that were working before the update
but to be fair: webhook-validation is mentioned explicitly in the upgrade notes for 2026.5.LTA … so … “someone” side.eyeing.someone.sitting.near.me did not thoroughly read the update notes
third: now to something else (which actually gave me the impulse to write):
Your request for more context would have appealed to memuch more, if you would have phrased it differently. E.g.: “I’m very interested in your perspective, because […]”
I think i understand your train of thought, but if you insist on something i instantly look at your request from a different pov, i guess.
Hey @daniel, thanks for the input about your experience with this breaking change, we will take it into account. You have a point about this setting being quite coarse grained. What I was trying to clarify, precisely, is which finer grains are relevant for the user.
Regarding a few other points you made:
i am beginning to question the reasons for further explanations […]
[…]
Your request for more context would have appealed to memuch more, if you would have phrased it differently. E.g.: “I’m very interested in your perspective, because […]”
I most definitely am not tricking users into gathering requirements for us or into giving us LLM prompts. However, I am indeed gathering use cases and requirements from users. My goal is to give PMs a clear picture of what the user wants to do with the product and what obstacle are they finding. Typically, most users are happy to elaborate on their use case if that means that it will be taken into account.
My phrase “I’m insisting on this because” was meant in the sense of “I’m repeating a question you didn’t acknowledge” and not “I’m demanding something out of you”. Maybe I could have phrased it differently, okay, I accept that.
I value feedback, but let’s not imply that there are any hidden intentions behind the interactions in this forum, okay? This is not a place to share the (I quote) “deranged afterthought of your troubled mind”.
first on-topic, off-topic very terse at bottom (i’ll try, promise ) .
As a sq-admin i want to be able to configure defined exceptions to the general decision (concerning validation of webhooks by on/off-switch) so that defined webhooks can reach their configured endpoints even when validation is on.
Also … I just realized, there is no info about the purpose of the wh-validation itself in the docs. So let me offer you the same question: what is your use-case for this webhook validation? I am genuinely interesten in the “so that”-part here. (protection from what?)
Also (sidenote) … it actually occured to me by accident that Austin registers as a sourcerer In dark-mode the profile-pic-icon in the post-heading just has translucent-ish “icon-badges”(?!) … in contrast to Andres prominently visible “big-fish” icon-badge. I needed to check the groups he is in to validate my perception. So, hi sourcerer-austin
i want selected webhooks to be able to reach their configured destinations so that they can be useful. So trying to answer your questions:
When the global binary switch for wh-validation is ON, i do not want this validation to happen for a defined set of webhooks. This could be (for example) a checkbox in webhook-CRUD-ui or a property containing a list of network addresses
Concerning the feature of “Webhook validation” itself:
I, myself, really would like to understand better, what is the actual goal of this feature itself? Is it - for example - to protect the system from webhooks that are not created by admins? What else crossed the mind of the deciding forces?
I did not find any meaningful info in the docs. So, i’d like to suggest that you suggest to someone that someone could please add meaning to the docs, too.
off-topic:
i think you are correct in pointing at my used language, in a way. Ty for factually answering to it anyways! By not filtering out unwanted(unfair?) suggestions, i was opening up my main message to get sniped because of an critical thought - that actually originated right in the moment of typing those letters into the keyboard - puked into the posting
If Ann is still around, maybe check in with her about how she would have reacted to my “provocative phrasing”, reading it will probably give her a chuckle first and afterwards a senseful reply of the same kind of reply like you gave me (maybe with more wittyness sprinkled over … which i would have liked … because thats why i mentioned something something deranged at all)
Thanks for elaborating, @daniel! This post is currently flagged for the PMs, let’s see if they can find some time to drop by and comment on what’s the intended usage of the feature and consider the requests for exceptions/granularity.
We are implementing a fix that will go out in the next patch release - expected in December (or earlier). In the interim, i can suggest you two options:
Switch back to the previous release - until December.
I understand this is not ideal, but we don’t want you to be blocked because of this issue. As a process improvement we’ve taken this feedback & we’ll be extra careful of such changes in the future.
Thank you all for your feedback and your patience.
We have a fix. It will be in SonarQube Server 2026.5.5, which we plan to release this week.
After you install this version, a new instance setting will be available. Use it to define which IP addresses and ranges SonarQube Server can send webhooks to. This lets you allow your internal addresses, for example a webhook host that resolves to a 10.x.x.x address.
(and everything inbetween, too, ofc 
)
first: to the actual technical feature at hand, that is nested in OPs posting (whitelisting specific webhook sink urls that are on local network ip ranges):
) yesterday evening and would like to chime in, if i may. Have not been very active here the last months.
) .
In dark-mode the profile-pic-icon in the post-heading just has translucent-ish “icon-badges”(?!) … in contrast to Andres prominently visible “big-fish” icon-badge. I needed to check the groups he is in to validate my perception. So, hi sourcerer-austin 
(maybe with more wittyness sprinkled over … which i would have liked … because thats why i mentioned something something deranged at all)
