fix(security): remove deep-research search/fetch tools (GHSA-j7p8-g5m6-3wv5) (#162)

The openai_deep_research module cached Meta Ads records in a module-level singleton keyed only by "<type>:<id>". Under streamable-http one process serves every caller, and fetch read that cache with no credential resolution and no ownership check, so any caller could read another caller's cached account, campaign, ad, page and business records.

Removed rather than scoped: in production every fetch call already failed (70% "Record not found", the rest schema-validation errors from clients treating it as a generic Graph fetch), and the hosted MCP replaces search with its own implementation, so there was no working behaviour to preserve. Regression tests assert neither tool is registered again.

Also bumps to 1.0.122 and documents the advisory in SECURITY.md.

Author: nictuku

README.md

@@ -502,14 +502,6 @@ For advanced users who need to self-host, the package can be installed from sour
       - `limit`: Maximum number of results to return (default: 25)
     - Returns: Location data with key, name, type, and geographic hierarchy information
 
-29. `mcp_meta_ads_search` (Enhanced)
-    - Generic search across accounts, campaigns, ads, and pages
-    - Automatically includes page searching when query mentions "page" or "pages"
-    - Inputs:
-      - `access_token` (optional): Meta API access token (will use cached token if not provided)
-      - `query`: Search query string (e.g., "Injury Payouts pages", "active campaigns")
-    - Returns: List of matching record IDs in ChatGPT-compatible format
-
 ## Licensing
 
 Meta Ads MCP is licensed under the [Business Source License 1.1](LICENSE), which means:

SECURITY.md

@@ -180,3 +180,44 @@ same-origin page — the escalation target for the XSS above.
 - If you completed an OAuth login on a machine where an untrusted page may have
   been open, reconnect the Meta account so a fresh token is issued.
 - Credited to zx — GitHub [@manus-pi](https://github.com/manus-pi).
+
+### GHSA-j7p8-g5m6-3wv5 — `search`/`fetch` deep-research tools returned one caller's cached records to another
+
+- **Severity:** High (CVSS 3.1 7.5 — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`)
+- **Affected versions:** `>= 0.6.0, <= 1.0.121` when run with
+  `--transport streamable-http` and serving more than one caller from one
+  process.
+- **Fixed in:** `1.0.122`
+- **Affected configurations:** Multi-caller deployments only. The default stdio
+  transport, and any deployment where a process serves a single caller, has no
+  cross-caller boundary to cross. The hosted MCP at `*.mcp.pipeboard.co`
+  intercepts `search` and answers it with its own implementation, so the Python
+  cache was never populated there and `fetch` had nothing to return — measured
+  over production traffic, every hosted `fetch` call returned "Record not found"
+  or a schema-validation error.
+
+**What went wrong.** `openai_deep_research.py` cached Meta Ads records in a
+module-level `MetaAdsDataManager` singleton, keyed only by `"<type>:<id>"` with
+no caller, session or tenant component. `search` populated that cache under the
+calling user's credential; `fetch` read it back with no credential resolution
+and no ownership check, so any caller who knew (or guessed) a record id could
+read another caller's cached ad-account, campaign, ad, page or business records
+— including account name, currency, total spend, balance and the raw Graph
+objects. `fetch` never called the Graph API, so nothing downstream validated
+the reader's token either; the HTTP auth gate gets a request past on any
+non-empty bearer token, which is enough for every other tool because Graph
+rejects a bad token, but not for a tool that answers from local state.
+
+**Fix.** The `search` and `fetch` tools and the module that backed them were
+removed outright. They had no working use left to preserve, so scoping the
+cache per caller would have kept the machinery without the benefit.
+
+**Action for operators.**
+- Upgrade to `1.0.122` or later.
+- If you ran an earlier version as a shared multi-caller service, treat the
+  record types listed above as potentially disclosed to other callers of that
+  process.
+- Clients that relied on the deep-research `search`/`fetch` pair should use the
+  typed tools instead: `get_ad_accounts`, `get_campaigns`,
+  `get_campaign_details`, `get_adsets`, `get_ads`, `get_ad_details`.
+- Credited to [@BarakSrour](https://github.com/BarakSrour).

meta_ads_mcp/__init__.py

@@ -6,7 +6,7 @@
 
 from meta_ads_mcp.core.server import main
 
-__version__ = "1.0.121"
+__version__ = "1.0.122"
 
 __all__ = [
     'get_ad_accounts',

meta_ads_mcp/core/__init__.py

@@ -14,7 +14,6 @@
 from .targeting import search_interests, get_interest_suggestions, estimate_audience_size, search_behaviors, search_demographics, search_geo_locations
 from . import reports  # Import module to register conditional tools
 from . import duplication  # Import module to register conditional duplication tools
-from .openai_deep_research import search, fetch  # OpenAI MCP Deep Research tools
 
 __all__ = [
     'mcp_server',
@@ -44,6 +43,4 @@
     'search_behaviors',
     'search_demographics',
     'search_geo_locations',
-    'search',  # OpenAI MCP Deep Research search tool
-    'fetch',   # OpenAI MCP Deep Research fetch tool
 ]