Security audit

gmail

Security checks for vulnerabilities and agentic risk

Overview

This is a disclosed Gmail integration that handles sensitive email and automation, with clear user-approval rules for writes, connections, and persistent forwarding.

Install only if you trust Maton with access to the Gmail account you connect. Prefer OAuth and the narrowest Gmail scopes, confirm every send/delete/label/draft operation, and be especially careful with triggers or destinations because they can keep forwarding future email events until removed.

A.I.G

Vulnerability Patterns

Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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)

T08 · Insecure Dependencies

Warning

Location: SKILL.md:34
Finding: Third-Party CLI Installation Without Artifact Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-41` **Vulnerability Type**: Supply-chain risk in credential-handling dependencies **Risk Level**: Medium ### Vulnerable Code ```bash npm install -g @maton/cli@0.3.1 ``` ```bash brew install maton-ai/cli/maton brew pin maton ``` ### Technical Analysis The Skill directs users to install the Maton CLI globally from npm or a third-party Homebrew tap. Although the npm package version is pinned and the Homebrew package is pinned after installation, the instructions do not verify an artifact checksum, package signature, provenance attestation, or immutable content digest. Version pinning reduces unexpected upgrades but does not protect against a compromised publisher account, registry artifact, package release, or Homebrew tap. In particular, `brew pin maton` occurs only after Homebrew resolves and installs the tap's current artifact. The installed CLI is highly sensitive because the Skill entrusts it with Maton OAuth sessions, API keys, Gmail content, hosted-function deployment, trigger configuration, and Gmail write operations. Global installation also increases the exposure because the executable becomes available across the user's environment. ### Attack Path 1. An attacker compromises the npm publisher, package registry artifact, Homebrew tap, or release infrastructure associated with the Maton CLI. 2. The attacker publishes malicious content under the expected package name and version, or alters the artifact resolved by the Homebrew formula. 3. A user follows the Skill's documented installation command without independently verifying the artifact. 4. Installation scripts or the resulting executable run with the user's local privileges. 5. When the user authenticates or performs Gmail operations, the compromised CLI accesses Maton credentials, OAuth sessions, API responses, and mailbox data. 6. The malicious dependency can exfiltrate data, alter Gmail requests, create persistent trigger ...[truncated 837 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Publish SHA-256 or stronger checksums for every reviewed CLI artifact and require verification before installation. 2. Provide package signatures or Sigstore provenance attestations tied to a documented publisher identity. 3. Pin Homebrew installation to a reviewed formula revision and immutable bottle digest rather than pinning only after installation. 4. Document the authoritative source repository, npm publisher, Homebrew tap owner, and release-signing identity. 5. Prefer a project-local or isolated installation over a global npm installation where operationally possible. 6. Disable or carefully review package lifecycle scripts during installation when supported. 7. Provide a reproducible-build or software bill of materials process so users can validate that registry artifacts correspond to reviewed source. 8. Re-review dependencies and release notes before changing any pinned version. 9. Continue storing credentials in the operating system credential store and ensure the CLI never exposes them in command-line arguments, logs, or configuration files. ]]>

T08 · Insecure Dependencies

Warning

Location: SKILL.md:1201
Finding: Optional SDK Dependencies Lack Cryptographic Artifact Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:1201-1227` **Vulnerability Type**: Supply-chain risk in application dependencies **Risk Level**: Medium ### Vulnerable Code ```bash pip install 'maton-ai==0.3.1' ``` ```python from maton_ai import Maton, login # login() maton = Maton() # maton = Maton(api_key="...") result = maton.google_mail.message.list(max_results=10) ``` ```bash npm install @maton/sdk@0.3.1 ``` ```javascript import { Maton, login } from "@maton/sdk"; // await login() const maton = new Maton(); // const maton = new Maton({ apiKey: "..." }); const result = await maton.google_mail.message.list({ maxResults: 10 }); ``` ### Technical Analysis The optional Python and JavaScript examples install SDK packages from public package ecosystems and then use those packages in authentication and Gmail API workflows. Exact version pinning is present, which limits version drift, but the instructions do not pin immutable artifact hashes or verify signatures and provenance. These SDKs operate inside the caller's application process. Consequently, a compromised SDK has direct access to process environment variables, SDK-managed sessions, explicitly supplied API keys, Gmail responses, and any other application data available to that process. The commented examples also show that callers may pass an API key directly to the SDK, making dependency integrity especially important. ### Attack Path 1. An attacker compromises the PyPI or npm publisher, build process, registry artifact, or a transitive dependency used by the SDK. 2. A malicious artifact is distributed under the expected package and version or is selected through an inadequately locked transitive dependency. 3. A developer installs the SDK using the documented command without verifying its artifact hash or provenance. 4. The malicious package executes during installation, import, initialization, login, or an API call. 5. The package reads process credentials or intercepted G ...[truncated 794 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Supply hash-locked installation instructions, such as a Python requirements file using `--require-hashes` and a JavaScript lockfile with verified integrity metadata. 2. Publish and verify package signatures or Sigstore provenance attestations. 3. Lock and audit transitive dependencies, not only the top-level SDK version. 4. Use isolated virtual environments or containers with minimal filesystem and environment access. 5. Avoid passing API keys directly in source code; use an approved secret store and inject credentials only into the process that requires them. 6. Ensure secrets are removed from the environment of unrelated child processes. 7. Generate and publish an SBOM for each reviewed SDK release. 8. Run dependency vulnerability and provenance checks before installation and whenever versions change. 9. Prefer OAuth sessions with narrowly scoped Gmail permissions and promptly revoke unused connections. ]]>

SkillSpector

Vulnerability Patterns

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
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.