All Docs
FeaturesAgentOS WorkUpdated March 11, 2026

Security Patch: Closing the Admin Page Access Gap in v1.0.26

Security Patch: Closing the Admin Page Access Gap in v1.0.26

Overview

Version 1.0.26 ships a targeted security fix that closes an access-control gap on the /dashboard/admin route. Prior to this release, the route-level RBAC check was stubbed out with a comment, allowing any authenticated user to view the Admin Panel — including the Batch Jobs Panel — simply by navigating to the URL directly.

This post explains what was vulnerable, why it matters, and exactly how it was fixed.

What Was the Issue?

In src/app/dashboard/admin/page.tsx, lines 12–13 contained a placeholder comment:

// In production, check RBAC role here via lib/auth.ts

The actual role-loading and redirect logic was never implemented at the page level. As a result:

  • Any authenticated user — including those with the member role — could navigate to /dashboard/admin and see the full Admin Panel UI.
  • The Batch Jobs Panel and other administrative views were visually exposed.
  • Protective checks existed at the tRPC mutation layer, so destructive write operations were still blocked server-side — but read-only exposure of admin UI and data remained.

This is a classic defence-in-depth gap: the API was protected, but the page was not.

What Changed?

The fix adds a proper server-side access check directly in the page component, executed before any content is rendered:

  1. Retrieve the session — confirm the user is authenticated.
  2. Load the org context — resolve the user's orgId from the session or cookie.
  3. Query orgMembers — fetch the user's membership record and inspect their role field.
  4. Redirect if unauthorised — if the role is member, immediately redirect to /dashboard with no page content rendered.
  5. Proceed for admins/owners — only users with the admin or owner role continue through to the Admin Panel.

This approach is consistent with the existing lib/auth.ts patterns used elsewhere in the codebase.

Why Route-Level Protection Matters

Even when API endpoints are secured, unprotected pages can:

  • Leak UI structure, feature names, and operational data to unauthorised users.
  • Create confusion and support burden when regular members encounter admin-only interfaces.
  • Provide a foothold for privilege-escalation attempts if any client-side logic can be manipulated.

Defending at both the route level and the API level ensures that unauthorised users never receive admin page content in the first place.

Who Is Affected?

RoleBefore v1.0.26After v1.0.26
owner✅ Full admin access✅ Full admin access
admin✅ Full admin access✅ Full admin access
member⚠️ Could view Admin Panel UI✅ Redirected to /dashboard

No action is required from end users or administrators. The change is entirely server-side and takes effect automatically on deployment.

Upgrade Instructions

  1. Deploy the v1.0.26 release to your environment.
  2. Verify that your orgMembers table contains accurate role values (owner, admin, or member) for all users.
  3. Confirm that lib/auth.ts session helpers are reachable from the admin page server component.
  4. Optionally, test by signing in as a member-role user and navigating to /dashboard/admin — you should be redirected to /dashboard.

Affected File

  • src/app/dashboard/admin/page.tsx — lines 12–13 and surrounding page-load logic.