CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
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.
7204 vulnerabilities reference this CWE, most recent first.
GHSA-JJ5X-7M66-MCCH
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-06 21:31Incorrect authorization in Bluetooth in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-106314"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T19:17:59Z",
"severity": "HIGH"
},
"details": "Incorrect authorization in Bluetooth in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-jj5x-7m66-mcch",
"modified": "2026-10-06T21:31:46Z",
"published": "2026-10-06T21:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106314"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/501533684"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JJ68-CP4V-98QF
Vulnerability from github – Published: 2024-07-02 21:20 – Updated: 2024-07-05 21:27aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn't allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "aimeos/ai-admin-graphql"
},
"ranges": [
{
"events": [
{
"introduced": "2022.04.1"
},
{
"fixed": "2022.10.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "aimeos/ai-admin-graphql"
},
"ranges": [
{
"events": [
{
"introduced": "2023.04.1"
},
{
"fixed": "2023.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "aimeos/ai-admin-graphql"
},
"ranges": [
{
"events": [
{
"introduced": "2024.04.1"
},
{
"fixed": "2024.04.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2024.04.1"
]
}
],
"aliases": [
"CVE-2024-39324"
],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-02T21:20:55Z",
"nvd_published_at": "2024-07-02T21:15:11Z",
"severity": "LOW"
},
"details": "aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn\u0027t allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.\n",
"id": "GHSA-jj68-cp4v-98qf",
"modified": "2024-07-05T21:27:07Z",
"published": "2024-07-02T21:20:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aimeos/ai-admin-graphql/security/advisories/GHSA-jj68-cp4v-98qf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39324"
},
{
"type": "WEB",
"url": "https://github.com/aimeos/ai-admin-graphql/commit/4eabc2b973509ffa5924e7f88c8f87ee96e93b38"
},
{
"type": "WEB",
"url": "https://github.com/aimeos/ai-admin-graphql/commit/687059d7eb2e1d55a09ed72dad3814f35edad038"
},
{
"type": "WEB",
"url": "https://github.com/aimeos/ai-admin-graphql/commit/a839a5adf16fee4221d444b7d2f5140d8cabf0ac"
},
{
"type": "WEB",
"url": "https://github.com/aimeos/ai-admin-graphql/commit/acbb044620f4ff8e8d78a775cd205ec47cf119b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/aimeos/ai-admin-graphql"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services"
}
GHSA-JJ82-76V6-933R
Vulnerability from github – Published: 2026-03-03 23:13 – Updated: 2026-03-20 21:35Summary
system.run exec allowlist analysis treated wrapper binaries as the effective executable and did not fully unwrap env/shell-dispatch wrappers.
This allowed wrapper-smuggled payloads (for example env bash -lc ...) to satisfy an allowlist entry for the wrapper while executing non-allowlisted commands.
Impact
On affected versions, an actor who can trigger system.run requests under an allowlist policy could bypass intended allowlist restrictions by routing execution through wrapper binaries.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected:
<= 2026.2.21-2 - Patched in next release:
2026.2.22(pre-set below so publish can happen immediately after npm release)
Fix Commit(s)
2b63592be57782c8946e521bc81286933f0f99c7
Release Process Note
patched_versions is pre-set to the planned next release (>= 2026.2.22).
After npm 2026.2.22 is published, this advisory can be published directly without further metadata edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27566"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T23:13:51Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`system.run` exec allowlist analysis treated wrapper binaries as the effective executable and did not fully unwrap `env`/shell-dispatch wrappers.\n\nThis allowed wrapper-smuggled payloads (for example `env bash -lc ...`) to satisfy an allowlist entry for the wrapper while executing non-allowlisted commands.\n\n### Impact\nOn affected versions, an actor who can trigger `system.run` requests under an allowlist policy could bypass intended allowlist restrictions by routing execution through wrapper binaries.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.21-2`\n- Patched in next release: `2026.2.22` (pre-set below so publish can happen immediately after npm release)\n\n### Fix Commit(s)\n- `2b63592be57782c8946e521bc81286933f0f99c7`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`\u003e= 2026.2.22`).\n\nAfter npm `2026.2.22` is published, this advisory can be published directly without further metadata edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-jj82-76v6-933r",
"modified": "2026-03-20T21:35:56Z",
"published": "2026-03-03T23:13:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jj82-76v6-933r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27566"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/2b63592be57782c8946e521bc81286933f0f99c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-wrapper-binary-unwrapping-in-system-run"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw\u0027s exec allowlist wrapper analysis did not unwrap env/shell dispatch chains"
}
GHSA-JJ9H-M6R9-G37H
Vulnerability from github – Published: 2026-10-10 21:31 – Updated: 2026-10-10 21:31Tabularis through 0.27.0 contains an incorrect authorization vulnerability in the MCP run_query safety gate that allows prompt-injected agents or untrusted MCP clients to bypass read-only mode by submitting side-effecting SELECT statements. Attackers can run statements like SELECT setval, nextval, or PostgreSQL query_to_xml with embedded DELETE to modify data without approval prompts.
{
"affected": [],
"aliases": [
"CVE-2026-108604"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T20:16:32Z",
"severity": "MODERATE"
},
"details": "Tabularis through 0.27.0 contains an incorrect authorization vulnerability in the MCP run_query safety gate that allows prompt-injected agents or untrusted MCP clients to bypass read-only mode by submitting side-effecting SELECT statements. Attackers can run statements like SELECT setval, nextval, or PostgreSQL query_to_xml with embedded DELETE to modify data without approval prompts.",
"id": "GHSA-jj9h-m6r9-g37h",
"modified": "2026-10-10T21:31:16Z",
"published": "2026-10-10T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108604"
},
{
"type": "WEB",
"url": "https://github.com/TabularisDB/tabularis"
},
{
"type": "WEB",
"url": "https://github.com/TabularisDB/tabularis/blob/804c4c3bb6fd8eaa2e36cbe49f6c0d58f373b5e9/src-tauri/src/ai_activity.rs#L357-L416"
},
{
"type": "WEB",
"url": "https://github.com/TabularisDB/tabularis/blob/804c4c3bb6fd8eaa2e36cbe49f6c0d58f373b5e9/src-tauri/src/mcp/mod.rs#L1136-L1171"
},
{
"type": "WEB",
"url": "https://hackmd.io/@haind/S1BofaIsMx"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/tabularis-through-0.27.0-read-only-bypass-via-mcp-run-query-select-classification"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-JJJJ-JWHF-8RGR
Vulnerability from github – Published: 2025-10-16 21:36 – Updated: 2025-10-24 19:28Summary
A privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user.
Details
The vulnerability exists in the IAM policy validation logic in cmd/iam.go. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the DenyOnly argument.
The DenyOnly flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually allowed by the session policy, not just that it isn't denied.
Attack Scenario
- An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)
- The restricted account attempts to create a new service account for itself without specifying any policy restrictions
- Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy
- The attacker now has escalated privileges beyond the intended restrictions
Impact
Attack Complexity: LOW - Exploitation requires only valid credentials for a restricted service/STS account
Confidentiality: HIGH - Attackers can access buckets and objects beyond their intended restrictions
Integrity: HIGH - Attackers can modify, delete, or create objects outside their authorized scope
Availability: NONE - Does not directly impact service availability
Patches
Fixed in PR https://github.com/minio/minio/pull/21642 Commit: c1a49490c78e9c3ebcad86ba0662319138ace190
Install the release
go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z
Workarounds
No workarounds available. You can upgrade to the latest version immediately.
Mitigation Steps
- Upgrade MinIO: Update to the latest version containing the fix
- Audit Service Accounts: Review all service accounts created by non-admin accounts
- Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation
- Review Access Logs: Check for unauthorized access to sensitive buckets
Resources
- Fix PR: https://github.com/minio/minio/pull/21642
- Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/minio/minio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20251015170045-c1a49490c78e"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62506"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-16T21:36:06Z",
"nvd_published_at": "2025-10-16T22:15:31Z",
"severity": "HIGH"
},
"details": "### Summary\nA privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing \"own\" account operations, specifically when creating new service accounts for the same user.\n\n### Details\nThe vulnerability exists in the IAM policy validation logic in `cmd/iam.go`. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the `DenyOnly` argument.\n\nThe `DenyOnly` flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually **allowed** by the session policy, not just that it isn\u0027t denied.\n\n### Attack Scenario\n 1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)\n 2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions\n 3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy\n 4. The attacker now has escalated privileges beyond the intended restrictions\n\n### Impact\n\n **Attack Complexity**: LOW - Exploitation requires only valid credentials for a restricted service/STS account\n\n **Confidentiality**: HIGH - Attackers can access buckets and objects beyond their intended restrictions\n\n **Integrity**: HIGH - Attackers can modify, delete, or create objects outside their authorized scope\n\n **Availability**: NONE - Does not directly impact service availability\n\n### Patches\nFixed in PR https://github.com/minio/minio/pull/21642\nCommit: c1a49490c78e9c3ebcad86ba0662319138ace190\n\nInstall the release\n```\ngo install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z\n```\n\n### Workarounds\nNo workarounds available. You can upgrade to the latest version immediately.\n\n### Mitigation Steps\n\n1. **Upgrade MinIO**: Update to the latest version containing the fix\n2. **Audit Service Accounts**: Review all service accounts created by non-admin accounts\n3. **Revoke Suspicious Accounts**: Delete any service accounts that may have been created through exploitation\n4. **Review Access Logs**: Check for unauthorized access to sensitive buckets\n\n### Resources\n\n- Fix PR: https://github.com/minio/minio/pull/21642\n- Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)",
"id": "GHSA-jjjj-jwhf-8rgr",
"modified": "2025-10-24T19:28:23Z",
"published": "2025-10-16T21:36:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/minio/minio/security/advisories/GHSA-jjjj-jwhf-8rgr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62506"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/issues/21647"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/pull/21642"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/commit/c1a49490c78e9c3ebcad86ba0662319138ace190"
},
{
"type": "PACKAGE",
"url": "https://github.com/minio/minio"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/discussions/21655"
},
{
"type": "WEB",
"url": "https://news.ycombinator.com/item?id=45684035"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "MinIO is Vulnerable to Privilege Escalation via Session Policy Bypass in Service Accounts and STS"
}
GHSA-JJVQ-RHWJ-P63J
Vulnerability from github – Published: 2026-10-01 06:31 – Updated: 2026-10-01 06:31Hitachi Coding Software Suite contains an Incorrect Authorization vulnerability that allows an unprivileged user to perform administrator-level operations.
This issue affects Hitachi Coding Software Suite: through 3.3.0.
{
"affected": [],
"aliases": [
"CVE-2026-82828"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-01T05:17:10Z",
"severity": "HIGH"
},
"details": "Hitachi Coding Software Suite contains an Incorrect Authorization vulnerability that allows an unprivileged user to perform administrator-level operations.\n\n\nThis issue affects Hitachi Coding Software Suite: through 3.3.0.",
"id": "GHSA-jjvq-rhwj-p63j",
"modified": "2026-10-01T06:31:25Z",
"published": "2026-10-01T06:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82828"
},
{
"type": "WEB",
"url": "https://www.hitachi-ies.com/common/documents/vulnerability/hcss/Hitachi_Coding_Software_Suite_Public_statement_20260925_EN.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-JM28-2WCR-QF3H
Vulnerability from github – Published: 2026-07-30 14:25 – Updated: 2026-07-30 14:25Summary
The synchronous execution RPCs StartActionAndWait and StartActionByGetAndWait return the full LogEntry for the just-executed action without checking whether the caller is allowed to read that action's logs.
OliveTin's ACL model separates exec from logs. A deployment can intentionally allow a user to run an action while denying access to its historical or live output. That separation is enforced in GetLogs, GetActionLogs, ExecutionStatus, and EventStream, but it is not enforced in the synchronous ...AndWait endpoints.
As a result, any user who can execute an action through these endpoints can read the action output immediately even when the action's ACL explicitly sets logs:false.
Details
OliveTin defines separate per-action permissions:
// service/internal/config/config.go
type PermissionsList struct {
View bool `koanf:"view"`
Exec bool `koanf:"exec"`
Logs bool `koanf:"logs"`
Kill bool `koanf:"kill"`
}
The normal log and streaming paths correctly enforce logs permission:
// service/internal/api/api.go
func (api *oliveTinAPI) isLogEntryAllowed(e *executor.InternalLogEntry, user *authpublic.AuthenticatedUser) bool {
if user == nil || !isValidLogEntry(e) {
return false
}
return acl.IsAllowedLogs(api.cfg, user, e.Binding.Action)
}
That check is used by:
GetLogsGetActionLogsExecutionStatusEventStream
However, the synchronous execution endpoints directly return the created LogEntry without any logs ACL check:
// service/internal/api/api.go
func (api *oliveTinAPI) StartActionAndWait(ctx ctx.Context, req *connect.Request[apiv1.StartActionAndWaitRequest]) (*connect.Response[apiv1.StartActionAndWaitResponse], error) {
...
internalLogEntry, ok := api.startActionAndWaitRun(binding, args, user)
if !ok {
return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("execution not found"))
}
return connect.NewResponse(&apiv1.StartActionAndWaitResponse{
LogEntry: api.internalLogEntryToPb(internalLogEntry, user),
}), nil
}
func (api *oliveTinAPI) StartActionByGetAndWait(ctx ctx.Context, req *connect.Request[apiv1.StartActionByGetAndWaitRequest]) (*connect.Response[apiv1.StartActionByGetAndWaitResponse], error) {
...
internalLogEntry, ok := api.executor.GetLog(execReq.TrackingID)
if ok {
return connect.NewResponse(&apiv1.StartActionByGetAndWaitResponse{
LogEntry: api.internalLogEntryToPb(internalLogEntry, user),
}), nil
}
return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("execution not found"))
}
And internalLogEntryToPb() includes the full output:
// service/internal/api/api.go
func (api *oliveTinAPI) internalLogEntryToPb(logEntry *executor.InternalLogEntry, authenticatedUser *authpublic.AuthenticatedUser) *apiv1.LogEntry {
pble := &apiv1.LogEntry{
ActionTitle: logEntry.ActionTitle,
Output: logEntry.Output,
ExitCode: logEntry.ExitCode,
ExecutionTrackingId: logEntry.ExecutionTrackingID,
...
}
...
return pble
}
The executor separately enforces exec permission, but there is no subsequent check that the response should omit or deny Output when logs:false.
Local Reproduction
I verified this locally with a one-off test against the real StartActionAndWait handler.
Configuration used:
- action
secret_actionwith shellecho SECRET_FROM_ACTION - user
lowmatched by ACL: exec: truelogs: falseview: falsekill: false
Then I invoked StartActionAndWait as low through the real handler path using header-based auth.
Observed output from the test run:
=== RUN TestTempStartActionAndWaitLeaksOutputWithoutLogsPermission
time="2026-03-12T23:36:33+01:00" level=info msg="Action requested" actionTitle=secret-action tags="[]"
time="2026-03-12T23:36:33+01:00" level=info msg="Action parse args - Before" actionTitle=secret-action cmd="echo SECRET_FROM_ACTION"
time="2026-03-12T23:36:33+01:00" level=info msg="Action parse args - After" actionTitle=secret-action cmd="echo SECRET_FROM_ACTION"
time="2026-03-12T23:36:33+01:00" level=info msg="Action started" actionTitle=secret-action timeout=5
time="2026-03-12T23:36:33+01:00" level=info msg="Action finished" actionTitle=secret-action exit=0 outputLength=40 timedOut=false
temp_acl_bypass_test.go:56: output="S\x00E\x00C\x00R\x00E\x00T\x00_\x00F\x00R\x00O\x00M\x00_\x00A\x00C\x00T\x00I\x00O\x00N\x00\r\x00\n\x00" blocked=false action="secret-action"
--- PASS: TestTempStartActionAndWaitLeaksOutputWithoutLogsPermission (0.03s)
The UTF-16LE formatting is from Windows echo, but the key result is that the response returned the real command output even though the caller's ACL explicitly denied log access.
Impact
- Bypass of log confidentiality controls: Operators may configure actions to be executable but not log-readable. The
...AndWaitendpoints break that separation. - Disclosure of secrets printed by actions: Many OliveTin actions wrap administrative scripts and commands whose stdout/stderr may contain credentials, internal paths, hostnames, tokens, or sensitive operational data.
- Adjacent to previous output-leak bugs: OliveTin already had an EventStream output disclosure bug. This is a separate response-path authorization gap on the synchronous execution APIs.
Recommended Fix
Enforce logs permission before returning LogEntry content from synchronous execution endpoints.
Two reasonable fixes:
- Deny the endpoint response when
logs:false
if !acl.IsAllowedLogs(api.cfg, user, binding.Action) {
return nil, connect.NewError(connect.CodePermissionDenied, fmt.Errorf("permission denied to view action output"))
}
- Or redact log-bearing fields when
logs:false
pb := api.internalLogEntryToPb(internalLogEntry, user)
if !acl.IsAllowedLogs(api.cfg, user, binding.Action) {
pb.Output = ""
pb.ExitCode = 0
}
return connect.NewResponse(&apiv1.StartActionAndWaitResponse{LogEntry: pb}), nil
The same fix should be applied to both:
StartActionAndWaitStartActionByGetAndWait
References
service/internal/api/api.goservice/internal/config/config.goservice/internal/acl/acl.go
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260708085316-e421780c9885"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67439"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T14:25:20Z",
"nvd_published_at": "2026-07-29T21:17:48Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe synchronous execution RPCs `StartActionAndWait` and `StartActionByGetAndWait` return the full `LogEntry` for the just-executed action without checking whether the caller is allowed to read that action\u0027s logs.\n\nOliveTin\u0027s ACL model separates `exec` from `logs`. A deployment can intentionally allow a user to run an action while denying access to its historical or live output. That separation is enforced in `GetLogs`, `GetActionLogs`, `ExecutionStatus`, and `EventStream`, but it is not enforced in the synchronous `...AndWait` endpoints.\n\nAs a result, any user who can execute an action through these endpoints can read the action output immediately even when the action\u0027s ACL explicitly sets `logs:false`.\n\n## Details\n\nOliveTin defines separate per-action permissions:\n\n```go\n// service/internal/config/config.go\ntype PermissionsList struct {\n View bool `koanf:\"view\"`\n Exec bool `koanf:\"exec\"`\n Logs bool `koanf:\"logs\"`\n Kill bool `koanf:\"kill\"`\n}\n```\n\nThe normal log and streaming paths correctly enforce `logs` permission:\n\n```go\n// service/internal/api/api.go\nfunc (api *oliveTinAPI) isLogEntryAllowed(e *executor.InternalLogEntry, user *authpublic.AuthenticatedUser) bool {\n if user == nil || !isValidLogEntry(e) {\n return false\n }\n return acl.IsAllowedLogs(api.cfg, user, e.Binding.Action)\n}\n```\n\nThat check is used by:\n\n- `GetLogs`\n- `GetActionLogs`\n- `ExecutionStatus`\n- `EventStream`\n\nHowever, the synchronous execution endpoints directly return the created `LogEntry` without any `logs` ACL check:\n\n```go\n// service/internal/api/api.go\nfunc (api *oliveTinAPI) StartActionAndWait(ctx ctx.Context, req *connect.Request[apiv1.StartActionAndWaitRequest]) (*connect.Response[apiv1.StartActionAndWaitResponse], error) {\n ...\n internalLogEntry, ok := api.startActionAndWaitRun(binding, args, user)\n if !ok {\n return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf(\"execution not found\"))\n }\n return connect.NewResponse(\u0026apiv1.StartActionAndWaitResponse{\n LogEntry: api.internalLogEntryToPb(internalLogEntry, user),\n }), nil\n}\n\nfunc (api *oliveTinAPI) StartActionByGetAndWait(ctx ctx.Context, req *connect.Request[apiv1.StartActionByGetAndWaitRequest]) (*connect.Response[apiv1.StartActionByGetAndWaitResponse], error) {\n ...\n internalLogEntry, ok := api.executor.GetLog(execReq.TrackingID)\n if ok {\n return connect.NewResponse(\u0026apiv1.StartActionByGetAndWaitResponse{\n LogEntry: api.internalLogEntryToPb(internalLogEntry, user),\n }), nil\n }\n return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf(\"execution not found\"))\n}\n```\n\nAnd `internalLogEntryToPb()` includes the full output:\n\n```go\n// service/internal/api/api.go\nfunc (api *oliveTinAPI) internalLogEntryToPb(logEntry *executor.InternalLogEntry, authenticatedUser *authpublic.AuthenticatedUser) *apiv1.LogEntry {\n pble := \u0026apiv1.LogEntry{\n ActionTitle: logEntry.ActionTitle,\n Output: logEntry.Output,\n ExitCode: logEntry.ExitCode,\n ExecutionTrackingId: logEntry.ExecutionTrackingID,\n ...\n }\n ...\n return pble\n}\n```\n\nThe executor separately enforces `exec` permission, but there is no subsequent check that the response should omit or deny `Output` when `logs:false`.\n\n## Local Reproduction\n\nI verified this locally with a one-off test against the real `StartActionAndWait` handler.\n\nConfiguration used:\n\n- action `secret_action` with shell `echo SECRET_FROM_ACTION`\n- user `low` matched by ACL:\n - `exec: true`\n - `logs: false`\n - `view: false`\n - `kill: false`\n\nThen I invoked `StartActionAndWait` as `low` through the real handler path using header-based auth.\n\nObserved output from the test run:\n\n```text\n=== RUN TestTempStartActionAndWaitLeaksOutputWithoutLogsPermission\ntime=\"2026-03-12T23:36:33+01:00\" level=info msg=\"Action requested\" actionTitle=secret-action tags=\"[]\"\ntime=\"2026-03-12T23:36:33+01:00\" level=info msg=\"Action parse args - Before\" actionTitle=secret-action cmd=\"echo SECRET_FROM_ACTION\"\ntime=\"2026-03-12T23:36:33+01:00\" level=info msg=\"Action parse args - After\" actionTitle=secret-action cmd=\"echo SECRET_FROM_ACTION\"\ntime=\"2026-03-12T23:36:33+01:00\" level=info msg=\"Action started\" actionTitle=secret-action timeout=5\ntime=\"2026-03-12T23:36:33+01:00\" level=info msg=\"Action finished\" actionTitle=secret-action exit=0 outputLength=40 timedOut=false\n temp_acl_bypass_test.go:56: output=\"S\\x00E\\x00C\\x00R\\x00E\\x00T\\x00_\\x00F\\x00R\\x00O\\x00M\\x00_\\x00A\\x00C\\x00T\\x00I\\x00O\\x00N\\x00\\r\\x00\\n\\x00\" blocked=false action=\"secret-action\"\n--- PASS: TestTempStartActionAndWaitLeaksOutputWithoutLogsPermission (0.03s)\n```\n\nThe UTF-16LE formatting is from Windows `echo`, but the key result is that the response returned the real command output even though the caller\u0027s ACL explicitly denied log access.\n\n## Impact\n\n- **Bypass of log confidentiality controls:** Operators may configure actions to be executable but not log-readable. The `...AndWait` endpoints break that separation.\n- **Disclosure of secrets printed by actions:** Many OliveTin actions wrap administrative scripts and commands whose stdout/stderr may contain credentials, internal paths, hostnames, tokens, or sensitive operational data.\n- **Adjacent to previous output-leak bugs:** OliveTin already had an EventStream output disclosure bug. This is a separate response-path authorization gap on the synchronous execution APIs.\n\n## Recommended Fix\n\nEnforce `logs` permission before returning `LogEntry` content from synchronous execution endpoints.\n\nTwo reasonable fixes:\n\n1. Deny the endpoint response when `logs:false`\n\n```go\nif !acl.IsAllowedLogs(api.cfg, user, binding.Action) {\n return nil, connect.NewError(connect.CodePermissionDenied, fmt.Errorf(\"permission denied to view action output\"))\n}\n```\n\n2. Or redact log-bearing fields when `logs:false`\n\n```go\npb := api.internalLogEntryToPb(internalLogEntry, user)\nif !acl.IsAllowedLogs(api.cfg, user, binding.Action) {\n pb.Output = \"\"\n pb.ExitCode = 0\n}\nreturn connect.NewResponse(\u0026apiv1.StartActionAndWaitResponse{LogEntry: pb}), nil\n```\n\nThe same fix should be applied to both:\n\n- `StartActionAndWait`\n- `StartActionByGetAndWait`\n\n## References\n\n- `service/internal/api/api.go`\n- `service/internal/config/config.go`\n- `service/internal/acl/acl.go`",
"id": "GHSA-jm28-2wcr-qf3h",
"modified": "2026-07-30T14:25:20Z",
"published": "2026-07-30T14:25:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-jm28-2wcr-qf3h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67439"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/e421780c9885aa5024d2f47b4ed4898f2f18eb90"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.17.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OliveTin: StartActionAndWait Endpoints Bypass `logs` Permission and Return Action Output"
}
GHSA-JM2G-3F56-RVVH
Vulnerability from github – Published: 2025-04-23 12:31 – Updated: 2026-10-06 18:31A vulnerability was found in mod_proxy_cluster. The issue is that the directive should be replaced by the directive as the former does not restrict IP/host access as Require ip IP_ADDRESS would suggest. This means that anyone with access to the host might send MCMP requests that may result in adding/removing/updating nodes for the balancing. However, this host should not be accessible to the public network as it does not serve the general traffic.
{
"affected": [],
"aliases": [
"CVE-2024-10306"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-23T10:15:14Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in mod_proxy_cluster. The issue is that the \u003cDirectory\u003e directive should be replaced by the \u003cLocation\u003e directive as the former does not restrict IP/host access as `Require ip IP_ADDRESS` would suggest. This means that anyone with access to the host might send MCMP requests that may result in adding/removing/updating nodes for the balancing. However, this host should not be accessible to the public network as it does not serve the general traffic.",
"id": "GHSA-jm2g-3f56-rvvh",
"modified": "2026-10-06T18:31:14Z",
"published": "2025-04-23T12:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10306"
},
{
"type": "WEB",
"url": "https://github.com/modcluster/mod_proxy_cluster/pull/309"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2025:2973"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2025:5309"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:3453"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9434"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9466"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:9997"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-10306"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2321302"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JM36-4MV9-X2PW
Vulnerability from github – Published: 2022-01-19 00:00 – Updated: 2023-08-08 15:31An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.3. Under certain conditions it was possible to bypass the IP restriction for public projects through GraphQL allowing unauthorised users to read titles of issues, merge requests and milestones.
{
"affected": [],
"aliases": [
"CVE-2022-0172"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-18T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.3. Under certain conditions it was possible to bypass the IP restriction for public projects through GraphQL allowing unauthorised users to read titles of issues, merge requests and milestones.",
"id": "GHSA-jm36-4mv9-x2pw",
"modified": "2023-08-08T15:31:37Z",
"published": "2022-01-19T00:00:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0172"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-0172.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/348411"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JM4G-8RVQ-V87J
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2023-12-21 13:49An incorrect permission check in Jenkins XebiaLabs XL Deploy Plugin 10.0.1 and earlier allows attackers with Generic Create permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing Username/password credentials stored in Jenkins.
The permission check was partially fixed in XebiaLabs XL Deploy Plugin 7.5.9: A permission check was added, but for the wrong permission, still allowing some non-admin users to access the form validation method.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.1"
},
"package": {
"ecosystem": "Maven",
"name": "com.xebialabs.deployit.ci:deployit-plugin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21664"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-14T16:18:06Z",
"nvd_published_at": "2021-06-10T15:15:00Z",
"severity": "MODERATE"
},
"details": "An incorrect permission check in Jenkins XebiaLabs XL Deploy Plugin 10.0.1 and earlier allows attackers with Generic Create permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing Username/password credentials stored in Jenkins.\n\nThe permission check was partially fixed in XebiaLabs XL Deploy Plugin 7.5.9: A permission check was added, but for the wrong permission, still allowing some non-admin users to access the form validation method.\n",
"id": "GHSA-jm4g-8rvq-v87j",
"modified": "2023-12-21T13:49:53Z",
"published": "2022-05-24T19:04:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21664"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/xldeploy-plugin/commit/79ae204d2ee6cd94badf4c24a150cee13a3bde44"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/xldeploy-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2021-06-10/#SECURITY-1982"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/06/10/14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incorrect permission check in XebiaLabs XL Deploy Plugin allows capturing credentials"
}
Mitigation
- 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.
Mitigation
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].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- 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].
Mitigation
- 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.
Mitigation
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.
No CAPEC attack patterns related to this CWE.