T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:194
- Finding
- Hosted Functions Inherit Account-Wide Maton Authority## Vulnerability Details **File Location**: `SKILL.md`, lines 194–218 and 546–548 **Vulnerability Type**: Excessive runtime privileges and insufficient authorization isolation **Risk Level**: Medium ### Vulnerable Code ```text 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. 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. ``` ```text The sandbox sees the variables from `function env` plus the runtime-injected `MATON_API_KEY` that carries the deploying account's identity (see [Functions](#functions)). The same applies when the function runs as a trigger destination. ``` ### Technical Analysis A hosted function intended to perform a narrow Buffer operation receives the identity of the entire deploying Maton account through the runtime-injected `MATON_API_KEY`. There ...[truncated 2190 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the account-level runtime credential with a function-specific, short-lived token. 2. Require each function deployment to declare an explicit allowlist containing: - The permitted application, such as `buffer`. - The exact connection identifier. - The allowed endpoint, such as `/buffer/`. - The permitted GraphQL operations or operation classes. - Whether read or mutation access is required. 3. Enforce the allowlist at the Maton gateway rather than relying on handler logic or written policy. 4. Default functions to read-only access and require separate approval for mutation privileges. 5. Prevent a trigger destination from increasing the function's authorization scope. 6. Record and expose an auditable permission manifest during deployment and invocation. 7. Retain `DENY_ALL` as the default network policy, but do not treat it as a substitute for API-level authorization isolation. 8. Revoke function credentials automatically when the function is deleted or the associated automation ends. 9. Until technical isolation is available, use a dedicated Maton account containing only the single Buffer connection required by the function.