GHSA-2RHW-GW3F-477J: Predictable HostGUID Assignment in DNN Platform New Installations

The DNN (DotNetNuke) platform relies on a HostGUID identifier to uniquely track and secure individual installations. This identifier is stored in the HostSettings database table and serves as a fundamental root of trust. It is utilized as a source of cryptographic entropy for various platform-wide security features.

Starting with the 10.0.0 release branch, a flaw in the DNN installation process introduces a critical cryptographic weakness. New deployments of the platform fail to generate a randomized GUID. Instead, the installer assigns a static, hardcoded GUID to every newly created instance.

This behavior maps to CWE-331 (Insufficient Entropy). Thousands of distinct DNN deployments worldwide share the exact same identifier. The lack of uniqueness compromises any security mechanism that assumes the HostGUID is a secret or unique value. Upgrades from earlier 9.x versions remain unaffected, as the upgrade process preserves the previously generated unique identifier.

In a secure DNN deployment, the HostGUID is dynamically generated during the initial setup phase. The application typically invokes a standard random generation function, such as Guid.NewGuid(), and commits the result to the database. This guarantees statistical uniqueness across different environments.

The vulnerability originates from a regression introduced in the 10.0.0 installation templates. Rather than executing dynamic generation logic, the installer applies a base database template containing pre-populated data. This template includes a hardcoded HostGUID value in the HostSettings initialization script.

When administrators deploy new instances using the affected 10.x installers, the system copies the hardcoded GUID directly into the production database. The application code fails to perform any secondary validation to ensure the identifier is unique before utilizing it in cryptographic operations.

The distinction between fresh installations and upgrades dictates vulnerability exposure. During an upgrade from DNN 9.x, the system retains the existing HostSettings table records. The previously generated secure GUID persists, isolating upgraded instances from this vulnerability.

The security implications of a shared HostGUID extend beyond simple instance identification. DNN utilizes this value as a cryptographic salt or seed for generating critical platform keys. When the underlying entropy source is static and publicly known, the derived keys become entirely predictable.

One primary consequence involves the generation of machine keys and encryption keys. If the platform derives encryption keys for sensitive data using the HostGUID, an external entity possessing the static GUID can recreate those identical keys. This degrades the confidentiality of encrypted database columns, including stored credentials and secure configuration parameters.

Session management and token generation mechanisms frequently incorporate the HostGUID to ensure tokens cannot be reused across different DNN instances. A shared identifier eliminates this cryptographic boundary. Tokens generated on one vulnerable instance might satisfy validation checks on an entirely different instance running the same shared GUID.

Furthermore, the shared identifier disrupts automated telemetry and licensing servers. External systems identifying clients by their HostGUID experience widespread collisions. Thousands of distinct installations report the same identifier, breaking asset tracking and vulnerability management systems.

Exploiting this vulnerability relies entirely on the predictability of cryptographic operations. An attacker begins by identifying a target running a newly installed version of DNN between 10.0.0 and 10.2.1. The attacker does not require direct access to the database or administrative credentials to initiate the attack.

The attacker retrieves the hardcoded HostGUID by analyzing the public DNN 10.x installation source code or by performing a test installation locally. Armed with the static identifier, the attacker reverse-engineers the platform's key derivation functions mapping to specific target components.

If the HostGUID serves as the primary salt for password hashing algorithms, the attacker performs optimized offline brute-force attacks. They pre-compute rainbow tables using the known static salt. This significantly reduces the computational overhead required to crack stolen password hashes from any vulnerable DNN instance.

In scenarios where the HostGUID seeds pseudo-random number generators for password reset links or authorization tokens, the attacker predicts the output. They trigger a reset sequence and calculate the resulting token offline, bypassing the intended email verification sequence entirely.

The primary remediation requires upgrading the DNN Platform to version 10.2.2 or later. The patch restores the dynamic generation of the HostGUID during the installation sequence. It ensures that new deployments rely on secure Guid.NewGuid() invocations rather than static template records.

Administrators must explicitly verify their environment to determine if they are affected. The vulnerability status is confirmed by querying the HostSettings table directly. The following SQL query extracts the active identifier:

SELECT SettingValue FROM HostSettings WHERE SettingName = 'HostGUID'

If the returned value matches the known hardcoded 10.x template GUID, the environment is vulnerable. Simply upgrading the software does not rotate the compromised GUID on existing installations. Administrators must manually generate a new GUID, update the HostSettings table, and restart the application pool.

Following a manual GUID rotation, administrators must regenerate all derived cryptographic keys. This includes recycling machine keys, invalidating all current user sessions, and enforcing a platform-wide password reset. These steps ensure that previously derived predictable keys are permanently retired.