Gcore is a European cloud and CDN provider. On lg.gcore.lu, they run a public looking glass: a tool for running pings, traceroutes and BGP lookups from their network.
I discovered traceroute output rendered reverse DNS hostnames as raw HTML, so anyone who controlled the reverse DNS for an IP address could inject javascript into the looking glass, creating opportunities for an XSS attack. And I run a host that does exactly this.
For an XSS finding, this is one of my more modest ones. I wasn’t able to escalate it to anything major, the looking glass itself is unexciting, and it’s not a difficult bug to fix. I wouldn’t have written about it if Gcore had handled it differently.
After initially refusing my report, I demoed it in a conference talk while it was still live. Weeks later, a “customer support specialist” emailed:
Please be informed that publishing reports without our consent is a criminal act.
They refused to elaborate on which crime, or whether this was a threat, and refused to connect me with their legal team. They did fix the vulnerability eventually.
The vulnerability: PTR records rendered as HTML
For a while I thought this wasn’t possible, but DNS names are actually quite flexible. So I made this host, forward and reverse:
f.<marquee><h1/onmouseover=fetch`//s42.re/d.png`>marquee
<img/src='//s42.re/d.png'/crossorigin='anonymous'>.d.s42.re
It looks a little unconventional, as some DNS software disliked spaces and parentheses. Fortunately, you don’t need them in HTML. Some operating systems let you ping this, but not all.
I then had Gcore’s looking glass run a traceroute to this host. When displaying a traceroute, this usually shows the reverse name of each hop:
The giant scrolling text is my <marquee> canary: it means my hostname
was inserted as HTML into the page. You can also see my tracking pixel
being retrieved in the network panel.
The traceroute result is persistent and has a public link,
at lg.gcore.lu/results/<uuid>, so the victim doesn’t have to run the
traceroute themselves. I can just run it once, then send the link. My
payload executes in their browser.
There is no further escalation I could find. Gcore has numerous sensitive
logins and portals, but the ones I found are on gcore.com.
I didn’t find an escalation on gcore.lu the way I
have elsewhere. So this is a
persistent, one-click XSS on Gcore’s looking glass, a site that doesn’t
even have logins.
It should be fixed, but it’s not severe.
Reporting it
I reported it on March 28, 2026, through Gcore’s bug bounty program, with a description, payload, and a direct link to a saved result that executed the javascript. Within minutes, an automated reply came back:
Your submission has been automatically analyzed for eligibility under our Bug Bounty Program. […] Your report meets all our technical requirements:
- Clear, reproducible PoC demonstrating real exploitation.
- Target is in scope and impact is above minimum threshold.
- Policy compliance confirmed.
Your report is being forwarded for urgent internal validation and triage.
Two weeks later, a person refused it:
due to no information on how the vulnerability can be exploited on our resources and no POC provided, we have to refuse the report according to our Bug Bounty Policy
That was most curious, as I sent them a live persistent XSS link, that showed execution of my planted javascript, on their website. That certainly qualifies as a PoC to me.
I followed up twice: there certainly was a PoC, surely they were mistaken, but if they were sure about refusing it, I would publish. No response. So I included this in my presentation at RIPE92 on May 18, mentioning they refused the report and it was still live.
Some weeks later, on June 29, they suddenly mailed me again:
Please be informed that publishing reports without our consent is a criminal act. We strongly advise against such actions. Additionally, we will reevaluate your submission and inform you of the final decision.
A “criminal act” is quite the claim, so I asked for specifics. Which law, which country? Were they claiming I had already done something that was a crime? Was this a statement of intent to take legal action? I also asked that any answer come from someone with authority on legal decisions, rather than customer support.
After another reminder, a different support specialist replied:
any and every decision that we provided you with in this ticket is final and will not be changed […] Gcore’s legal position can be found on our website
Their website did not answer any of my questions, unsurprisingly.
What went wrong
The vulnerability itself is not exciting. The handling is exceptionally bad:
- They refused my report because of a missing proof of concept, even though I had included a public link to a working PoC.
- Months of silence while I sent several follow-ups.
- A vague “criminal act” threat, months after the report and only after I had gone public, that they then refused to elaborate on.
The fix for the vulnerability is simple, and I recommended this in my first report: HTML-encode the PTR hostnames and other DNS values before rendering them. For hardening, I recommended a Content-Security-Policy. And, they did actually fix it, some time after this mail exchange. It took me a moment to verify, because they also blocked my IP address from their looking glass.
Timeline
- March 28, 2026 - Reported to Gcore’s bug bounty program, with the payload and a link to a saved result that executed javascript. An automated reply the same day rated it High and said it met all technical requirements.
- April 11, 2026 - Gcore refused the report, citing “no POC provided”.
- April 11, 2026 - I replied that the proof of concept was in the report, that I would publish, and asked them to respond within 14 days.
- April 24, 2026 - Reminder that I would proceed with publication.
- May 18, 2026 - Demoed in presentation at RIPE92.
- June 29, 2026 - Gcore replied that “publishing reports without our consent is a criminal act” and that they would re-evaluate. I asked for details and a proper legal contact.
- July 14, 2026 - Gcore replied that every decision was final, pointed to their website for their “legal position”, and asked again for a proof-of-concept video.
- The looking glass was later fixed, and my IP address was blocked from the tool. They did not assign any bounty to my report.
I'm Sasha Romijn, an independent developer and internet infrastructure specialist in Amsterdam. I find security issues in internet infrastructure, usually in configurations, trust relationships, and cross-system behaviour that got overlooked. Some of my finds include taking over an event platform with a talk title, rooting OpenWrt via SSID, taking down a European network with a TLS certificate, rooting Home Assistant through MeshCore, and, some years back, compromising Apple keychain access groups.
Find me on Mastodon, Bluesky, or work with me.