# Reported issues for Oncofiles

Pod holds 13 of 13 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Oncofiles](/mcp/oncofiles).

## Most discussed

### Add declarative MCP tool access classification

Labels requested: enhancement, security, mcp-tool

## Description

Add a declarative access policy layer for MCP tools registered under `src/oncofiles/tools`. Today, each tool module registers functions manually with `mcp.tool()(fn)`, and the tool's security boundary is implicit in the function body.

This makes reviews and future changes harder: a new tool can be added without a clear declaration of whether it is patient-scoped read, patient-scoped write, integration management, operator diagno

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/523) · 2026-04-27 · open · external user · 2 comments

### Introduce shared AccessContext for MCP and dashboard patient access

## Description

Create a shared access-resolution layer that converts the current request/tool context into an explicit `AccessContext`. This object should contain the resolved patient identity, caller identity, auth source, and access capabilities.

Current code resolves patient access in multiple ways across MCP tools and dashboard routes. Some paths use `patient_slug`, others use implicit patient context, direct `_get_patient_id()`, dashboard session email checks, or bearer-token shortcuts. T

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/520) · 2026-04-27 · open · external user · 2 comments

### Inactive patient slugs can still be resolved by MCP patient_slug

### Description

 Patient slug resolution does not filter out inactive patients. The application uses an is_active flag for patient archival/deactivation, but get_patient_by_slug() returns patients by slug regardless of is_active.

  Because MCP patient-scoped tools resolve explicit patient_slug values through this lookup, an inactive or archived patient may still be targetable through MCP tools if the caller knows the slug.

  This bypasses the expected behavior of patient deactivation/archival

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/509) · 2026-04-26 · closed · external user · 1 comment

### Uploaded document filenames are accepted without sanitizing path-like segments

### Description

 The document upload flow accepts caller-supplied filenames and stores/uploads them without sanitizing path-like characters or traversal-looking segments such as ../, /, or \.

  Although Google Drive uses explicit parent folder IDs and does not interpret filenames as filesystem paths, accepting path-like filenames is still unsafe and can cause inconsistent parsing, confusing metadata,
  misleading logs/UI, and potential downstream issues if any future exporter, local import/exp

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/508) · 2026-04-26 · closed · external user · 2 comments

### OCR document ID helper returns unscoped cross-patient document IDs

### Description

The database helper get_ocr_document_ids() returns all document IDs that have cached OCR pages across the entire database. It does not join against the documents table and does not filter by patient_id.

  This breaks the patient-isolation pattern used elsewhere in document helpers. While the helper may not directly expose the full ID set to MCP clients, it is used by patient-facing status/pipeline code to compute
  whether documents have OCR. Using a global OCR ID set can leak 

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/504) · 2026-04-26 · closed · external user · 2 comments

### MCP bearer secret reused as dashboard session and OAuth state signing key

### Description

 The application reuses MCP_BEARER_TOKEN for multiple independent authentication and signing purposes.

  The same secret is used for:

  - HTTP bearer authentication
  - dashboard session token HMAC signing
  - dashboard session token HMAC verification
  - OAuth state token HMAC signing
  - OAuth state token HMAC verification

  This creates unnecessary coupling between separate auth mechanisms. If MCP_BEARER_TOKEN is leaked or exposed through any one path, the same secret can 

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/502) · 2026-04-26 · closed · external user · 2 comments

### MCP patient_slug ACL bypass allows cross-patient read/write access

### Description

Multiple MCP patient-scoped tools trust patient_slug resolution without enforcing caller-to-patient authorization. A caller authenticated for Patient A can pass a valid slug for Patient B, and the tool operates
  under Patient B’s patient_id.

  This affects more than listing endpoints. It also impacts mutating tools and ID-based tools whose ownership checks rely on the resolved patient ID.

  Examples of affected tool classes:

  - Patient context mutation: update_patient_conte

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/498) · 2026-04-26 · closed · external user · 2 comments

### Critical: MCP `patient_slug` bypass allows cross-patient data access

### Description

 MCP patient-scoped tools allow a caller authenticated for one patient to pass a different patient_slug and retrieve data scoped to that other patient. The central resolver accepts the supplied slug and returns
  the target patient_id without verifying that the caller is an admin, caregiver, or otherwise authorized for that patient.

  This affects read tools such as list_documents and list_treatment_events. Some tools have additional local ACL checks, but the shared resolver re

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/497) · 2026-04-26 · closed · external user · 2 comments

## Most recent

### Gmail and Calendar get-by-id DB helpers should enforce patient scope

## Description

Gmail and Calendar get-by-id database helpers are not patient-scoped internally.

The helpers fetch rows by internal numeric id only, even though both tables are patient-owned:

- `src/oncofiles/database/_gmail.py:71`
- `src/oncofiles/database/_calendar.py:61`

Current queries:

```sql
SELECT * FROM email_entries WHERE id = ?
SELECT * FROM calendar_entries WHERE id = ?
```

The MCP tool callers currently perform ownership checks after fetching the row:

- `src/oncofiles/tools/int

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/533) · 2026-05-05 · open · external user · 0 comments

### MCP bearer token is reused as signing key for dashboard sessions and OAuth state

Labels requested: bug, security

## Description

The same `MCP_BEARER_TOKEN` secret is used across multiple trust domains:

- static MCP bearer/admin authentication,
- dashboard session token HMAC signing,
- Google OAuth state HMAC signing.

This couples unrelated authentication mechanisms to one secret. If the MCP bearer token is disclosed, the blast radius is larger than necessary: an attacker could use the static bearer token directly, forge dashboard session tokens, and forge OAuth state tok

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/521) · 2026-04-27 · closed · external user · 1 comment

### Gmail and Calendar MCP tools lack explicit patient_slug resolution

**Description**

Several Gmail and Calendar integration MCP tools still use the legacy patient resolution pattern. They do not accept a `patient_slug` parameter and instead call `_get_patient_id()` directly.

This breaks stateless HTTP and multi-patient workflows. Other patient-scoped MCP tools accept `patient_slug` and resolve the target patient per request using `_resolve_patient_id(patient_slug, ctx)`. These integration tools cannot do that, so callers cannot explicitly target the intended pa

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/518) · 2026-04-27 · closed · external user · 1 comment

### Document cross-reference lookup does not enforce patient_id scoping

**Description**

The database helper `get_cross_references()` returns all relationship rows involving a document ID without verifying patient ownership for both documents in the relationship.

The patient-facing MCP tool `get_related_documents()` verifies that the requested source document belongs to the resolved patient. However, it then calls `get_cross_references(doc_id)` and trusts the returned relationship rows. If a cross-reference row links the source document to a document owned by anoth

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/517) · 2026-04-27 · closed · external user · 1 comment

### Legacy integration MCP tools cannot target patients in stateless HTTP

### Description

Several Gmail and Calendar integration MCP tools still use the legacy patient resolution pattern. They call _get_patient_id() directly instead of accepting patient_slug and resolving through
  _resolve_patient_id(patient_slug, ctx).

  This breaks stateless HTTP behavior for multi-patient and operator/admin workflows. In stateless MCP clients, per-request patient selection does not persist reliably, so patient-scoped tools need an explicit
  patient_slug parameter to target the 

[Read the thread](https://github.com/peter-fusek/oncofiles/issues/503) · 2026-04-26 · closed · external user · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/peter-fusek/oncofiles/issues).