Cross-instance configuration poisoning in X-Road

§ 01. Overview

X-Road is the open-source data-exchange layer maintained by the Nordic Institute for Interoperability Solutions (NIIS). It is the technical backbone of Estonia's X-tee and Finland's Suomi.fi Data Exchange Layer, and is deployed by governments and organisations well beyond the Nordics. Each deployment forms an ecosystem (an X-Road instance) whose members and Security Servers trust a signed, centrally distributed global configuration that defines who is a legitimate participant.

X-Road ecosystems can federate: two instances agree to exchange services, and each Security Server downloads the other ecosystem's global configuration so it can validate cross-border traffic. Advisory GHSA-c5gr-pcm6-828r describes a flaw in how a Security Server processes that federated download, allowing one ecosystem's configuration to be written into the trust store of another. NIIS rated it High severity, CVSS 8.0.

§ 02. How it works

Global configuration is delivered as a signed directory of configuration parts. Each part carries an ecosystem identifier that tells the Security Server which instance the part belongs to, and the Security Server uses that identifier to decide where on disk the part is stored. The vulnerability is that when a Security Server downloads configuration from a federated partner, it writes each part according to the identifier embedded inside the part – without verifying that the identifier matches the ecosystem the configuration was actually fetched from.

This is a classic origin-validation failure (CWE-346) compounded by insufficient verification of data authenticity (CWE-345). A malicious or compromised federated partner can assemble a valid, correctly signed configuration directory that contains a SHARED-PARAMETERS part naming the victim ecosystem rather than the attacker's own. Because the attacker controls the identifier field, the receiving Security Server treats the crafted part as the victim ecosystem's own configuration and overwrites the authoritative copy it already holds.

The signature check that is supposed to anchor trust does not stop the attack: the part is signed with the victim's own legitimate configuration key, which is public within the federation, so the forged part passes validation as if it originated from the victim's configuration source. The missing control is binding the delivered configuration to the ecosystem that actually served it.

§ 03. Impact

Because global configuration defines the trust anchors, member registry and Security Server list for an ecosystem, overwriting it hands the attacker control over the victim's authoritative trust configuration. From there an attacker can impersonate any of the victim's members or Security Servers, undermining the confidentiality and integrity guarantees the whole X-Road model depends on – the CVSS vector reflects this with a changed scope and High impact across confidentiality, integrity and availability.

The compromise is persistent rather than transient. The poisoned configuration survives normal configuration refreshes and is not automatically corrected, so recovering a victim ecosystem requires manual cleanup rather than simply waiting for the next legitimate download. Exploitation does require an existing federation relationship and elevated position (high attack complexity and high privileges required), which is why the flaw is scored High rather than Critical, but for national data-exchange infrastructure the blast radius of a successful attack is substantial.

§ 04. Affected and fixed versions

All X-Road Security Server versions before 7.8.2 are affected. NIIS shipped fixes across three maintenance lines: 7.8.2, 7.7.3 and 7.6.4. Operators should upgrade to the patched release on their branch.

No CVE identifier is listed for this advisory at time of writing; it is tracked as GHSA-c5gr-pcm6-828r in the X-Road repository's security advisories. Because a successfully injected configuration persists, operators who may have been targeted should not rely on upgrading alone – the advisory notes the poisoned configuration needs manual remediation.

§ 05. Disclosure

The issue was reported to NIIS through coordinated disclosure by OffSeq and is credited to OffSeq in the published advisory. NIIS handled the report through its security-advisory process and released fixed versions across the supported X-Road branches before publication.