2026-08-28 · view entry permalink →
Zalktis (Latvian accounting software): unauthenticated SQL injection reachable by any PEPPOL/UBL e-invoice sender — no account, no network position, just a routine bookkeeping import (CVE-2026-59109)
CVE-2026-59109, coordinated via Latvia's CERT.LV vulnerability-disclosure platform, is an unauthenticated SQL injection in Zalktis, a Windows accounting application used by Latvian businesses, reachable through the everyday act of importing a received electronic invoice over the PEPPOL/UBL e-address network. When Zalktis imports an invoice or e-commerce export, four validation lookups concatenate trading-partner-controlled fields directly into SQL string literals with no parameterization and no escaping: the buyer/seller registration number (DatuParbaude.cs:320), the VAT number (DatuParbaude.cs:459), the EAN/barcode (DatuParbaude.cs:763), and the invoice line's unit-of-measure code taken from the <cbc:InvoicedQuantity unitCode="..."> XML attribute (frmreksaraksti.cs:3381). The application ships an escaping helper for exactly this purpose — "the application ships an escaping helper, Dazadi.sql_txt(), that strips single quotes — but it is never called on these import paths" (OffSeq Cybersecurity, 2026-06-30).
The unit-of-measure path is the most dangerous of the four because it fires automatically for every line of every imported invoice with no attacker targeting required. OffSeq demonstrated boolean-based ('1'='1' vs '1'='2') and UNION-based extraction, retrieving Lietotajs.Parole (user password) values from the accounting database in testing. CVSS 4.0 8.7 High / CVSS 3.1 8.8 High (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) — the only "interaction" required is the victim's routine act of importing the invoice, not a security decision: "OffSeq found that Zalktis built the SQL behind those imports by pasting fields taken straight from the incoming document into the query text... No account, prior relationship or network position is needed — on the PEPPOL network anyone can address an invoice to the victim, and the only step the victim takes is importing it" (OffSeq Cybersecurity, 2026-06-30). The vulnerable pattern is shared across roughly 20 import channels in the application, so every installation that imports documents is affected. Reported 2026-06-30, vendor-confirmed fixed 2026-07-16, CVE reserved 2026-07-30, published 2026-08-13, fixed in Zalktis 2026.1.586 (pre-1-July branch) or 2026.2.592 (post-1-July branch).
The generalisable lesson extends past this one product: PEPPOL e-invoicing is mandated across European public procurement, so "a trading partner's invoice field reaches your SQL statement" transfers to any administration running e-invoice intake regardless of which accounting package it uses, wherever that package parses trading-partner-controlled document fields without parameterized queries. Triage: unauthenticated SQL-metacharacter content in structured e-invoice fields that should carry only registration numbers, VAT numbers, EAN codes or unit-of-measure codes is the discriminator — those fields are structured identifiers by specification, so any content resembling SQL syntax in them has no legitimate business explanation regardless of which system parses the document.
OffSeq found that Zalktis built the SQL behind those imports by pasting fields taken straight from the incoming document into the query text... No account, prior relationship or network position is needed — on the PEPPOL network anyone can address an invoice to the victim, and the only step the victim takes is importing it.
The application ships an escaping helper, Dazadi.sql_txt(), that strips single quotes — but it is never called on these import paths.