I use https://detectify.com/ to check my website of any possible security issue, the site gives me that /.well-known /acme-challenge/ could be an XSS so that an attacker can inject JavaScript into the victim’s browsers, which will execute under the vulnerable domain.
If putting some HTML in the URL results in it being echoed back to the viewer as HTML, that’s potentially an XSS risk. When you put <h1>something in the URL, do you see <h1>something when you view it, or do you see “something” rendered as a heading? If the former, everything is probably fine; if the latter, there’s potentially a problem and you should investigate it further (try <script> etc).
That’s unlikely to be related to Let’s Encrypt, though. /.well-known/acme-challenge/<h1>something isn’t a valid ACME HTTP-01 challenge URL, so if you request it, you’re most likely hitting your webserver’s error page. It’s easy enough to imagine a custom error page with some content like “Page [URL] not found” that could be vulnerable to reflected XSS if it’s implemented incorrectly.
This can be used to defeat Content Security Policy, if you have that enabled.
If there were an actual XSS vulnerability in your web application, an attacker might add something like <script>window.location = 'https://some-phishing-site.example.com';</script>. Without Content Security Policy blocking unsafe inline scripts this would work, but with a proper Content Security Policy this would be blocked by browsers.
However, it’s likely your Content Security Policy would trust JavaScript files served from your own domain, so the attacker could change that to <script src="/.well-known/acme-challenge/window.location%20%3D%20%27https%3A%2F%2Fsome-phishing-site.example.com%2F%27%3B%2F%2Fx"></script> and defeat that security measure.
(You’d think the fact that this file is served with a different mimetype would prevent it from being interpreted as JavaScript, but unfortunately browsers are very tolerant of JavaScript being sent as text/plain due to historical reasons.)
Now, you have to use Content Security Policy for this to even be an issue, and even if you do it’s minor in the grand scheme of things, but comprehensive security scanners are right to point out reflection of user input like this even if it is sanitized.
I understand now that because the script is not executed but only echoed in the browser, then that /.well-known/acme-challenge/ is save, and not an xss risk.