X-Road® is open-source software and ecosystem solution that provides unified and secure data exchange between organisations. The basic idea of X-Road is that members of an ecosystem exchange data through access points (Security Servers) that implement the same technical specifications. X-Road is a digital public good verified by the Digital Public Goods Alliance, and it is released under the MIT open source license and is available free of charge.

Tier 2
€100 - €5,000
Tier 3
€50 - €625
Rules of engagement

Our promise to you

  • We are happy to respond to any questions, please use the button in the right top corner for this.
  • We respect the safe harbour clause that you can find below

Your promise to us

  • Provide detailed but to-the point reproduction steps
  • Include a clear attack scenario. How will this affect us exactly?
  • Remember: quality over quantity!
  • Please do not discuss or post vulnerabilities without our consent (including PoC's on YouTube and Vimeo)
  • Please do not use automatic scanners -be creative and do it yourself! We cannot accept any submissions found by using automatic scanners. Scanners also won't improve your skills, and can cause a high server load (we'd like to put our time in thanking researchers rather than blocking their IP's 😉)
  • Please perform all testing in an environment that you are authorized to test. NIIS cannot provide authorization to test against production instances of X-Road, as these instances are owned and operated by third parties.

Disclosure policy

NIIS supports the responsible disclosure of vulnerabilities. However, due to X-Road’s use in government agencies worldwide, it is necessary for NIIS to ensure that sufficient time is available for users to patch their instances of X-Road prior to the public disclosure of any vulnerability. As such, we ask that you mention your intention to publicly disclose a vulnerability when you submit a finding to this program and wait for NIIS to grant approval before publicly disclosing your findings. Findings that are publicly disclosed without NIIS approval will not be eligible for a bounty.


Central Server

Tier 2

Central Server contains the registry of X-Road members and their Security Servers. Besides, the Central Server contains the security policy of the X-Road instance that includes a list of trusted certification authorities, a list of trusted time-stamping authorities, and configuration parameters. Both the member registry and the security policy are made available to the Security Servers via HTTP protocol. This distributed set of data forms the global configuration that Security Servers use for mediating the messages sent via X-Road.

More information about the Central Server can be found at:

Security Server

Tier 2

Security Server is the entry point to X-Road, and it is required for both producing and consuming services via X-Road. The Security Server mediates service calls and service responses between Information Systems. The Security Server encapsulates the security aspects of the X-Road infrastructure: managing keys for signing and authentication, sending messages over a secure channel, creating the proof value for messages with digital signatures, time-stamping and logging.

More information about the Security Server can be found at:

Configuration Proxy

Tier 3

Configuration Proxy is an intermediary that may optionally be used to mediate configuration originating from the Central Server to the Security Servers. The Configuration Proxy downloads the configuration, stores it, and makes it available for download. Thus, the configuration proxy can be used to increase system availability by creating an additional configuration source and reduce load on the Central Server.

More information about the Configuration Proxy can be found at:

In scope

We are happy to announce the first X-Road® bug bounty program! We've done our best to clean most of our known issues and now would like to request your help to spot the ones we missed! The following components of X-Road are in-scope for this bug bounty program:

  • X-Road Central Server
  • X-Road Security Server and its addons
  • X-Road Configuration Proxy

As an example:
We are very interested in maintaining a high level of trust and security in the communication that takes place between two Security Servers. If you find any way of breaking that trust by using a man in the middle attack or any other means, please let us know!

Getting started

The best way to get started with X-Road is to get familiar with the overall concept and try out the software in practice. More information about X-Road and links to additional resources can be found at:

In addition, it is recommended to read the following documents before getting started on hands-on level:

How to setup your own environment

The easiest way to install your environment is to use the Ansible script available here. Please use the X-Road vanilla variant and the official X-Road package repository.

Starting from X-Road 7.0.0 the Security Server supports Docker. The Docker image is available on Docker Hub.

Once all the components are up and running, complete the configuration process following these instructions.

X-Road Bug Bounty Environment

X-Road bug bounty environment is a pre-configured X-Road environment that is publicly accessible to any researcher participating in the X-Road bug bounty program. Performing testing is allowed in this environment. However, the configuration of the environment is static and researchers have read-only access to the configuration.

X-Road bug bounty environment is a fully functional X-Road environment that consists of:

  • Central Server (CS)
  • Security Servers (SS) x2
  • Test services (IS)
  • Trust services (CA, OCSP, TSA)

There are three registered member organisations in the environment:

  • NIIS - X-Road operator
  • Test company - service consumer
  • Test agency - service provider

Accessing Security Servers

NIIS is the owner of Security Server #1, and Test agency the owner of Security Server #2. The test services are published on Security Server #2 and they can be consumed via Security Server #1. Security Server #1 is also the management Security Server connected to the Central Server.

Username for the UI is "xrd" and password is "secret". When logging in for the first time there’s a warning message, because the self-signed certificate of the Security Server UI needs to be accepted.

N.B.! The credentials are read-only - it is not possible update Security Servers' configuration. Also, it's not possible to get shell access to the Security Server hosts.

Invoking Test Services

Test services are published on Security Server #2 and they can be consumed via Security Server #1. There are test services available via both SOAP and REST interfaces. Test services can be invoked in multiple ways, e.g. command line using curl, Firefox RESTClient addon.

SOAP Services

There are two test services available: getRandom and helloService. GetRandom does not take any parameters and it returns a random number between 1 and 100 (example request). HelloService takes a name as a parameter and returns a greeting with the given name (example request). The test services can be invoked through Security Server's #1 SOAP interface at:

SOAP requests must be submitted using HTTP POST method and content-type must be "text/xml". The examples below illustrate how the test services and listMethods meta service can be invoked using curl.

Example requests can be downloaded at:

REST Services

REST services can be consumed using the X-Road Message Protocol for REST. The environment provides one REST API for testing purposes. The API is a public API providing open data, and it's owned and maintained by NIIS. The service description of the API is available here.

The test services can be invoked through Security Server's #1 REST interface at:

Requests must be submitted using the HTTP method and content-type required by the endpoint to be invoked. The examples below illustrate how to invoke the test services using curl. Other available endpoints can be discovered from the service descriptions.

Out of scope

Out of scope

  • Vulnerabilities related to,, or any other webpage relating to X-Road. Only the X-Road core software itself is in scope for this program.
  • Vulnerabilities related to the X-Road autologin utility.
  • Reports from static analysis of source code without accompanying proof of concept and steps to reproduce against a live instance of X-Road.
  • Reports from automated tools or scans without accompanying proof of concept and steps to reproduce.
  • Vulnerabilities relating to host configuration, such as open ports or TLS configuration issues. Host hardening is up to the server administrator in the X-Road architecture, so only vulnerabilities in the X- Road software itself will be considered in-scope.
  • Vulnerabilities related to the Test CA provided with X-Road. This CA is for testing purposes only, and is not used in production environments.
  • Spam, social engineering and physical intrusion.
  • DoS/DDoS attacks or brute force attacks.
  • Vulnerabilities that are limited to non-current browsers (older than 3 versions) will not be accepted.
  • Attacks requiring physical access to a victim’s computer/device, man in the middle or compromised user accounts.
  • Reports that state that software is out of date/vulnerable without a proof-of-concept.


  • Pre-auth account takeover / oauth squatting
  • Self-XSS that cannot be used to exploit other users
  • Verbose messages/files/directory listings without disclosing any sensitive information
  • CORS misconfiguration on non-sensitive endpoints
  • Missing cookie flags
  • Missing security headers
  • Cross-site Request Forgery with no or low impact
  • Presence of autocomplete attribute on web forms
  • Reverse tabnabbing
  • Bypassing rate-limits or the non-existence of rate-limits.
  • Best practices violations (password complexity, expiration, re-use, etc.)
  • Clickjacking on pages with no sensitive actions
  • CSV Injection
  • Blind SSRF without proven business impact (DNS pingback only is not sufficient)
  • Disclosed and/or misconfigured Google API key (including maps)
  • Host header injection without proven business impact
  • Sessions not being invalidated (logout, enabling 2FA, ..)
  • Hyperlink injection/takeovers
  • Mixed content type issues
  • Cross-domain referer leakage
  • Anything related to email spoofing, SPF, DMARC or DKIM
  • Content injection
  • Username / email enumeration
  • E-mail bombing
  • HTTP Request smuggling without any proven impact
  • Homograph attacks
  • XMLRPC enabled
  • Banner grabbing / Version disclosure
  • Open ports without an accompanying proof-of-concept demonstrating vulnerability
  • Weak SSL configurations and SSL/TLS scan reports
  • Not stripping metadata of images
  • Disclosing API keys without proven impact
  • Same-site scripting
  • Subdomain takeover without taken over the subdomain
  • Arbitrary file upload without proof of the existence of the uploaded file


  • In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate.
  • Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited, may be excluded or be lowered in severity.
  • Recently discovered zero-day vulnerabilities found in in-scope assets within 4 weeks after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty.
  • Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
  • Please use only the latest versions of each X-Road component in your testing environment. Issues found in outdated versions of X-Road, or on unsupported platforms, will not be eligible for bounties, unless the issue can be reproduced in the latest version. A list of supported platforms can be found in the release notes for each version of X-Road.
  • Participation in this program by NIIS employees and contractors is prohibited for the duration of their employment or contract with NIIS, and for a period of two years thereafter. Additionally, any vulnerability submitted to this program that is traced back to code contributed by the researcher who reported it will not be eligible for a bounty.
Severity assessment

This program follows Intigriti's default severity assessment guidelines, combining the CVSSv3 standard with an optional business impact modifier.


What is the easiest way to try X-Road?

X-Road bug bounty environment is a pre-configured X-Road environment that is publicly accessible to any researcher participating in the X-Road bug bounty program. Performing testing is allowed in this environment. However, the configuration of the environment is static and researchers have read-only access to the configuration. Please see the "In scope" section for details.

Another alternative is the Standalone Security Server - a special version of Security Server that is ready-to-use in minutes without the normal Security Server installation, configuration and registration process. However, the available feature set is also limited compared to a regular Security Server.

All aboard!
Please log in or sign up on the platform

For obvious reasons we can only allow submissions or applications for our program with a valid intigriti account.

It will only take 2 minutes to create a new one or even less to log in with an existing account, so don't hesitate and let's get started. We would be thrilled to have you as part of our community.

last contributors
Overall stats
submissions received
average payout
accepted submissions
total payouts
Nordic Institute for Interoperability Solutions
changed the in scope
Nordic Institute for Interoperability Solutions
closed a submission
created a submission
Nordic Institute for Interoperability Solutions
closed a submission
created a submission
Nordic Institute for Interoperability Solutions
closed a submission
created a submission
Nordic Institute for Interoperability Solutions
changed the out of scope
Nordic Institute for Interoperability Solutions
changed the out of scope
Nordic Institute for Interoperability Solutions
changed the in scope