Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/oncofiles/issues.md or /mcp/oncofiles/issues.json, or Pod over MCP.

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.

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 · 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 · 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 · 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 · 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 · 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:

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 · 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:

Read the thread · 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 · 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:

Current queries:

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

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

Read the thread · 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:

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 · 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 · 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 · 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 · 2026-04-26 · closed · external user · 1 comment

The remaining reports are on the project's issue tracker.