CVE-2026-48709: Missing Authorization in OliveTin ValidateArgumentType RPC Endpoint

OliveTin is an open-source web application designed to expose predefined shell commands and administrative execution workflows through a clean, web-based user interface. It is commonly deployed by system administrators to run repetitive maintenance tasks, service restarts, or deployment scripts without giving users direct SSH access. To protect these administrative workflows, OliveTin supports strict authentication controls, including the AuthRequireGuestsToLogin directive, which is designed to block unauthenticated access to the application dashboards and backend APIs.

However, in OliveTin versions prior to 3000.13.0, the exposed attack surface includes a vulnerability in the handling of Remote Procedure Call (RPC) requests. Specifically, the ValidateArgumentType endpoint, implemented in the service/internal/api/api.go component, does not implement authentication or authorization validation. This means that even when the system is configured to require authentication for guest users, this specific endpoint remains fully exposed to external, unauthenticated network traffic.

The missing access control is classified as CWE-862 (Missing Authorization) and carries a CVSS score of 3.7. Although the vulnerability does not directly lead to arbitrary code execution, it functions as an information disclosure oracle. By querying this endpoint, an unauthorized remote actor can systematically brute-force action binding IDs and enumerate valid action structures, disclosing sensitive internal script metadata and parameter types.

The root cause of this vulnerability lies in the inconsistent application of security middleware and helper functions within the backend API layer. In a secure OliveTin deployment, endpoints that interact with administrative actions or configurations check the requester's identity. This validation is usually performed by calling auth.UserFromApiCall followed by api.checkDashboardAccess, which ensures that the client possesses the necessary privileges to query the backend.

During the implementation of the parameter validation feature, developers introduced the ValidateArgumentType RPC endpoint. This endpoint was designed to allow front-end clients to validate user inputs dynamically before submitting them to the execution queue. However, the handler function for ValidateArgumentType was written without any references to auth.UserFromApiCall or api.checkDashboardAccess. Consequently, the API router executed incoming validation requests from unauthenticated clients without validating session tokens or checking access policies.

The impact of this missing authorization is amplified by the internal mechanics of OliveTin's action-binding identifiers. The software represents action bindings using SHA256 hashes generated from the human-readable action titles (e.g., "Ping", "Restart Apache"). Because administrative actions often use common, dictionary-based terminology, the binding IDs are predictable. An unauthenticated attacker can precompute hashes of expected actions and use the exposed validation endpoint as a verification oracle.

To understand the exact breakdown, we analyze the vulnerable code path inside service/internal/api/api.go. In the vulnerable state, the ValidateArgumentType method completely lacks authorization wrappers:

// VULNERABLE CODE (Pre-3000.13.0)
func (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {
    // No authentication check is performed here
    if api.argumentNotFoundForValidation(req.Msg) {
        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", req.Msg.BindingId))
    }
 
    err := api.validateArgumentTypeInternal(req.Msg)
    desc := ""
    if err != nil {
        desc = err.Error()
    }
 
    return connect.NewResponse(&apiv1.ValidateArgumentTypeResponse{
        Valid:       err == nil,
        Description: desc,
    }), nil
}

The patch in commit a3865704c854061452a4ab5f6d95de3312698ccd introduces verification logic. The developers added explicit checks to authenticate the user and ensure they have dashboard access and action-specific permissions before validating inputs:

// PATCHED CODE (3000.13.0)
func (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {
    // Extract and authenticate the calling user
    user := auth.UserFromApiCall(ctx, req, api.cfg)
    if err := api.checkDashboardAccess(user); err != nil {
        return nil, err
    }
 
    // Verify the user has access to the specific binding ID
    if err := api.validateArgumentTypeBindingAccess(user, req.Msg); err != nil {
        return nil, err
    }
 
    if api.argumentNotFoundForValidation(req.Msg) {
        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", req.Msg.BindingId))
    }
 
    return api.validateArgumentTypeConnectResponse(req.Msg)
}

While the applied fix successfully blocks unauthenticated access, the implementation of validateArgumentTypeBindingAccess introduces a potential side-channel vulnerability for low-privileged authenticated users. If a requested binding ID does not exist, the API returns a CodeNotFound error (404 status). If the action exists but the user lacks permissions, the API yields CodePermissionDenied (403 status). This behavioral difference allows authenticated users to enumerate restricted administrative action IDs, indicating the remediation is not perfectly robust against credentialed internal reconnaissance.

Exploitation of CVE-2026-48709 requires an unauthenticated network path to the OliveTin API port (typically port 1337). No specific user interaction is needed. The attack methodology involves querying the ValidateArgumentType endpoint with precomputed SHA256 hashes representing common administrative action titles.

To construct the attack oracle, the threat actor computes a series of SHA256 hashes. For example, the string "Backup Database" produces 80628e9323f66a2b89d4d5e172dfcbef0eb912efc4d26bbf1f579be408661633. The attacker sends a POST request to /api/ValidateArgumentType with this target binding ID and a candidate argument name:

{
  "bindingId": "80628e9323f66a2b89d4d5e172dfcbef0eb912efc4d26bbf1f579be408661633",
  "argumentName": "database_name",
  "value": "temp",
  "type": "ascii"
}

If the server responds with a standard 200 OK JSON block containing validation success or failure, the attacker confirms both that the "Backup Database" action exists and that "database_name" is a valid parameter name. Conversely, if the server returns a CodeNotFound error, the attacker knows that either the action hash is incorrect or the parameter name is invalid. This allows an automated tool to sweep through a wordlist of actions and parameters, extracting a blueprint of the OliveTin server configuration.

The primary impact of this vulnerability is unauthorized information disclosure of internal system metadata. OliveTin configurations contain lists of shell scripts, system management actions, and environment settings. By leaking action titles and argument constraints, an unauthenticated attacker gains detailed insight into the target host's software stack, network topology, backup locations, and administrative workflows.

This leakage directly feeds the initial phases of more complex attack chains. For instance, discovering an action named "Restart PostgreSQL Service" with an argument "port" informs the attacker that PostgreSQL is running locally and points to potential command injection vectors within that action's script template. The vulnerability acts as an effective reconnaissance tool, converting black-box OliveTin deployments into transparent, targetable systems.

The CVSS v3.1 base score of 3.7 reflects the low-impact nature of the direct leakage, but does not capture the downstream risks of custom action scripts. If OliveTin scripts are poorly sanitized, exposing the exact parameter names and types lowers the difficulty of constructing a successful downstream command injection attack.

The primary and most effective remediation path is to upgrade OliveTin to version 3000.13.0 or higher, where authorization controls are integrated. The official fix requires all validation requests to pass through the dashboard access verification, locking out unauthenticated guest users immediately when guest access is disabled.

If upgrading is not immediately feasible, administrators should deploy external protective controls. Applying a reverse proxy such as Nginx, Caddy, or Envoy in front of OliveTin allows for URL-level access control. Administrators should configure the reverse proxy to block or reject POST requests targeting the /api/ValidateArgumentType and /api/oliveTinAPI/ValidateArgumentType endpoints from untrusted networks.

Additionally, administrators can implement defensive naming strategies for their OliveTin actions. Because binding IDs are SHA256 hashes of the action titles, using long, randomized, or high-entropy action titles (e.g., "Main DB Backup - Secure98234") renders dictionary-based SHA256 brute-forcing impossible. This effectively neutralizes the predictability of the binding IDs, rendering the validation oracle useless to external scanners.