T09 · Insecure Skill Coding Practices
- Location
src/sync.ts:12- Finding
Ignored secrets may be uploaded because .gitignore is not applied
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a real Notion sync tool, but it needs review because it can upload unintended local files or secrets and stores the Notion token plainly.
Install only if you are comfortable sending the chosen directory's file contents and structure to Notion. Before syncing, run dry-run, use a narrow directory, add explicit ignores for secrets such as .env files, credentials, keys, and private configs, avoid syncing untrusted repositories with symlinks, and treat .notion-sync.json as a sensitive file because it contains the Notion token.
src/sync.ts:12Ignored secrets may be uploaded because .gitignore is not applied
src/config.ts:18Notion API token is exposed through command-line arguments and plaintext configuration
src/sync.ts:19Symbolic links can disclose files outside the configured synchronization root
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
notion-sync sync --dir /some/path # sync a specific directory notion-sync status # show sync state notion-sync ignore list # list ignore patterns notion-sync ignore add "*.env" # add ignore pattern
### Default Ignore Patterns
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
notion-sync sync --dir /some/path # sync a specific directory notion-sync status # show sync state notion-sync ignore list # list ignore patterns notion-sync ignore add "*.env" # add ignore pattern
### Default Ignore Patterns
The lockfile pins brace-expansion 2.0.2, which is reported vulnerable to denial-of-service conditions from pathological brace patterns. In this package it is only a transitive dependency via glob/minimatch, so exploitability depends on whether untrusted glob-like patterns are accepted at runtime, but the dependency risk is real.
form-data 4.0.5 is a real vulnerable dependency according to the advisory, with CRLF injection risk when multipart field names or filenames are attacker-controlled. Here it is transitive under the Notion client stack, so impact depends on whether this skill passes untrusted names into multipart uploads, but the dependency weakness itself is genuine.
js-yaml 3.14.2 has multiple reported CPU-exhaustion issues during parsing of crafted YAML. Because this skill includes gray-matter and likely processes front matter from local files being synced, malicious or malformed Markdown/YAML content could trigger denial of service during parsing.
minimatch 9.0.5 is flagged for ReDoS-style backtracking on crafted patterns. This skill's purpose includes syncing directories and managing ignore patterns, which makes attacker- or user-controlled glob patterns more likely than in a generic package and increases practical risk of CPU exhaustion.
picomatch 4.0.3 is reported vulnerable to method-injection and ReDoS issues in crafted glob expressions. Although it appears in dev tooling here, if any build or local automation paths process untrusted patterns, this can still cause incorrect matching or denial of service; however, this is less directly dangerous to end users than runtime deps.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
The README promotes syncing arbitrary workspace directories and file contents to Notion but does not clearly warn that project data will be transmitted to a third-party SaaS. In this skill context, that omission is meaningful because users may run it from sensitive repositories and unintentionally exfiltrate source code, secrets, internal docs, or regulated data.
The documentation instructs users to pass the Notion API token directly on the command line, which can leak credentials via shell history, terminal logging, CI logs, or process inspection by other local users. Because this skill is specifically about authenticating to a third-party API, exposing the token can enable unauthorized access to the connected Notion workspace.
The skill is explicitly designed to sync local files and directories to Notion, a third-party service, but it does not warn users that file contents and directory structure may be transmitted externally. In a workspace automation context, users may invoke this on sensitive repositories or documents and unintentionally exfiltrate proprietary or confidential data.
The initialization example passes the Notion token directly on the command line, which can expose credentials via shell history, process listings, logs, or terminal recordings. This is especially risky in shared development environments, CI systems, or when users copy commands into monitored shells.
The package description advertises syncing 'any workspace or directory' to Notion, which is a broad trigger scope for an agent skill that can exfiltrate local content to a third-party service. In an agent context, overly broad scope increases the chance of accidental oversharing of sensitive files because users are not warned that the operation may recursively include large portions of the workspace.
The manifest describes local-to-Notion syncing without warning that local workspace contents may be transmitted to a remote third-party service. This omission is risky for agent-driven use because users may interpret the action as a local formatting or indexing task rather than outbound data transfer, leading to unintended disclosure.
The config initialization path stores the Notion API token directly in .notion-sync.json via saveConfig without any warning, masking, or safer secret-handling mechanism. Because this file is created inside the workspace and only excluded by convention, the token can be exposed through accidental commits, backups, file sharing, or other local tooling that reads project files.
This function reads arbitrary workspace files and uploads their full contents to Notion, but the code shown provides no in-flow confirmation, disclosure, scope preview, or guardrail before transmitting data to an external SaaS. In a sync skill, that behavior is expected, but it is still risky because users may unintentionally sync secrets, private notes, config files, or other sensitive content if ignore patterns are incomplete or misconfigured.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"node": ">=18"
},
"dependencies": {
"@notionhq/client": "^2.2.15",
"chalk": "^5.3.0",
"commander": "^12.0.0",
"glob": "^10.3.10",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"dependencies": {
"@notionhq/client": "^2.2.15",
"chalk": "^5.3.0",
"commander": "^12.0.0",
"glob": "^10.3.10",
"gray-matter": "^4.0.3",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"dependencies": {
"@notionhq/client": "^2.2.15",
"chalk": "^5.3.0",
"commander": "^12.0.0",
"glob": "^10.3.10",
"gray-matter": "^4.0.3",
"ignore": "^5.3.0"
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"@notionhq/client": "^2.2.15",
"chalk": "^5.3.0",
"commander": "^12.0.0",
"glob": "^10.3.10",
"gray-matter": "^4.0.3",
"ignore": "^5.3.0"
},
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"chalk": "^5.3.0",
"commander": "^12.0.0",
"glob": "^10.3.10",
"gray-matter": "^4.0.3",
"ignore": "^5.3.0"
},
"devDependencies": {
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"commander": "^12.0.0",
"glob": "^10.3.10",
"gray-matter": "^4.0.3",
"ignore": "^5.3.0"
},
"devDependencies": {
"@types/node": "^20.11.0",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"ignore": "^5.3.0"
},
"devDependencies": {
"@types/node": "^20.11.0",
"tsup": "^8.0.1",
"typescript": "^5.3.3"
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"@types/node": "^20.11.0",
"tsup": "^8.0.1",
"typescript": "^5.3.3"
}
}
No suspicious patterns detected.