What We Learned from a Multi-Service Vulnerability Disclosure | RIPE Labs

Eleonora Petridou

What We Learned from a Multi-Service Vulnerability Disclosure

Eleonora Petridou(RIPE NCC staff)

Eleonora Petridou

Eleonora is Chief Information Security Officer at the RIPE NCC and is responsible for ensuring that the RIPE NCC maintains necessary levels of Information security and compliance with best practices and applicable regulations. More

Contributors:

Virgile Uytterhaegen

8 min read — 10 Jun 2026

ripe

security

operational

Click to like, and right click to unlike this article.

Share

Share

X/Twitter<br>LinkedIn<br>Facebook<br>Mastodon<br>Vkontacte<br>Telegram<br>Whatsapp<br>Email<br>Copy link

More

A series of vulnerabilities reported through the RIPE NCC bug bounty programme revealed weaknesses across multiple services and highlighted the risks posed by vulnerability chains. We look at how the issues were addressed, and what the disclosure taught us about handling complex security reports that span teams and systems.

In February 2025, Internet infrastructure specialist Sasha Romijn reported a series of vulnerabilities affecting RIPE NCC applications through our bug bounty program. The program provides a structured and responsible channel for security researchers to report vulnerabilities to us, strengthening RIPE NCC’s security posture through continuous external testing.<br>Sasha’s findings emerged from a broader effort to explore how seemingly low-risk flaws in Internet-facing tools and services can sometimes be combined into attacks with much more significant impact. Several of the reported issues would have been assessed as moderate risk in isolation. However, Sasha demonstrated that they could be combined into attack chains that expanded an attacker's privileges and access beyond what any single vulnerability would allow.<br>This helped us to identify and address weaknesses across multiple applications and improve our understanding of how such vulnerabilities can interact in complex environments. It also highlighted shortcomings in the way we handled parts of the vulnerability disclosure process itself. In this article, we will take a look at how we addressed the vulnerabilities that were identified, and we’ll also talk about important lessons we learned along the way on how our vulnerability disclosure processes need to improve.<br>We are grateful to Sasha for reporting the issues responsibly, working with us throughout the remediation process, and later sharing her research with the wider community in a constructive way. You can read several posts on the topic from Sasha over on her blog and we really do recommend watching her RIPE 92 presentation, which made for a great opening presentation for the meeting.

Addressing the reported vulnerabilities<br>The reported issues fell into three broad categories: Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and overly permissive Certificate Authority Authorization (CAA) records. Taken individually, each had a different impact and required a different remediation. What made them significant was the way they could be combined.<br>Cross- Site Scripting (XSS)<br>The first vulnerabilities reported were Cross-Site Scripting (XSS) issues in RIPE Atlas and RIPEstat. XSS vulnerabilities allow an attacker to inject code into a resource they control and execute that code when another user interacts with it.<br>In this case, the XSS was possible in two places:<br>Through the NSID field in RIPE Atlas measurements<br>Through the DNS check display of version.bind in the old RIPEstat UI<br>To illustrate the issue, the screenshots below show how maliciously crafted data could be used to inject content into legitimate RIPE NCC services:<br>By tricking a user into visiting a legitimate RIPE Atlas or RIPEstat page containing the vulnerable components, an attacker could execute malicious code within the context of that user's browser. From there, the attacker could steal the user’s cookies and get their hands on the crowd_token.key cookie that authenticates users to RIPE NCC services like RIPE Atlas, the LIR Portal and others.<br>The RIPE Atlas and RIPEstat teams fixed these vulnerabilities quickly by improving the sanitisation and escaping of untrusted input. The work also reinforced the value of Content Security Policy (CSP) headers, which provide an additional layer of protection by limiting what content a browser is allowed to execute. Following this work, stricter CSP policies have been deployed on RIPE Atlas, and similar work is ongoing in other internet-facing RIPE NCC services.<br>Cross-Site Request Forgery (CSRF)<br>This brings us to the next vulnerability, which belongs to the category of Cross-Site Request Forgery (CSRF). In simple terms, CSRF involves having a user's browser perform a request chosen by an attacker. To do that successfully, an attacker often relies on the victim already being authenticated to the target service.<br>In this case, the RIPE Database syncupdates service did not perform...