Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 4 min read

A password you cannot change: CVE-2026-114119 and the hardcoded SQL Server administrator in Bp Premier

A password you cannot change: CVE-2026-114119 and the hardcoded SQL Server administrator in Bp Premier Most hardcoded-credential advisories describe a key that the vendor rotates in an update. CVE-2026-114119, publishe

A password you cannot change: CVE-2026-114119 and the hardcoded SQL Server administrator in Bp Premier

Most hardcoded-credential advisories describe a key that the vendor rotates in an update. CVE-2026-114119, published on 21 October 2026 for Best Practice Software's Bp Premier before 1.14.1.1128, describes something less tractable: a Microsoft SQL Server administrative password that is shared across all installations and that, according to the record, cannot be changed without breaking the application. That detail changes the remediation conversation from "patch and rotate" to something closer to network architecture.

What the record states

The NVD entry says Bp Premier before 1.14.1.1128 uses a hardcoded Microsoft SQL Server administrative password shared across all installations and not changeable without breaking the application. An attacker with network access to the database instance can authenticate as sysadmin, bypass application authentication, and execute operating system commands as SYSTEM.
Three facts follow directly, and each one carries its own consequence:

  1. The credential is the same everywhere, so the population of affected deployments is the population of installations, not the subset that was misconfigured.
  2. The password cannot be rotated by the customer, so a change to the credential requires a vendor release.
  3. The privilege level is sysadmin on SQL Server, which is a path to operating-system command execution, not just to the application's data. The record references a GCVE entry from the Australian CI-ISAC vulnerability database and the Bp Premier Oxford SP1 release notes. Bp Premier is clinical practice management software used in Australian general practice, which is relevant to the impact assessment rather than to the technical mechanism.

Why "cannot be changed" is the important phrase

An embedded credential in an installer is a common finding. What usually limits the damage is that the operator is expected to change it, and auditors can check whether they did. The advisory removes that mitigation: rotation is not a documented operational step because the application depends on the value.
Two control surfaces remain.

  • Network reachability to the database port. If nothing on the network except the application server can reach the SQL Server listener, the shared credential cannot be used from elsewhere. This is the control that matters, and it has to be enforced on the host firewall and the network segment, not on the application's own login form.
  • The vendor's replacement mechanism. A fixed build at 1.14.1.1128 or later implies the vendor changed something. Whether the new design removes the static credential, rotates it per installation, or merely changes the value is not stated in the advisory, and it should be confirmed with the vendor before assuming the underlying class of risk is gone.

The clinical context is not decoration

It would be easy to file this under "medical software, handled by someone else". The data behind that SQL Server instance is a practice management database: patient demographic records, appointment history, billing and Medicare claim data, and correspondence. The Australian context adds a specific reporting regime; a sysadmin-level compromise of that instance is a notifiable event under the Privacy Act 1988 (Cth) and the Notifiable Data Breaches scheme if it results in unauthorised access to personal information. This article does not assess whether a specific incident is notifiable, because that depends on facts a CVE record cannot supply.
The practical consequence is that the investigation burden is higher than the technical one. A shared credential means you cannot prove non-use from authentication logs alone if the attacker's access looked like the application's access.

Verification for a practice or a managed service provider

  • Build check. Confirm Bp Premier is at 1.14.1.1128 or later. The release notes describe Oxford SP1 at 1.14.1.1129, so the fixed line is present in the SP1 train.
  • Port exposure. From a workstation that should not have database access, attempt a TCP connection to the SQL Server port on the Bp Premier server. A successful connection is the finding; no credential should be sent in this test.
  • Firewall rule review. The rule should permit the application server and the backup system and nothing else. A rule scoped to "the clinic subnet" includes every workstation and every unpatched printer with a management interface.
  • Local firewall on the server. Confirm the Windows firewall profile is active and does not include an allow-any rule for the SQL Server port. This matters when the network rule is managed by someone else.
  • Managed service providers. If a third party hosts the instance, ask for the same three facts in writing: build, network path, and whether they have any monitoring that would distinguish an interactive sysadmin login from the application's own service account.

What to ask the vendor

Two questions are worth putting in writing rather than inferring. First, whether the fixed build removes the static credential or replaces it with a different static value, since the two answers imply different long-term risk. Second, whether the vendor can detect an administrative login that did not come from the application, which determines whether an affected practice could ever confirm non-exploitation.
Neither question is answerable from the advisory, and both change what a practice should do next week.

Limits

This article does not assert exploitation in the wild, does not describe the credential, and does not claim that a fixed build eliminates every related risk. The CVSS information in the record is as published; the severity of a database-credential exposure is highly dependent on network position, which the advisory cannot assess. The clinical and regulatory context is provided as background for prioritisation, not as a legal determination.

References

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.