CVE-2024-6912 is a critical severity (CVSS 9.8) flaw in PerkinElmer ProcessPlus on Windows. The software uses the same built-in Microsoft SQL Server login across installations, so a remote attacker who knows it can sign in to the database. ProcessPlus 2.0.0 is reported as the fix.
What's affected
The NVD record lists ProcessPlus through 1.11.6507.0 on Windows. CyberDanube, the researcher who disclosed the issue, gives the same boundary.
The advisory says the credential is stored in a ProcessPlus configuration file under the program data folder, and that the same value appeared in every installation the researchers reviewed. This advisory does not print the password here and neither do we. The point is that the value is shared, so it is effectively public to anyone who has seen one install.
On versions, the CyberDanube timeline reports that the vendor said all three issues in the disclosure were fixed in version 2.0.0, released on 11 July 2024. The NVD record gives no fixed version, so confirm 2.0.0 with the vendor.
The weakness is CWE-798, use of hard-coded credentials. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. CyberDanube labels the overall disclosure "High" impact rather than critical, which is a difference in how the group is rated and not a contradiction about this flaw. Use the 9.8 for this CVE.
How to check if you're exposed
- Read the installed ProcessPlus version in Programs and Features. At or below 1.11.6507.0 is in scope.
- Check whether the SQL Server instance that ProcessPlus installs listens on a network interface and not only on the local machine. SQL Server Configuration Manager shows the protocols, and the Windows firewall rules show whether the port is reachable.
- Find out whether the database still uses the vendor default login. If your records show it was never changed, assume it is the shared value.
- Check SQL Server logs for failed and successful logins from addresses that are not the ProcessPlus host or your administrators.
What to do now
- Upgrade ProcessPlus to 2.0.0 or later after vendor confirmation.
- Restrict network access to the host and to the SQL Server port. This is the advisory's first workaround.
- Change the database credentials, both in the configuration file and in the database itself, as the advisory instructs. Changing only one side will break the application.
- Review who and what connected to the database since installation, and treat the data as possibly exposed.
- Apply the fix for CVE-2024-6913 at the same time, because the advisory says the two combine into a full host compromise.
Why it matters
Hard-coded credentials turn a private secret into a published one. Once a single installation has been inspected, every other installation shares the exposure, and no amount of strong password policy on the host will help.
The advisory ties this to a second weakness. The application connects with the database's most privileged account, so database access can be turned into command execution on Windows. That is the reason the CVSS vector shows high impact on all three of confidentiality, integrity and availability. The CVE is not in the CISA Known Exploited Vulnerabilities catalogue, and the sources do not report exploitation in the wild.
Software inventories help here. Searching your estate for the product name and version is the fastest way to find the hosts that need the change.
Quick check
Is changing the password enough?
It removes the shared credential, but the advisory also recommends upgrading to 2.0.0 and restricting network access. Do all three.
Why is this scored critical when the researcher says high?
The NVD record scores this single CVE at 9.8. CyberDanube's "High" describes the whole group of three disclosures.
Sources
Last reviewed: 19 October 2026.
