Back to skill

Security audit

zoho-bookings

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed Zoho Bookings integration, with meaningful cautions around Maton credentials, hosted functions, and persistent trigger destinations.

Install only if you intend to use Maton as the OAuth gateway for Zoho Bookings. Prefer OAuth over long-lived API keys, approve every write and automation separately, keep function network policy at DENY_ALL unless you explicitly need named hosts, and use a dedicated Maton account with only the needed connection before deploying hosted functions if your main account has other app connections.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:184
Finding
Hosted Functions Inherit Account-Wide Maton Access## Vulnerability Details **File Location**: `SKILL.md:184-205` **Vulnerability Type**: Excessive authorization scope for hosted functions **Risk Level**: Medium **Relevant Code Snippet**: ```markdown > **Execution identity.** A function runs as the Maton account that deployed it — the same identity > as the `maton` CLI session that performed the deploy, no more and no less. It receives that > identity as a runtime-injected `MATON_API_KEY`: the key is placed in the sandbox's environment > only while the function runs, is never stored in the package or the code, is never set through > `function env`, and only the authenticated account owner can create, deploy, or update a function. Functions are `PRIVATE` unless the user chooses otherwise. Outbound network access is a > platform-enforced setting, not a handler decision: with `--network-policy DENY_ALL` the sandbox > cannot open any outbound connection regardless of what the code does, and that is the policy every > example here uses. Opening the network is the exception, made per function, only when the user has > named the hosts the code must reach and approved it. > > Invoking a function is an authenticated call: the URL alone grants nothing, and a request without > a Maton `Authorization` header is rejected with `401` before the handler runs — which is why > `maton api` is the documented way to call one. > > **Before any deploy or invocation, give the user a least-privilege summary and get approval on it:** the handler > (which they wrote or reviewed — never deploy code they did not), the connections the deploying > account holds (`maton connection list`), which is exactly what the function will be able to reach, > and the network policy. Prefer an account whose connections are only the ones the function needs. ``` ### Technical Analysis A function intended to perform a narrowly scoped Zoho Bookings operation receives a runtime-injected `MATON_API_KEY` rep ...[truncated 1940 chars]
Remediation
## Remediation Suggestions 1. Replace the account-wide runtime credential with a short-lived, function-specific capability. 2. Bind each capability to explicitly approved connection IDs rather than every connection held by the account. 3. Enforce an application allowlist, such as only `zoho-bookings`, on the gateway. 4. Restrict permitted native API paths and HTTP methods for each function. 5. Default functions to read-only access and require separate authorization for write methods. 6. Validate these restrictions server-side; do not rely solely on handler instructions or user review. 7. Record immutable audit logs identifying the function, connection, endpoint, method, and trigger responsible for each request. 8. Expire and revoke the scoped credential automatically when the function or associated automation is deleted. 9. Until technical scoping is available, use a dedicated Maton account containing only the minimum connection required by the function.

T08 · Insecure Dependencies

Note
Location
SKILL.md:33
Finding
Package Installation Lacks Artifact Integrity Verification## Vulnerability Details **File Location**: `SKILL.md:33-45` **Vulnerability Type**: Unverified third-party dependency installation **Risk Level**: Low **Relevant Code Snippet**: ```markdown ## Installation ### NPM ```bash npm install -g @maton/cli@0.3.1 ``` ### Homebrew ```bash brew install maton-ai/cli/maton brew pin maton ``` ``` ### Technical Analysis The Skill instructs users to install executable software from npm or a vendor-controlled Homebrew tap. The npm version is pinned, and Homebrew is pinned after installation, which reduces unexpected upgrades. However, neither procedure verifies a cryptographic signature, expected digest, package provenance attestation, or reproducible artifact identity before execution. Version pinning alone does not protect against compromise of the publisher account, package registry, release artifact, or Homebrew tap. A modified artifact published under the expected name and version could execute installation hooks or later run with the local user's permissions. Global npm installation also increases exposure by placing the executable in a shared command path. No evidence indicates that the named packages are currently malicious. The issue is the absence of integrity controls in the documented installation process. ### Attack Path 1. An attacker compromises the package publisher, registry release, vendor tap, or associated release infrastructure. 2. The attacker replaces or publishes a malicious artifact under the expected package or formula identity. 3. A user follows the documented installation command. 4. The package manager downloads and installs the artifact without comparison against an independently supplied digest or signature. 5. Installation hooks or the installed CLI execute under the user's local privileges. 6. The compromised component may access Maton authentication state, connected-account data, or other resources available to that user. ### I ...[truncated 493 chars]
Remediation
## Remediation Suggestions 1. Publish expected SHA-256 or stronger digests through an independently authenticated release channel. 2. Provide signed release artifacts and document signature verification before installation. 3. Adopt package provenance attestations, such as npm provenance and Sigstore-compatible verification. 4. Document the exact trusted npm scope, publisher identity, Homebrew tap, and release source. 5. Prefer a verified standalone binary or package with reproducible build metadata where practical. 6. Avoid global npm installation when a project-local or isolated installation is sufficient. 7. Use lockfiles containing registry-resolved integrity hashes for SDK dependencies. 8. Continue pinning versions, but require deliberate review of release notes and updated integrity metadata before upgrades. 9. Advise users not to run package installation with elevated operating-system privileges unless strictly necessary.
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.