Is this really a serious report?

Sure, but you can take it however you like.

Asking because if you are modifying something on your client like described you are just accessing a different system which is accessible anyway (in this case a public GitLab pages system: https://about.gitlab.com/blog/gitlab-pages-update/) and there is no bypass involved.

What is getting reported here seems to make no sense but let's see if someone from the Kali team says something.

Hi, let me explain again:

When you ping the kali.org website, it responds from Cloudflare, because they currently have WAF protection. So, when anyone accesses it or tries to launch OWASP, XSS, SQLI, etc. attacks, it's stopped by Cloudflare...right? So, how come the instance in Google Cloud or the Ingress they have running doesn't have access rules from Cloudflare specifically, but rather they only have the proxy On, nothing else...but they don't have an ACL network policy that only allows traffic from Cloudflare. This means that by setting the proxy On, you should expect only traffic from Cloudflare to arrive, not directly to the public IP. The local modification I make to my host table...is logical...because what I'm trying to do isn't solve the problem with Cloudflare, it's to reach their public IP directly without this protection. Do you follow me?

Now reading the Gitlab Pages documentation... I understand, so using Cloudflare for PCs doesn't make sense... it's a bad implementation.

Thanks for your reply. To clarify, the behavior I'm reporting is that I'm able to access the same backend resource (which should be behind Cloudflare protections) without triggering any WAF/firewall controls, by directly reaching the origin or an alternate CDN endpoint.
If GitLab Pages is expected to be accessible regardless of the Cloudflare layer, then I understand this might be intended behavior.
Just wanted to flag it in case the exposure is not expected.

Thanks for the report.

Theres two differnet things at play here, kali.org & www.kali.org.

www.kali.org is a GitLab SaaS page - which as a result is completely static site (uses Hugo)
kali.org just redirect EVERYTHING to www.kali.org (not hosted on GitLab SaaS).

www.kali.org is just a 'shorten/pretty' URL to the kalilinux.gitlab.io domain.
kalilinux.gitlab.io has to be public, otherwise kali.org will not work for the public (other than staff, logged into GitLab).

In short, this is by design =).