Back to skill

Security audit

Second Brain Setup

Security checks for vulnerabilities and agentic risk

Overview

This skill is a narrowly scoped Notion setup helper, but it can create or move workspace objects without asking the user to confirm the exact location or existing databases first.

Before installing, make sure the Notion integration is shared only with the page where you want this setup to live. Avoid running it in a workspace where unrelated databases named Reading List or Inbox are visible to the integration, because the skill may move them automatically.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:94
Finding
Unconfirmed Relocation of Existing Notion Databases<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 94–101 and 124 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Instructions ```text If a database (not a page) named exactly `Reading List` exists: - If its parent is already `SECOND_BRAIN_ID`, do nothing — record `READING_LIST_ID` and skip to Step 3. - If its parent is something else, call `notion-move-pages` to move it under `SECOND_BRAIN_ID`. Record `READING_LIST_ID`. - Do NOT modify its existing schema, even if it differs from the spec below. Adopt as-is. ``` The same behavior is required for the Inbox database: ```text Same pattern as Step 2. Search → adopt-and-move if exists → otherwise create with: ``` ### Technical Analysis The skill performs a workspace-wide search for databases with the generic names `Reading List` and `Inbox`. It treats an exact title match as sufficient proof that a database belongs to this skill and may move that database beneath `SECOND_BRAIN_ID`. An integration-visible database can belong to another user, team, workflow, or project. Visibility through the Notion integration does not establish ownership or authorization to reorganize the object. The skill does not validate a stable database identifier, inspect provenance, limit adoption to descendants of the selected parent, or obtain user confirmation before moving an existing resource. Moving a database also changes its workspace hierarchy and may alter the practical access context inherited from its parent. ### Attack Path 1. An attacker or another workspace collaborator creates a database named exactly `Reading List` or `Inbox`. 2. The database is placed somewhere visible to the Notion integration. 3. A user invokes the second-brain setup skill. 4. The skill performs a global internal search using the generic database name. 5. The attacker-controlled or unrelated database is returned as an exact-name match. 6. Because its current pa ...[truncated 798 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Only adopt a database automatically when it is already a direct child of the selected `Second Brain` page. 2. If an exact-name match exists elsewhere, display its title, current parent, and URL, then require explicit user confirmation before moving it. 3. Do not use a generic title as the sole resource identity. Persist and validate database IDs created by the skill where possible. 4. If ownership cannot be established, create a new database under `Second Brain` or stop with a conflict report rather than modifying the existing object. 5. Before any move, verify that the source database is within a user-approved workspace subtree and that the destination's sharing configuration is appropriate. 6. Report duplicate exact-name matches instead of selecting one implicitly. ]]>

T05 · Unauthorized Access and Privilege Escalation

Note
Location
SKILL.md:57
Finding
Automatic Creation Under an Arbitrary Integration-Visible Page<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 57–84 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Low ### Vulnerable Instructions ```text Call `notion-search` with: ```json {"query": "", "query_type": "internal"} ``` This returns every page the integration can see. From the results: - If you see a page already titled exactly `Second Brain`, save its `page_id` as `SECOND_BRAIN_ID` and skip to Step 2. - Otherwise, pick any visible page as `INTEGRATION_PARENT_ID`. Prefer one that looks like a top-level workspace page (no parent, or named like `Home`, `Workspace`, `IronClaw`, etc.). ``` The selected page is then used as the creation parent: ```json { "pages": [ { "parent": {"type": "page_id", "page_id": "<INTEGRATION_PARENT_ID>"}, "properties": {"title": "Second Brain"} } ] } ``` ### Technical Analysis The skill enumerates every page visible to the integration and heuristically selects any visible page as a write target. A page being visible to an integration does not establish that it is an appropriate location for new content. The preference for names such as `Home`, `Workspace`, or `IronClaw` is not an authorization check. In a workspace with multiple accessible areas, the selected page may belong to an unrelated team, shared project, or sensitive hierarchy. The skill does not present candidate parents to the user or require confirmation before creating the `Second Brain` page and its child databases. ### Attack Path 1. The Notion integration has access to multiple pages. 2. No existing page titled exactly `Second Brain` is found. 3. An unrelated or attacker-influenced visible page has a plausible title such as `Home` or `Workspace`. 4. The skill chooses that page as `INTEGRATION_PARENT_ID` using its heuristic. 5. The skill creates `Second Brain`, `Reading List`, and `Inbox` beneath that page. 6. Users with access to the selected parent may receive unintende ...[truncated 638 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require the user to select or explicitly approve the parent page when no existing `Second Brain` page is found. 2. Present a minimal list of candidate page titles and URLs without exposing unnecessary page content. 3. Do not infer authorization from generic page titles or apparent top-level placement. 4. Restrict creation to a user-provided page ID or a previously approved and persisted parent ID. 5. Before creation, confirm that the integration has the necessary write access and warn that child objects may inherit the parent's sharing configuration. 6. If no parent has been explicitly approved, stop safely and provide instructions for creating and sharing a dedicated parent page. ]]>
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Unrestricted Tool Access

Medium
Category
Excessive Agency
Content
## STRICT RULES — read first

You will execute a **fixed sequence of Notion MCP tool calls**. You are NOT to invent pages, write markdown content, or call any tool not listed in the sequence below.

✅ **The only output of this skill:**
1. One **page** titled exactly `Second Brain` (no body content, no icon, no cover)
Confidence
80% confidence
Finding
Skill grants unrestricted tool access without appropriate constraints. An agent with unfettered tool access can perform arbitrary actions including file modification, network requests, and code execution.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill can create and move existing Notion databases based on broad search results, but it does not require an explicit user confirmation before modifying workspace structure. In particular, the adopt-and-move behavior for any exact-match `Reading List` or `Inbox` database may relocate pre-existing content the user did not intend this setup to touch.

Static analysis

No suspicious patterns detected.