CVE-2026-92603: ContiNew Admin Authorization Bypass Flaw

CVE-2026-92603 Overview

CVE-2026-92603 is an authorization bypass vulnerability in ContiNew Admin through version 4.1.0. The flaw resides in the personal message delete endpoint exposed by UserMessageController. Authenticated users can submit arbitrary message identifiers in the IdsReq parameter to delete messages and announcements they do not own. The endpoint does not validate message ownership before invoking messageService.delete(req.getIds()), and the deletion also purges all recipients' read receipts. The issue is tracked as CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact

Any authenticated low-privilege user can permanently delete any other user's messages and announcements, including recipient read-receipt records, by supplying arbitrary IDs to the delete endpoint.

Affected Products

• ContiNew Admin versions through 4.1.0
• continew-system module UserMessageController (lines 93–97)
• continew-system module MessageServiceImpl (lines 130–135)

Discovery Timeline

• 2026-09-16 - CVE-2026-92603 published to NVD
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92603

Vulnerability Analysis

ContiNew Admin exposes a DELETE endpoint in UserMessageController that accepts a JSON body of message identifiers. The controller passes the caller-supplied IDs directly to the service layer with no ownership check. The service then deletes the target message rows and cascades removal of read-receipt records for every recipient.

The vulnerability is a horizontal privilege escalation. An authenticated account required only to be logged in can enumerate or guess numeric message IDs and destroy other users' data. Because the deletion also removes broadcast announcement rows, a single request can affect many recipients at once. The database has no soft-delete or audit safeguard on this path, making the operation destructive and non-recoverable through the application.

Root Cause

The root cause is missing ownership validation between the authenticated principal and the requested resource. The pre-patch signature void delete(List<Long> ids) does not accept a user context. Authorization checks in ContiNew's role model gate access to the endpoint but do not enforce that the caller owns the referenced records. This is a textbook Insecure Direct Object Reference matching [CWE-639].

Attack Vector

An attacker with any valid session sends a DELETE request to the user message endpoint carrying a JSON IdsReq payload containing arbitrary message IDs. The server executes the deletion without checking whether the IDs belong to the caller. No user interaction from the victim is required, and the attack is fully remote over the network.

// Pre-patch: vulnerable controller accepts any ID from any authenticated user
@Operation(summary = "删除消息", description = "删除消息")
@DeleteMapping
public void delete(@RequestBody @Valid IdsReq req) {
    messageService.delete(req.getIds());
}

// Post-patch: caller's user ID is bound to the delete call for ownership validation
@Operation(summary = "删除消息", description = "删除消息")
@DeleteMapping
public void delete(@RequestBody @Valid IdsReq req) {
    messageService.delete(req.getIds(), UserContextHolder.getUserId());
}

Source: ContiNew Admin patch commit 665ea2c

Detection Methods for CVE-2026-92603

Indicators of Compromise

• Unexpected DELETE requests to the ContiNew user message endpoint handled by UserMessageController.
• Application logs showing large or non-contiguous IdsReq.ids arrays submitted by non-administrative accounts.
• Database rows for messages and read receipts disappearing without a corresponding action by their owning user.
• User complaints about missing announcements or messages that were not deleted by the recipient.

Detection Strategies

• Enable request logging on the message delete route and correlate the authenticated user ID with the owner of each targeted message row.
• Add server-side instrumentation that logs the tuple (caller_id, message_id, message_owner_id) on every delete and flag mismatches.
• Baseline normal delete volumes per user and alert on accounts issuing bulk deletions outside historical patterns.

Monitoring Recommendations

• Forward ContiNew application and access logs to a centralized log platform for retention and query.
• Alert on repeated HTTP 200 responses from the message delete endpoint originating from a single low-privilege session.
• Track database delete counts on the message and read-receipt tables and alert on spikes.

How to Mitigate CVE-2026-92603

Immediate Actions Required

• Upgrade ContiNew Admin to a release that includes commit 665ea2c757a3f1246db62fb139fec1aac3cca296.
• Audit recent delete activity on message and announcement tables and restore from backups where unauthorized deletions are identified.
• Restrict access to the ContiNew Admin console to trusted networks until the patch is deployed.

Patch Information

The upstream fix changes the service contract from delete(List<Long> ids) to delete(List<Long> ids, Long userId) and passes UserContextHolder.getUserId() from the controller. The service layer must then verify each ID belongs to the caller before performing deletion. Review the UserMessageController patch, the MessageServiceImpl code, issue #220, and the VulnCheck advisory for full remediation context.

// Service interface after the fix
/**
 * 删除
 *
 * @param ids    ID 列表
 * @param userId 当前用户 ID（用于校验消息归属，防止越权删除）
 */
void delete(List<Long> ids, Long userId);

Source: ContiNew Admin patch commit 665ea2c

Workarounds

• Apply a reverse-proxy or WAF rule that blocks DELETE requests to the user message endpoint for non-administrative roles until the patch is applied.
• Add a custom Spring interceptor that resolves each ID in IdsReq against the caller's user ID and rejects mismatches with HTTP 403.
• Temporarily revoke the personal message delete permission from standard user roles in ContiNew's role configuration.

# Example nginx snippet to block the delete route pending patch deployment
location = /system/user/message {
    limit_except GET POST PUT PATCH {
        deny all;
    }
}