StudioCMS: IDOR in User Notification Preferences Allows Any Authenticated User to Modify Any User's Settings

Description

Summary

The updateUserNotifications endpoint accepts a user ID from the request payload and uses it to update that user's notification preferences. It checks that the caller is logged in but never verifies that the caller owns the target account (id !== userData.user.id). Any authenticated visitor can modify notification preferences for any user, including disabling admin notifications to suppress detection of malicious activity.

Details

The vulnerable handler is in packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts:257-311:

.handle(
    'updateUserNotifications',
    Effect.fn(function* ({ payload: { id, notifications } }) {
        // ...demo mode checks...

        const [sdk, userData] = yield* Effect.all([SDKCore, CurrentUser]);

        // Line 274: Only checks login + visitor level — any authenticated user passes
        if (!userData.isLoggedIn || !userData.userPermissionLevel.isVisitor) {
            return yield* new DashboardAPIError({ error: 'Unauthorized' });
        }

        // Line 280: Uses 'id' from payload — NOT userData.user.id
        const existingUser = yield* sdk.GET.users.byId(id);

        // Line 288: Updates target user using attacker-controlled 'id'
        const updatedData = yield* sdk.AUTH.user.update({
            userId: id,       // ← attacker controls this
            userData: {
                id,            // ← attacker controls this
                name: existingUser.name,
                username: existingUser.username,
                updatedAt: new Date().toISOString(),
                emailVerified: existingUser.emailVerified,
                createdAt: undefined,
                notifications,  // ← attacker controls this
            },
        });
    })
)

For comparison, the updateUserProfile handler in dashboard/profile.ts correctly uses userData.user.id instead of a user-supplied ID, preventing IDOR.

PoC

# 1. Log in as a visitor-role user, obtain session cookie

# 2. Disable all notifications for the admin user
curl -X POST 'http://localhost:4321/studiocms_api/dashboard/update-user-notifications' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id": "<admin-user-id>",
    "notifications": ""
  }'

# Expected: 403 Forbidden
# Actual: 200 {"message":"User notifications updated successfully"}

Impact

  • Any authenticated visitor can disable notification preferences for admin/owner accounts, suppressing alerts about new user creation, account changes, and user deletions
  • Enables attack chaining — suppress admin notifications first, then perform other malicious actions with reduced detection risk
  • Can modify any user's notification preferences (enable unwanted notifications or disable critical ones)

Recommended Fix

Add an ownership check in packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts:

// After the login check at line 274, add:
if (id !== userData.user?.id && !userData.userPermissionLevel.isAdmin) {
    return yield* new DashboardAPIError({
        error: 'Unauthorized: cannot modify another user\'s notification preferences',
    });
}

Basic information

Type
reviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2026-03-12 14:49:41 UTC
Updated
2026-03-12 14:49:43 UTC
GitHub reviewed
2026-03-12 14:49:41 UTC
NVD published
2026-03-11 21:16:16 UTC

EPSS Score

Score Percentile
0.02% 3.51%

CVSS Scores

Base score Version Severity Vector
5.4 3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:L)
A normal user session is enough; they don’t have to be admin.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:L)
Attackers could change some data, but it’s limited—not everything goes.
Availability (A:L)
Might cause slowdowns, glitches, or partial disruption—not a full brick.

Identifiers

CWEs

CWE id Name
CWE-639 Authorization Bypass Through User-Controlled Key

Credits

  • offset (reporter)
  • Adammatthiesen (remediation_developer)

Affected packages (1)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
npm studiocms <= 0.4.2 0.4.3

References

cvelogic Threat Intelligence