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.
