T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:184
- Finding
- Hosted Functions Inherit Account-Wide Maton Authority<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 184-210 **Vulnerability Type**: Excessive runtime privileges and insufficient credential scoping **Risk Level**: High ### Vulnerable 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. > > **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 hosted function receives a runtime-injected `MATON_API_KEY` representing the identity of the entire deploying Maton account. The document explicitly states that all connections held by that account are available to the function. This exceeds the minimum privilege required for a function intended to perform a specific Cal.com operation. The restriction that a function should access only the connection for which it was written is policy-based rather than enforced through a connection-scoped credential. The `DENY_ALL` network policy reduces exposure by preventing arbitrary outbound connections, but it does not establish application-level authorization boundaries inside the Maton platform. A function can still use the injected account credential to access other applications or connections available through the Maton gat ...[truncated 1606 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the account-wide runtime credential with a short-lived, function-specific token. 2. Bind the token to an explicit allowlist containing: - Permitted application, such as `cal-com`. - Permitted connection IDs. - Permitted API paths. - Permitted HTTP methods. 3. Require a machine-enforced permission manifest when a function is created or deployed. 4. Reject undeclared application or endpoint access at the Maton gateway. 5. Ensure trigger invocation does not widen the function’s original authorization scope. 6. Require separate approval whenever a function’s code or permission manifest changes. 7. Record and expose audit logs showing the application, connection, endpoint, and method used by each function invocation. 8. Prefer dedicated Maton accounts containing only the connections required for a function until granular capability tokens are available. 9. Preserve the existing `DENY_ALL` outbound-network default, but do not treat it as a substitute for gateway-level authorization controls. ]]>