OliveTin gives safe and simple access to predefined shell commands from a web interface. Prior to 3000.17.0, the service/internal/api/api.go StartActionAndWait and StartActionByGetAndWait endpoints return full LogEntry output after execution without enforcing the logs permission, allowing a user with exec permission but logs:false to read action output. This issue is fixed in version 3000.17.0.

OliveTin gives access to predefined shell commands from a web interface. From 3000.0.0 until 3000.17.0, the service/internal/auth/otoauth2/restapi_auth_oauth2.go OAuth2 login handler stores per-login state in the registeredStates map on every /oauth/login request without expiring, deleting, or bounding entries, allowing an unauthenticated attacker to exhaust memory and cause a denial of service. This issue is fixed in version 3000.17.0.

OliveTin gives access to predefined shell commands from a web interface. From 3000.2.0 until 3000.17.0, the service/internal/executor/arguments.go checkShellArgumentSafety function does not treat regex: custom argument types as unsafe for Shell mode actions, allowing values that pass typeSafetyCheckRegex to be interpolated by wrapCommandInShell into an sh -c command string and enabling OS command injection. This issue is fixed in version 3000.17.0.

OliveTin gives access to predefined shell commands from a web interface. In versions 3000.0.0 and prior, The ValidateArgumentType RPC endpoint in service/internal/api/api.go does not perform any authentication or authorization checks. Unlike all other data-returning API endpoints, it does not call auth.UserFromApiCall or checkDashboardAccess. When AuthRequireGuestsToLogin is enabled (the security-conscious configuration), this endpoint remains accessible to unauthenticated users and can be used as an oracle to enumerate valid action binding IDs and their argument configurations. This issue has been fixed in version 3000.13.0.

OliveTin gives access to predefined shell commands from a web interface. In versions 3000.0.0 and prior, the template engine uses a single shared text/template.Template instance (tpl package-level variable in service/internal/tpl/templates.go) across all goroutines. Every action execution calls tpl.Parse(source) followed by t.Execute() on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case — each ExecRequest spawns a goroutine), a race condition occurs: one goroutine's Parse overwrites the template tree while another goroutine is calling Execute, causing cross-user command contamination, Go runtime panic, and incorrect command execution. This issue has been resolved in version 3000.13.0.