GBrain v0.40.8.x appears to enforce OAuth/federated source scope correctly on default read paths, but explicit source overrides can widen remote MCP caller access.
Security classification
The key issue is that source_id is authority-bearing. A remote MCP caller may request a source, but the server must validate the requested source against the caller's token claims (sourceId / allowedSources) at tool invocation time. Token signature and expiry validation alone are insufficient.
Observed behavior
In a multi-client OAuth deployment using synthetic canary data:
get_page, search, and default query did not leak a page written only to another client's source.
query with source_id=<other-source> returned the other client's page.
query with source_id=__all__ also returned the other client's page.
Separately, get_page did not expose a safe explicit source selector, so a federated client could not retrieve a canonical page from an allowed shared source without maintaining source-local mirrors.
Expected behavior
- Remote OAuth callers may only query sources in their allowed source set.
source_id=__all__ from remote OAuth callers should be clamped to allowed sources, or rejected.
- Unauthorized explicit source requests should return a generic forbidden/insufficient-scope style error, not an empty success.
get_page should support explicit source selection within the caller's allowed source set.
- Source-scoped tool calls should audit the caller source, requested source, effective source decision, and whether the request was rejected or clamped.
Reproduction note
No sensitive data was involved in this reproduction. The test used synthetic canary pages and then soft-deleted them.
I have a draft patch ready from a fork and will open a PR referencing this issue.
GBrain v0.40.8.x appears to enforce OAuth/federated source scope correctly on default read paths, but explicit source overrides can widen remote MCP caller access.
Security classification
The key issue is that
source_idis authority-bearing. A remote MCP caller may request a source, but the server must validate the requested source against the caller's token claims (sourceId/allowedSources) at tool invocation time. Token signature and expiry validation alone are insufficient.Observed behavior
In a multi-client OAuth deployment using synthetic canary data:
get_page,search, and defaultquerydid not leak a page written only to another client's source.querywithsource_id=<other-source>returned the other client's page.querywithsource_id=__all__also returned the other client's page.Separately,
get_pagedid not expose a safe explicit source selector, so a federated client could not retrieve a canonical page from an allowed shared source without maintaining source-local mirrors.Expected behavior
source_id=__all__from remote OAuth callers should be clamped to allowed sources, or rejected.get_pageshould support explicit source selection within the caller's allowed source set.Reproduction note
No sensitive data was involved in this reproduction. The test used synthetic canary pages and then soft-deleted them.
I have a draft patch ready from a fork and will open a PR referencing this issue.