🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟠 Plugin HTTP routes can shadow Control UI paths due to reordered request stages

Description

createGatewayHttpServer now executes plugin HTTP route handling before the Control UI HTTP handlers.

This changes the previous guarantee (tested as “does not let plugin handlers shadow control ui routes”) and makes it possible for a plugin-registered HTTP route to intercept and respond on Control UI paths (e.g. /chat, /avatar/..., or any Control UI SPA route) before the Control UI handler runs.

Impact (if plugins are untrusted/third-party, as implied by existing comments about “untrusted plugins”):

• UI phishing / spoofing: a plugin can register an exact or prefix route like /chat and serve a lookalike UI.
• Bypass of Control UI security headers: Control UI applies Content-Security-Policy and X-Frame-Options in applyControlUiSecurityHeaders, but a plugin response will only get the baseline headers from setDefaultSecurityHeaders unless it sets its own.
• Potential auth-flow abuse: even if Control UI auth is primarily WebSocket-based, a spoofed UI route can trick users into entering tokens/passwords.

Vulnerable ordering introduced:

​// Plugins now run before control-ui-avatar/control-ui-http
requestStages.push(
  ...buildPluginRequestStages({ /* ... */ })
);

if (controlUiEnabled) {
  requestStages.push({ name: "control-ui-avatar", /* ... */ });
  requestStages.push({ name: "control-ui-http", /* ... */ });
}

Additionally, plugin route registration/matching does not constrain paths to a safe namespace; routes can be any absolute path string, so /chat is a valid plugin route path.

Recommendation

Constrain plugin HTTP handling so it cannot intercept Control UI routes.

Options (choose one, in order of safety):

1. Namespace plugin HTTP routes (recommended): only allow plugin route registration under a dedicated prefix (e.g. /plugins/<pluginId>/...), and enforce this in registerPluginHttpRoute.

2. Keep Control UI precedence: move buildPluginRequestStages(...) back after control-ui-avatar and control-ui-http stages, and add a targeted exception so specific plugin endpoints remain reachable (e.g., classify certain webhook paths as not-control-ui, or explicitly check whether a request matches any registered plugin route before the Control UI SPA catch-all).

3. Blocklist Control UI paths for plugins: reject plugin route registrations that overlap the Control UI base path (including root-mounted /chat, /avatar/*, /assets/*, etc.).

Example approach (2), checking if a plugin route matches before falling into the Control UI catch-all:

​// Pseudocode: only run plugin handler before Control UI when the request is a registered plugin path.
if (handlePluginRequest && isRegisteredPluginHttpRoutePath(pluginRegistry, requestPath)) {
  requestStages.push(...buildPluginRequestStages(...));
}
​// then run control UI

This preserves Control UI integrity while keeping explicit plugin endpoints reachable.

Analyzed PR: #31885 at commit 36ba09e

_{Last updated on: 2026-03-02T18:37:42Z}

Greptile Summary

This PR fixes a bug where plugin HTTP routes registered via api.registerHttpRoute() were unreachable in version 2026.3.1. The issue occurred because the Control UI SPA catch-all handler (handleControlUiHttpRequest) executed before the plugin request handler (handlePluginRequest), causing all requests to non-built-in paths to be caught by the Control UI (returning 405 for POST or HTML for GET).

The fix reorders the handler chain in createGatewayHttpServer so plugin routes execute before Control UI handlers:

• Handler precedence (after change): Built-in routes → Plugin routes → Control UI → Probe endpoints
• Core behavior preserved: Built-in routes (hooks, tools, Slack, Canvas) still have highest priority
• Auth unchanged: Plugin route auth enforcement still applies before handler execution
• Fallthrough works: When plugins return false (not handling), requests continue to Control UI

The implementation correctly handles the fallthrough logic - plugin handlers are called first, and if they return false, the request proceeds to the Control UI handlers as expected. Tests verify both that plugins can now handle custom paths AND that unhandled requests still reach the Control UI.

Trade-off acknowledged: Plugins can now intercept Control UI paths (e.g., /chat, /avatars/*). This is intentional - explicitly registered plugin routes should take priority over a catch-all handler. However, this means a buggy or malicious plugin could shadow important UI routes, though this risk is mitigated by plugin auth enforcement and the fact that core built-in routes still have highest priority.

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - the change is well-tested and backward compatible
• Score reflects solid implementation with comprehensive testing, but acknowledges a notable behavior change where plugins can now shadow Control UI routes. The implementation correctly preserves auth enforcement and fallthrough logic, and tests verify both positive (plugin routes work) and negative (unhandled requests reach Control UI) cases. Core built-in routes maintain highest priority. The intentional trade-off (plugin route priority over catch-all) is reasonable but warrants team awareness for production deployment
• No files require special attention - both changes are straightforward and well-tested

_{Last reviewed commit: 10854dc}

Landed via temp rebase onto main.

• Gate: bunx vitest run src/gateway/server.plugin-http-auth.test.ts
• Land commit: 36ba09e
• Merge commit: 41c8734

Thanks @Sid-Qin!