Skip to main content

​
Security Advisory: Insecure Direct Object Reference (IDOR) Vulnerabilities

FieldValue
Advisory IDNXD-2026-001
Published2026-06-08
SeverityHigh (CVSS 3.1 Base Score: 6.5–7.5)
CWECWE-639 — Authorization Bypass Through User-Controlled Key
Affected ProductNexudus Coworking Platform
StatusDisclosed

​
Summary

Multiple Insecure Direct Object Reference (IDOR) vulnerabilities were identified in the Nexudus Coworking platform’s public-facing controllers. These vulnerabilities allow an authenticated user (coworker) to access, modify, or enumerate resources belonging to other users by manipulating sequential or predictable object identifiers in HTTP requests.

​
Vulnerability Details

​
What is IDOR?

An Insecure Direct Object Reference occurs when an application exposes internal object identifiers (such as database primary keys) in URLs or request parameters without verifying that the authenticated user is authorized to access the referenced object.

​
Root Cause

Several controller actions accept user-supplied identifiers (integer IDs or GUIDs) to retrieve records from the database but fail to verify that the requesting user owns or is otherwise authorized to access the returned record. While many endpoints correctly implement ownership checks (e.g., entity.Coworker != currentCoworker), several do not.

​
Affected Endpoints

​
1. Support — Unauthorized Help Desk Message Access

  • Endpoint: GET /Support/Message/{id}
  • Severity: High
  • Impact: An authenticated coworker can read the full contents of help desk messages (including comments and attachments) belonging to other coworkers by iterating over sequential message IDs. This exposes private support conversations, potentially containing sensitive account details, billing disputes, or personal information.

​
2. Bookings — Visitor Information Disclosure

  • Endpoint: GET /Bookings/GetBookingVisitors?bookingId={id}
  • Severity: Medium
  • Impact: An authenticated coworker can enumerate visitor lists of bookings belonging to other coworkers by iterating over sequential booking IDs.

​
3. Support — Unauthorized Request Closure

  • Endpoint: POST /Support/CloseRequest/{id}
  • Severity: Medium
  • Impact: Any authenticated coworker within the same business can close support requests belonging to other coworkers. The authorization check verifies business membership rather than individual ownership.

​
Exploitation Prerequisites

  • Authentication Required: Yes — attacker must have a valid coworker account.
  • Same Business Membership: For the “close request” endpoint, the attacker must be a member of the same business (location) as the victim. The new comment endpoint did not check this.
  • Identifier Predictability: Integer-based IDs are almost sequential and trivially enumerable.

​
Impact Assessment

CategoryImpact
ConfidentialityUnauthorized access to visitors and support tickets
IntegrityUnauthorized modification of support ticket contents and close status.
AvailabilityMinimal direct impact

​
Remediation

Each affected endpoint should verify that the authenticated user is the owner of (or is otherwise authorized to access) the requested resource before processing the request. The established pattern in the codebase is: 
var entity = service.Get(id);
if (entity == null)
    return RedirectToAction("Index");

if (entity.Coworker != Coworker)
    return RedirectToAction("Index");
This pattern is already correctly applied in the majority of endpoints and should be extended to all affected actions listed above.

​
Exploitation Assessment

Following identification of these vulnerabilities, an audit was performed to determine whether they had been exploited in production. The investigation examined help desk comments to identify any instances where comments were added to tickets by users who did not own those tickets, excluding legitimate administrative access (system administrators and users with assigned roles). Result: No evidence of exploitation was found. The only matching records were test tickets created by the security team during vulnerability validation. All other support ticket activity followed expected authorization patterns.

​
Timeline

DateEvent
2026-06-05Vulnerabilities identified and documented
2026-06-05Vendor notified
2026-06-05Fix deployed
2026-06-08Public disclosure

​
Credit

Discovered during external security review by PureCyber.