Routinator EUVD-2026-35063

Attacker must control an rsync repository that the target Routinator instance is configured to synchronize from - i.e., a publication point reachable via one of the configured trust anchor chains; this is the AT:P 'attack requirement' in the CVSS 4.0 vector. No authentication to Routinator itself is needed (PR:N) and no user interaction is required (UI:N), but exploitation is structurally limited to entities that already operate or have compromised an RPKI publication point, which is a small, identifiable population gated by the RPKI delegation model. Exploitation is constrained to writing within the Routinator rsync cache filesystem tree (not arbitrary host filesystem locations beyond the cache root, per the advisory wording).

Signals are mixed but lean toward genuine priority for RPKI operators. CVSS 4.0 vector AV:N/AC:L/AT:P/PR:N/UI:N gives network-reachable, no-auth exploitation with low complexity but a non-trivial 'attack requirement' (AT:P) - the attacker must control or compromise an rsync repository that Routinator is configured to fetch from, which in practice means being a (sub-)resource holder in the RPKI hierarchy or compromising one. Impact is VI:H/VA:H with VC:N, meaning cache integrity and availability can be subverted while confidentiality of the cache itself is rated none. No EPSS score, KEV listing, or POC is provided in the source data, so exploitation likelihood is unknown but presumed low given the small population of RPKI publication points and the trust model that already gates who can publish. The realistic concern is not mass exploitation but a targeted attack by (or against) a publication point that could corrupt validation results and influence BGP route filtering downstream.

An attacker who controls or compromises an rsync publication point in the RPKI hierarchy serves a module name containing '..' segments (e.g., rsync://malicious.example/../../etc/something/) so that when Routinator fetches and writes the repository contents into its local cache, files are placed outside the intended per-repository subdirectory and into arbitrary locations within the cache root. This corrupts cached RPKI objects used for route origin validation, potentially causing the validator to accept or reject ROAs incorrectly and influencing BGP filtering decisions downstream. No public exploit identified at time of analysis.