CVE-2026-114119: Bp Premier's hardcoded SQL Server admin password cannot be changed

A vulnerability catalogued as CVE-2026-114119 and published on 21 October 2026 describes a hardcoded Microsoft SQL Server administrator password in Bp Premier, the practice management platform from Best Practice Software that is widely used in Australian general practice. According to a technical write-up on dev.to that walks through the NVD record, every installation of Bp Premier before build 1.14.1.1128 shares the same database administrator credential, and the application depends on that exact value: changing it breaks the software.

A shared credential with no rotation path

The NVD entry, as summarised on dev.to, states that an attacker who can reach the database instance over the network can authenticate as sysadmin, sidestep the application's own login controls, and execute operating system commands as SYSTEM. Three properties make this worse than a typical hardcoded-password finding:

• The password is identical on every affected deployment, so the exposure is not limited to misconfigured sites; it covers the entire installed base.
• The customer cannot rotate it, because the application relies on the exact value. Any fix has to arrive as a vendor release.
• The privilege level is sysadmin on SQL Server, which on Windows is a route to operating system command execution, not merely read access to application tables.

The record points to a fixed build at 1.14.1.1128 or later, and the write-up notes that the Bp Premier Oxford SP1 release notes place that release train at 1.14.1.1129. It also references a GCVE-123-2026-0001 entry in the Australian CI-ISAC vulnerability database.

Remediation becomes network architecture

When a vendor ships an embedded credential, the standard advice is to change it after installation. That mitigation is unavailable here. What remains, as the dev.to author argues, is controlling who can reach the SQL Server listener in the first place. The port should be reachable only by the application server and the backup system; a firewall rule scoped to the whole clinic subnet exposes the database to every workstation and every networked printer management interface on it. The host firewall on the server itself should be checked as well, since network rules may be managed by someone else.

The database behind the credential

The data at stake is not generic. The write-up notes the instance holds patient demographics, appointment history, billing and Medicare claim data, and practice correspondence. Under Australia's Privacy Act 1988 and the Notifiable Data Breaches scheme, unauthorised access to that personal information could make an incident notifiable, though the author is careful to say this depends on facts a CVE record cannot establish.

There is also a forensic problem. Because an attacker authenticates with the same credential the application uses, authentication logs alone may not prove whether the shared password was ever abused.

Checks operators can run now

The write-up suggests a short verification list for practices and managed service providers:

• Confirm the build is 1.14.1.1128 or later.
• From a workstation that should have no database access, attempt a TCP connection to the SQL Server port on the Bp Premier server. A successful connection is itself the finding; no credentials should be sent.
• Review firewall rules so that only the application server and the backup system can reach the port.
• Verify the Windows firewall profile on the server contains no allow-any rule for SQL Server.
• If a third party hosts the instance, request in writing the build version, the network path to the database, and whether monitoring could distinguish an interactive sysadmin login from the application's service account.

Questions the advisory does not answer

Two things remain unclear even after patching. It is not stated whether the fixed build eliminates the static credential, rotates it per installation, or simply ships a different shared value; those outcomes imply very different long-term risk. It is also unknown whether the vendor can detect an administrative login that did not originate from the application, which determines whether an affected practice could ever confirm it was not exploited. The write-up makes no claim of exploitation in the wild, does not publish the password, and notes that severity depends heavily on the attacker's network position, which a CVE record cannot assess.

Why it matters

Hardcoded credentials are a common finding, but this one removes the usual escape hatch: the password is shared everywhere and cannot be changed by the people operating the software. Until the fixed build is deployed and the database port is properly segmented, affected clinics are relying entirely on network controls they may never have consciously configured. The case also illustrates a broader lesson for buyers of vertical-market software: when an application owns its database credentials, a patch may replace the specific value while leaving the underlying class of risk intact. That is a question worth putting to any vendor, in writing, before the next CVE lands.