Universal SQL Server sysadmin credential in the Jumis accounting software

§ 01. Overview

Jumis (formerly Tildes Jumis) is a Windows accounting application used across Latvian businesses. Each installation keeps its ledgers in a Microsoft SQL Server instance, and in shared or multi-company deployments several customers' databases sit on the same server.

OffSeq found that Jumis creates and uses a SQL Server login, ##Tilde_JumisAdmin##, whose password is not a stored secret but a value the client computes on demand. The computation is deterministic: it takes the SQL Server name and combines it with constants that are hard-coded into the application, and it is identical in every copy of Jumis. Because the login is a member of the sysadmin server role, anyone who can reach the server and reproduce the computation holds full administrative control of it and of every customer accounting database on it. It is tracked as CVE-2026-59105, coordinated by CERT.LV.

§ 02. The ##Tilde_JumisAdmin## login

Jumis provisions a dedicated SQL Server login, ##Tilde_JumisAdmin##, and adds it to the sysadmin fixed server role. The application authenticates as this login for administrative tasks rather than using the invoking user's Windows identity, so the same high-privilege account exists on every deployment and is shared across the companies whose databases live on that server.

sysadmin is the highest privilege level in SQL Server. A session holding it can read and write every database on the instance, create and drop databases, alter logins, and reconfigure the server itself. In a shared Jumis deployment, one such login therefore spans every tenant's accounting data.

§ 03. Root cause: a password derived from a non-secret

The weakness is not that the login exists but that its password can be reconstructed by anyone. Instead of storing a unique, random secret per installation, Jumis derives the password at run time by hashing a string assembled from the SQL Server name (@@servername) together with fixed constants embedded in the client binary. The same routine runs identically in every installation.

A hard-coded constant shared across all installations is not a secret: it ships inside software that runs on customer machines and can be recovered from the client. Once that constant is known, the only input that varies between installations is the server name – and the server name is not secret either (below). The result is a credential whose entropy comes from a value an attacker can obtain, not from a per-installation secret. This is why the primary weakness is classed as CWE-1391 (use of weak credentials) with CWE-547 (use of hard-coded, security-relevant constants) contributing, rather than a simple stored-password flaw.

§ 04. Why the only input isn't secret

Reconstructing the password needs the hard-coded constants (recoverable from the client) and the SQL Server name. The server name is discoverable rather than confidential:

• The instance suffix is hard-coded by the application. Jumis builds the local instance name as the computer name plus a fixed instance suffix, so that half of the name is a known constant, not a per-site secret.
• The host name is exposed by the SQL stack itself. It can be read from the SQL Server Browser service (UDP 1434), from the TDS pre-login response when connecting to the instance, or from ordinary DNS and NetBIOS name resolution on the network.

So for an attacker who can reach the SQL service, the server name is observable and the rest of the derivation is fixed. The password follows without guessing, and a single authentication attempt confirms it.

§ 05. Validation

OffSeq confirmed the finding against an installed copy of Jumis 7.0.140 on Windows 10, in a controlled environment against systems OffSeq controls; no third-party systems were touched.

• Algorithm, against the shipped binary. The independent reconstruction of the derivation was checked against Jumis's own routine, invoked by reflection on the shipped Jumis.exe. For a given server name, the two produced the same password, confirming the reconstruction matches the application exactly.
• Authentication as sysadmin. Using only the server name as input, the computed password authenticated the ##Tilde_JumisAdmin## login against a real instance; suser_name() returned ##Tilde_JumisAdmin## and is_srvrolemember('sysadmin') returned 1.
• Escalation to the operating system. On the on-premise server installation, which enables xp_cmdshell during routine operation, the sysadmin session was able to run operating-system commands on the database server, confirming that database compromise extends to code execution on the host.

The exact constants, the server-name values used, and the key-generation tooling are withheld, as noted above.

§ 06. Impact and severity

The published metric is CVSS 3.1 base 9.8 (Critical) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The vector is network-reachable, low-complexity, with no privileges and no user interaction: the derived password is itself the credential, so no prior account is needed, and the only variable input is observable on the network.

Successful authentication grants sysadmin on the SQL Server instance. That means read access to every customer's accounting database on the server (confidentiality), the ability to modify or forge ledger and payment records across all of them (integrity), and the ability to drop databases (availability) – each rated High. On the on-premise server installation the application enables xp_cmdshell, so the same access chains into operating-system command execution on the machine holding every tenant's data.

A scope-changed reading (S:C) would reach 10.0, since the flaw lives in the Jumis client yet breaches the authority of the SQL Server and crosses from one company's intended database to all tenant databases and then to the host OS. The reported, conservative value is 9.8.

§ 07. Remediation

The fix is to stop deriving the administrative password from the server name. A per-installation credential must be a unique, randomly generated, high-entropy secret stored securely (for example via Windows DPAPI or protected configuration), never a value computed in client code from a non-secret input. Beyond that: move the service account to Windows Authentication (Integrated Security) instead of a shared SQL login holding sysadmin, apply least privilege so administrative tasks use only the roles they need, and stop automatically enabling xp_cmdshell and OLE Automation.

Jumis Pro SIA addressed the issue from release TJ7.0.141.36 (the Jumis July 2026 release); the latest available at publication is TJ7.0.142.7 (the September 2026 release).

Customers should update to TJ7.0.141.36 or later. After upgrading, confirm that ##Tilde_JumisAdmin## can no longer access databases that have been updated to at least TJ7.0.141.36: the login should hold only a limited public account in legacy databases and no account in new ones. Until a fixed build is deployed, restrict network access to the SQL Server so that only the hosts that need it can reach the instance, and keep restorable backups of the accounting databases.

§ 08. Disclosure and outcome

The vulnerability was reported to CERT.LV through Latvia's national coordinated-vulnerability-disclosure platform on 25 June 2026. CERT.LV opened coordination with the vendor on 29 June, the vendor confirmed the issue and began remediation by 30 July 2026, and CVE-2026-59105 was reserved on 6 August 2026. During coordination the product and maintainer were identified as Jumis (formerly Tildes Jumis) and Jumis Pro SIA (formerly SIA Tilde), with the fix shipping from release TJ7.0.141.36. The disclosure is coordinated by CERT.LV.

The discovery is credited to Nils Putniņš (OffSeq Cybersecurity).