CVE-2026-67439: Incorrect Authorization Leading to Log Leak in OliveTin

OliveTin exposes predefined shell commands to users through a web interface. Administrators use Access Control Lists (ACLs) to manage execution permissions separately from log-viewing capabilities.

This design ensures that low-privileged users can trigger operational tasks without seeing command outputs, which may contain sensitive system details, configurations, or environmental secrets.

The vulnerability, designated as CVE-2026-67439, resides in the synchronous execution API endpoints. These endpoints run actions and return the execution results directly to the client.

This architectural bypass violates the configured access controls, allowing users with execution rights (exec:true) but restricted log viewing (logs:false) to fully read the execution logs.

The impact is limited to information disclosure. An attacker cannot escalate execution rights beyond their pre-assigned actions, but they can view data printed to standard output or standard error.

The core issue exists in the service/internal/api/api.go file within the OliveTin backend. The software exposes two synchronous execution routes: StartActionAndWait and StartActionByGetAndWait.

Unlike their asynchronous counterparts, these endpoints block execution until the shell command finishes and then package the execution metrics directly into a response message.

While the application successfully verifies that the user holds the necessary execution rights to trigger an action, it fails to perform post-execution verification before serializing the log payload.

The endpoints convert the backend execution output (InternalLogEntry) straight into a Protobuf payload via api.internalLogEntryToPb without evaluating the user's log privileges.

The developers omitted the invocation of api.isLogEntryAllowed within these specific handlers. Because this check was missing, the application sent the command's complete stdout and stderr back to the client interface. The lack of validation leads to a complete bypass of the log-viewing restriction.

To understand the vulnerability, examine the difference between the unpatched code and the patched version. The unpatched endpoints executed actions and serialized the raw internal logs directly to the client. The fix introduces a structured authorization helper and channels the results through an explicit permission validation routine.

// BEFORE THE PATCH (Vulnerable Code)
// The backend directly serializes internal logs without evaluating log permissions
internalLogEntry, ok := api.startActionAndWaitRun(binding, args, justification, user)
if !ok {
	return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("execution not found"))
}
return connect.NewResponse(&apiv1.StartActionAndWaitResponse{
	LogEntry: api.internalLogEntryToPb(internalLogEntry, user), // <-- Direct exposure
}), nil

// AFTER THE PATCH (Fixed Code)
// The backend now routes the log payload through permission validation helpers
func (api *oliveTinAPI) requireLogEntryAllowed(entry *executor.InternalLogEntry, user *authpublic.AuthenticatedUser) error {
	if api.isLogEntryAllowed(entry, user) {
		return nil
	}
	return connect.NewError(connect.CodePermissionDenied, fmt.Errorf("permission denied to view this execution"))
}
 
func (api *oliveTinAPI) logEntryForAllowedViewer(internalLogEntry *executor.InternalLogEntry, user *authpublic.AuthenticatedUser) (*apiv1.LogEntry, error) {
	if err := api.requireLogEntryAllowed(internalLogEntry, user); err != nil {
		return nil, err
	}
	return api.internalLogEntryToPb(internalLogEntry, user), nil
}

The refactored structure introduces requireLogEntryAllowed which actively calls isLogEntryAllowed to check the user's ACL. If the user lacks permissions, the application halts the transaction and returns a connect.CodePermissionDenied error. This mechanism guarantees that execution outputs are filtered securely before leaving the system.

To exploit this vulnerability, an attacker must have network access to the OliveTin instance and a valid set of credentials. The user account must be granted execution access to at least one action, but have log access explicitly disabled. This setup represents a standard configuration for restricted system operators.

The attacker makes a direct request to the synchronous endpoints instead of using the standard client UI flow. For example, the attacker issues a POST request to /apiv1.OliveTinService/StartActionAndWait containing the target command identifier. Alternatively, a GET request can be structured to target the /apiv1.OliveTinService/StartActionByGetAndWait endpoint.

The application validates execution privileges, triggers the process, and blocks until completion. When the command completes, the server replies with a standard JSON or Protobuf payload containing the LogEntry. This object includes the full stdout and stderr arrays, revealing any configuration strings, active credentials, or filesystem pathways printed by the scripts.

The security impact is classified as an authorization bypass leading to information disclosure. The vulnerability does not allow unauthorized remote code execution because the attacker must already possess execution rights for the triggered action. It does, however, compromise the principle of least privilege.

The severity of the leak depends on the scripts managed by OliveTin. If actions involve sensitive operations like database backups, environment setups, or cloud provisioning, the execution logs likely output database connection strings, credentials, structural directories, or API keys. Exposure of these details provides lateral movement vectors to deeper parts of the infrastructure.

The CVSS v3.1 base score is 4.3 (Medium), reflecting network exploitability with low privileges required, zero user interaction, and a low confidentiality impact. There are no known public exploits or evidence of active exploitation in the wild.

The primary resolution is updating OliveTin to version 3000.17.0 or later. This version contains the complete access control validations for all synchronous action routes. Administrators should plan updates immediately to eliminate the authorization bypass vectors.

If patching cannot be executed immediately, administrators should audit all defined actions in the configuration files. Modifying scripts to ensure they suppress output or avoid printing secrets to stdout provides a secondary layer of defense. Additionally, logs from proxy servers or OliveTin's logging endpoints should be audited for frequent hits to /apiv1.OliveTinService/StartActionAndWait from low-privileged accounts.