What We Learned from a Multi-Service Vulnerability Disclosure

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.

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.

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.

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

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.

Cross- Site Scripting (XSS)

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.

In this case, the XSS was possible in two places:

• Through the NSID field in RIPE Atlas measurements
• Through the DNS check display of version.bind in the old RIPEstat UI

To illustrate the issue, the screenshots below show how maliciously crafted data could be used to inject content into legitimate RIPE NCC services:

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.

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.

Cross-Site Request Forgery (CSRF)

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.

In this case, the RIPE Database syncupdates service did not perform sufficient checks on certain requests. Combined with a valid RIPE NCC SSO session, this made it possible for an attacker to interact with the service and perform attacker controlled actions on behalf of the user.

The initial remediation addressed part of the issue, but later review showed that the original proof of concept could still be executed. Further testing and discussion with Sasha helped identify additional attack paths, resulting in further remediation work and ultimately a complete fix.

Overly permissive Certificate Authority Authorization (CAA)

The third issue involved Certificate Authority Authorization (CAA) records. CAA records allow domain owners to specify which Certificate Authorities are permitted to issue TLS certificates for their domains.

In this case, an overly permissive CAA configuration meant that certificates could be issued for certain subdomains under *.ripe.net. Under specific circumstances, this could then be used as part of the broader attack chain described above.

One example involved hostnames under mtg.ripe.net. During RIPE Meetings, devices connecting to the meeting network receive hostnames under this domain. The CAA configuration made it possible for an attacker to obtain a valid certificate for a hostname they controlled and use it as part of a larger attack.

The affected CAA configurations for both mtg.ripe.net and anchors.atlas.ripe.net were subsequently reviewed and updated, removing the overly broad certificate issuance permissions.

What we should have done better

Although the reported vulnerabilities have been addressed, Sasha's experience of the disclosure process itself highlighted areas where we fell short.

As mentioned, some of the reported issues were not fully resolved on the first attempt and had to be revisited. This emphasises the importance of validating fixes against the original report, rather than treating the vulnerability as addressed once a specific change has been deployed. At the same time, communication with Sasha became fragmented across multiple channels, making it harder to maintain a clear shared understanding of the status of the issues and the work underway to address them.

Things were further complicated by the fact that the reports spanned multiple RIPE NCC services. Addressing the issues required cooperation between teams with different responsibilities, priorities, operational constraints, and so on. As a result, although individual fixes were often implemented quite quickly, coordinating work across teams to make longer-term improvements and broader architectural changes proved more difficult.

The disclosure process also highlighted some of the limitations of handling specialised Internet infrastructure security reports through a general-purpose bug bounty workflow, where important technical context may need to pass through several stages before reaching the teams best placed to act on it. This contributed to delays in the validation and reward process, resulting in a longer wait for the researcher to receive their bounty payment than intended.

Taken together, these were largely organisational rather than technical challenges. Complex disclosures require clear ownership, good visibility, effective coordination, and regular communication with the researcher throughout their lifecycle. Sasha's experience highlighted where our existing ways of working were not strong enough, and where we need to do better.

Looking ahead

Looking ahead, we are focusing on further improving how we handle bug bounty submissions. We are enhancing our vulnerability disclosure process to improve the efficiency of report handling, strengthen coordination between teams, and provide more timely communication with researchers. We are also streamlining our internal workflows to ensure vulnerability reports are tracked and managed consistently from submission through remediation.

By continuously improving these processes, we aim to provide a better experience for researchers and further strengthen our security posture. We will also be refining our processes to ensure timely validation and reward decisions for eligible bug bounty submissions, and to support a more predictable and transparent coordinated disclosure process. Clear communication and fair recognition of researchers are essential to maintaining a successful partnership with the security community.

A subset of the reported findings highlighted required architectural changes rather than vulnerability-specific remediation. We have therefore initiated a longer-term effort to modernise our authentication and authorisation framework for RIPE NCC Services, to address the underlying design considerations identified during this research. As you will see in our quarterly planning for Q3, we’re already taking steps on this front.

All of the above are good lessons to have learned, and once again, we’re grateful to Sasha for the time, effort, and persistence with which the reports were disclosed. The issues raised through this work have already helped us improve both our services and our security processes. In particular, they’ve reinforced the importance of understanding how vulnerabilities interact across systems, and of maintaining a clear, shared picture of complex reports as they move between teams through the vulnerability disclosure process. All of this will continue to inform how we assess, fix, and communicate about security issues as we go forward.

Get involved

If you are a security researcher and are interested in helping us strengthen our security posture, we encourage you to participate in our bug bounty program. Whether you discover a minor issue or a complex vulnerability chain, your findings help us build more secure systems for our members and the broader Internet community. For more information please read our Responsible Disclosure Policy.

Our thanks to Sasha for her input on this article.