CVE-2026-48709: Root-Cause Authorization Fix for OliveTin ValidateArgumentType

Vulnerability

CVE-2026-48709 describes missing authorization in OliveTin's ValidateArgumentType RPC endpoint. According to the advisory context from CVE.org and the referenced fix commit a3865704c854061452a4ab5f6d95de3312698ccd, versions prior to 3000.13.0 allowed unauthenticated guest users to reach argument validation logic without the same access-control checks applied to other action-related APIs.

The vulnerable flow directly invoked internal validation:

err := api.validateArgumentTypeInternal(req.Msg)

That behavior exposed an oracle on binding existence and argument requirements. A remote caller could probe binding IDs, argument names, and type expectations by observing response differences, enabling enumeration of administrative action metadata even without permission to view the underlying action.

Patch

The patch introduces a dedicated authorization gate for ValidateArgumentType and places it before the validation response is generated. The new logic first resolves the caller identity, enforces dashboard access, and then checks whether the caller may validate against the requested binding.

func (api *oliveTinAPI) validateArgumentTypeBindingAccess(user *authpublic.AuthenticatedUser, msg *apiv1.ValidateArgumentTypeRequest) error {
	if msg == nil || msg.BindingId == "" {
		return nil
	}

	return api.errUnlessUserMayValidateArgumentTypeForBinding(user, msg.BindingId)
}

func (api *oliveTinAPI) errUnlessUserMayValidateArgumentTypeForBinding(user *authpublic.AuthenticatedUser, bindingID string) error {
	binding := api.executor.FindBindingByID(bindingID)
	if binding == nil || binding.Action == nil {
		return connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", bindingID))
	}

	if !api.userCanViewAction(user, binding.Action) {
		return connect.NewError(connect.CodePermissionDenied, fmt.Errorf("permission denied"))
	}

	return nil
}

The handler now performs these checks in sequence before calling the validation response helper. This aligns ValidateArgumentType with the authorization model already expected for action visibility.

The accompanying tests in the same commit verify three important cases: guests are denied when login is required, users lacking view permission are denied for restricted actions, and authorized users retain expected validation behavior.

Review

Pros

• The patch addresses the actual trust-boundary failure by moving authorization ahead of validation, rather than trying to sanitize validation output after the fact.
• Binding-level access is tied to userCanViewAction(), which is a strong design choice because it reuses the existing action visibility policy instead of inventing a separate ACL path for this RPC.
• The new CodePermissionDenied path blocks low-privilege enumeration of restricted actions, and the dashboard access check blocks guest access when guest login is disabled by policy.
• Regression coverage is solid for the reported issue: guest denial, denied access for view:false, and successful access for authorized users are all explicitly tested in api_test.go.

Cons

• The helper returns CodeNotFound for nonexistent bindings and CodePermissionDenied for unauthorized existing bindings. That distinction may still leak some existence information to callers who can reach the endpoint, although it is narrower than the original oracle.
• The access check is conditional on msg != nil and BindingId != "". If there are alternate validation modes that do not require a binding ID, they remain outside this specific authorization gate and should be reviewed separately.
• The patch is scoped to this RPC only. If other metadata-oriented endpoints call shared validation or binding lookup paths without equivalent authorization, similar enumeration issues could persist elsewhere.

Verdict

Root-cause.

The original flaw was missing authorization before sensitive validation logic. This patch corrects that by enforcing both session-level access and binding/action view authorization before processing the request. The implementation is narrowly targeted but conceptually correct, and the tests demonstrate that the endpoint now follows the same access-control expectations as related action APIs. Engineers should still review whether differing NotFound versus PermissionDenied responses are acceptable for their threat model, but the primary vulnerability described in NVD is substantively fixed by the upstream patch.