GHSA-FPJ4-9QHX-5M6M: Improper Authorization in DNN Platform Friend Request Flow

DNN Platform includes a social feature that allows users to establish mutual connections via friend requests. This functionality is governed by a state machine where requests must be explicitly accepted by the intended recipient. The vulnerability, tracked as GHSA-FPJ4-9QHX-5M6M, breaks this authorization model by permitting the initiating user to unilaterally force the acceptance of their own friend request.

The flaw is classified as Improper Authorization (CWE-285) and Insecure Direct Object Reference (CWE-639). It occurs within the API endpoints responsible for managing internal messaging and social interactions. Because the application logic relies solely on the provided request identifier without validating the caller's identity against the intended recipient, attackers can bypass the consent mechanism entirely.

This authorization failure affects DNN Platform versions 6.0.0 through versions prior to 10.2.2. The vulnerability exposes users to privacy violations by granting unauthorized access to restricted profile information. It also provides a vector for targeted social engineering attacks by establishing forced trust relationships on the platform.

The vulnerability resides in the API endpoint responsible for processing friend request acceptances, located under the DesktopModules/InternalServices/API/MessagingService/ directory path. When a user initiates a friend request, the system generates a unique identifier, such as a notificationId or friendshipId, to track the state of the connection attempt. The intended workflow requires the recipient to authenticate and submit this identifier to transition the request state to accepted.

The root cause is a missing contextual authorization check during this state transition. The API endpoint verifies that the supplied request identifier is valid and corresponds to an existing pending request. However, it fails to verify that the session initiating the acceptance action belongs to the user designated as the recipient of the friend request.

This reliance on the identifier alone creates a standard Insecure Direct Object Reference (IDOR) condition. Any authenticated user who possesses a valid request identifier can invoke the state change. Because the attacker initiates the request, they inherently possess the required identifier, allowing them to exploit the missing authorization constraint.

Prior to version 10.2.2, the MessagingServiceController processed acceptance requests based entirely on the provided identifier payload. The controller retrieved the friendship record from the database using the ID but did not perform a subsequent validation against the current execution context. The application implicitly trusted that only the legitimate recipient would submit the ID to the acceptance endpoint.

The patch implemented in version 10.2.2 introduces a strict ownership validation check within the processing logic. Before committing the state change to the database, the controller now compares the UserID of the recipient associated with the friendship record against the UserID of the currently authenticated user. If these values do not match, the application rejects the request.

This validation ensures that the authorization boundary is enforced at the controller layer before state mutations occur.

// Vulnerable conceptual logic prior to 10.2.2
var request = MessagingRepository.GetFriendRequest(payload.FriendshipId);
if (request != null) {
    MessagingRepository.AcceptFriendRequest(request);
}
 
// Patched conceptual logic in 10.2.2
var request = MessagingRepository.GetFriendRequest(payload.FriendshipId);
if (request != null && request.RecipientID == CurrentUser.UserID) {
    MessagingRepository.AcceptFriendRequest(request);
} else {
    throw new UnauthorizedAccessException();
}

Exploitation requires the attacker to possess an active, authenticated account on the target DNN Platform instance. The attacker begins by identifying a target user and initiating a standard friend request through the platform's user interface. This action generates the necessary state record within the application database.

Upon sending the request, the attacker monitors their local HTTP traffic to capture the API response or intercepts the outgoing request payload. This allows the attacker to extract the unique notificationId or friendshipId assigned to the newly created friend request. This identifier is the only parameter required for the subsequent exploitation step.

The attacker constructs a POST request directed at the AcceptFriendRequest API endpoint, appending the captured identifier in the payload. Because the server processes the request without verifying the recipient, the database updates the friendship status to accepted, forcefully establishing the connection without the target's interaction.

The primary consequence of this vulnerability is the compromise of user privacy controls. DNN Platform allows users to restrict the visibility of profile information, activity feeds, and uploaded media exclusively to confirmed friends. By forcing a connection, an attacker bypasses these privacy controls and gains persistent read access to restricted data.

Beyond data exposure, the forced relationship facilitates targeted social engineering and phishing campaigns. The platform UI presents the attacker as a trusted connection, which can be leveraged to distribute malicious links or extract sensitive information from the target. The implicit trust associated with a confirmed friendship significantly increases the likelihood of a successful secondary attack.

The vulnerability also enables attackers to perform metadata harvesting across the platform. By systematically forcing connections across a user base, an attacker can reconstruct internal social graphs and organizational hierarchies. This reconnaissance data provides utility for planning wider compromise strategies against the organization hosting the platform.

The vendor has addressed this vulnerability in DNN Platform version 10.2.2. This release functions as a security-focused hotfix designed to provide immediate remediation for organizations unable to perform major version upgrades. Administrators must deploy this update to securely enforce authorization boundaries within the messaging and social components.

Organizations utilizing legacy versions ranging from 6.0.0 up to the 10.2.x branch are strongly advised to prioritize this patch. The update applies a fundamental logic change to the MessagingServiceController and does not require extensive configuration modifications or schema changes. Applying the update permanently eliminates the IDOR condition.

In environments where immediate patching is strictly prohibited by change management policies, defensive monitoring can provide temporary visibility. Security teams should configure Web Application Firewalls (WAF) to log and alert on POST requests to the AcceptFriendRequest endpoint that originate from the same IP address or session that recently initiated a friend request. While this does not prevent the exploit, it provides an audit trail of forced connections.