Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

7196 vulnerabilities reference this CWE, most recent first.

GHSA-JHPV-5J76-M56H

Vulnerability from github – Published: 2026-04-17 22:17 – Updated: 2026-05-05 11:49
VLAI
Summary
OpenClaw: Sender policy bypass in host media attachment reads allows unauthorized local file disclosure
Details

Summary

OpenClaw's outbound host-media attachment read helper could enable host-local file reads based on global or agent-level read access without also honoring sender and group-scoped tool policy. In channel deployments that used toolsBySender or group policy to deny read for less-trusted senders, a denied sender could still trigger host-media attachment loading and cause readable local files to be returned through the outbound media path.

Affected Versions

This issue is known to affect OpenClaw 2026.4.9. Earlier versions were not confirmed during triage, so the advisory range is intentionally scoped to >= 2026.4.9 < 2026.4.10.

Impact

Affected deployments are those that both allow host read or filesystem root expansion at the global/agent level and rely on sender or group-scoped policy to deny read for some channel participants. In that configuration, the intended sender/group authorization boundary could be bypassed for outbound media reads, potentially disclosing host-local files readable by the OpenClaw process.

The issue does not require treating the model prompt as the security boundary. The vulnerable behavior was a concrete policy enforcement mismatch: sender/group policy denied read, while the host-media read helper could still be installed without that sender context.

Resolution

Fixed in OpenClaw 2026.4.10 by PR #64459, commit c949af9fabf3873b5b7c484090cb5f5ab6049a98. The fix threads sender, session, channel, and account context into outbound media access resolution and intersects host-media read capability creation with the existing group tool policy for read. When a concrete sender/group override denies read, OpenClaw no longer creates the host readFile media capability.

Additional attachment canonicalization hardening shipped in 2026.4.14, but the authorization bypass described here was fixed in 2026.4.10.

Credit

Thanks to @Telecaster2147 for reporting this issue.

Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.4.9"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:17:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nOpenClaw\u0027s outbound host-media attachment read helper could enable host-local file reads based on global or agent-level read access without also honoring sender and group-scoped tool policy. In channel deployments that used `toolsBySender` or group policy to deny `read` for less-trusted senders, a denied sender could still trigger host-media attachment loading and cause readable local files to be returned through the outbound media path.\n\n## Affected Versions\n\nThis issue is known to affect OpenClaw 2026.4.9. Earlier versions were not confirmed during triage, so the advisory range is intentionally scoped to `\u003e= 2026.4.9 \u003c 2026.4.10`.\n\n## Impact\n\nAffected deployments are those that both allow host read or filesystem root expansion at the global/agent level and rely on sender or group-scoped policy to deny `read` for some channel participants. In that configuration, the intended sender/group authorization boundary could be bypassed for outbound media reads, potentially disclosing host-local files readable by the OpenClaw process.\n\nThe issue does not require treating the model prompt as the security boundary. The vulnerable behavior was a concrete policy enforcement mismatch: sender/group policy denied `read`, while the host-media read helper could still be installed without that sender context.\n\n## Resolution\n\nFixed in OpenClaw 2026.4.10 by PR #64459, commit `c949af9fabf3873b5b7c484090cb5f5ab6049a98`. The fix threads sender, session, channel, and account context into outbound media access resolution and intersects host-media read capability creation with the existing group tool policy for `read`. When a concrete sender/group override denies `read`, OpenClaw no longer creates the host `readFile` media capability.\n\nAdditional attachment canonicalization hardening shipped in 2026.4.14, but the authorization bypass described here was fixed in 2026.4.10.\n\n## Credit\n\nThanks to @Telecaster2147 for reporting this issue.",
  "id": "GHSA-jhpv-5j76-m56h",
  "modified": "2026-05-05T11:49:51Z",
  "published": "2026-04-17T22:17:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jhpv-5j76-m56h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/64459"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c949af9fabf3873b5b7c484090cb5f5ab6049a98"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Sender policy bypass in host media attachment reads allows unauthorized local file disclosure"
}

GHSA-JJ2H-HCRF-9GFX

Vulnerability from github – Published: 2026-09-23 15:30 – Updated: 2026-10-05 12:31
VLAI
Details

A flaw was found in sudo. When sudoers rules use NOTBEFORE or NOTAFTER time-based access restrictions with timestamps that omit the trailing 'Z' timezone indicator, the time evaluation relies on the TZ environment variable inherited from the calling user. Because sudo is a setuid-root program, an unprivileged local user can set TZ to an extreme timezone offset to shift the authorization window by up to approximately 25 hours, causing expired rules to be treated as valid. This allows the user to execute commands outside the intended time window. Authentication is not bypassed; only the time-based authorization check is affected.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-96512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-23T14:17:10Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in sudo. When sudoers rules use NOTBEFORE or NOTAFTER time-based access restrictions with timestamps that omit the trailing \u0027Z\u0027 timezone indicator, the time evaluation relies on the TZ environment variable inherited from the calling user. Because sudo is a setuid-root program, an unprivileged local user can set TZ to an extreme timezone offset to shift the authorization window by up to approximately 25 hours, causing expired rules to be treated as valid. This allows the user to execute commands outside the intended time window. Authentication is not bypassed; only the time-based authorization check is affected.",
  "id": "GHSA-jj2h-hcrf-9gfx",
  "modified": "2026-10-05T12:31:21Z",
  "published": "2026-09-23T15:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96512"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sudo-project/sudo/commit/1820a349687522f51023d1ae5925125f59679a8c"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71609"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:75571"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:75579"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:75580"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-96512"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2539327"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/24/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JJ4J-X5WW-CWH9

Vulnerability from github – Published: 2025-09-15 16:28 – Updated: 2026-04-06 23:15
VLAI
Summary
Before action, Ash's hooks may execute in certain scenarios despite a request being forbidden
Details

Summary

Certain bulk action calls with a before_transaction hook and no after_transaction hook, will call the before_transaction hook before authorization is checked and a Forbidden error is returned, when called as a bulk action.

The impact is that a malicious user could cause a before_transaction to run even though they are not authorized to perform the whole action. The before_action could run a sensitive/expensive operation.

Impact

A malicious user could cause a before_action to run even though they are not authorized to perform the whole action.

You are affected if you have an create, update or destroy action that:

  • has a before_transaction hook on it, and no after_transaction hook on it.
  • is being used via an Ash.bulk_* callback (which AshJsonApi and AshGraphql do for update/destroy actions)

Whether or not or how much it matters depends on the nature of those before_transaction callbacks. If those before_transaction callbacks are side-effectful, or just doing something like looking up some external data. If your API endpoints are behind authentication and what kind.

Severity

The severity for this was hard to gauge. before_transaction hooks are not that commonly used. Additionally, any attacker must know which of these things are available to them, be authenticated to make such a request (i.e you very rarely have policies preventing the running of anonymous queries), so privileges and inside knowledge are required. Additionally, the action will always return a forbidden error, so no information is revealed. We will evaluate and adjust the severity in the next few days as needed.

It is currently marked as High, given that we really don't know what logic folks are putting in their before_transaction hooks and it could theoretically be very bad.

Workarounds

You should update ASAP, but if for whatever reason you cannot update, you can add logic to those before_transaction hooks to prevent them from doing their logic before they should.

Severity
5.6 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.38"
      },
      "package": {
        "ecosystem": "Hex",
        "name": "ash"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.5.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-15T16:28:24Z",
    "nvd_published_at": "2025-09-07T16:15:51Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nCertain bulk action calls with a `before_transaction` hook and no `after_transaction` hook, will call the `before_transaction` hook before authorization is checked and a Forbidden error is returned, when called as a bulk action.\n\nThe impact is that a malicious user could cause a `before_transaction` to run even though they are not authorized to perform the whole action. The `before_action` could run a sensitive/expensive operation.\n\n### Impact\nA malicious user could cause a `before_action` to run even though they are not authorized to perform the whole action.\n\nYou are affected if you have an create, update or destroy action that:\n\n- has a before_transaction hook on it, and no after_transaction hook on it.\n- is being used via an `Ash.bulk_*` callback (which AshJsonApi and AshGraphql do for update/destroy actions)\n\nWhether or not or how much it matters depends on the nature of those before_transaction callbacks. If those before_transaction callbacks are side-effectful, or just doing something like looking up some external data. If your API endpoints are behind authentication and what kind. \n\n### Severity\n\nThe severity for this was hard to gauge. `before_transaction` hooks are not that commonly used. Additionally, any attacker must know which of these things are available to them, be authenticated to make such a request (i.e you very rarely have policies preventing the running of anonymous queries), so privileges and inside knowledge are required. Additionally, the action will always return a `forbidden` error, so no information is revealed. We will evaluate and adjust the severity in the next few days as needed.\n\nIt is currently marked as High, given that we really don\u0027t know what logic folks are putting in their before_transaction hooks and it could theoretically be very bad.\n\n### Workarounds\n\nYou should update ASAP, but if for whatever reason you cannot update, you can add logic to those before_transaction hooks to prevent them from doing their logic before they should.",
  "id": "GHSA-jj4j-x5ww-cwh9",
  "modified": "2026-04-06T23:15:03Z",
  "published": "2025-09-15T16:28:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/security/advisories/GHSA-jj4j-x5ww-cwh9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ash-project/ash/commit/5d1b6a5d00771fd468a509778637527b5218be9a"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2025-48042.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ash-project/ash"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48042"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Before action, Ash\u0027s hooks may execute in certain scenarios despite a request being forbidden"
}

GHSA-JJ5X-7M66-MCCH

Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-06 21:31
VLAI
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)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:27
VLAI
Summary
aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services
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't allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.

Severity
3.8 (Low)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "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:35
VLAI
Summary
OpenClaw's exec allowlist wrapper analysis did not unwrap env/shell dispatch chains
Details

Summary

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.

Severity
7.1 (High)
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
Show details on source website
To clipboard 

{
  "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:31
VLAI
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.

Severity
6.3 (Medium)
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H
5.8 (Medium)
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
Show details on source website
To clipboard 

{
  "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:28
VLAI
Summary
MinIO is Vulnerable to Privilege Escalation via Session Policy Bypass in Service Accounts and STS
Details

Summary

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

  1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)
  2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions
  3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy
  4. 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

  1. Upgrade MinIO: Update to the latest version containing the fix
  2. Audit Service Accounts: Review all service accounts created by non-admin accounts
  3. Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation
  4. 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)
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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:31
VLAI
Details

Hitachi 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.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "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:25
VLAI
Summary
OliveTin: StartActionAndWait Endpoints Bypass `logs` Permission and Return Action Output
Details

Summary

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:

  • GetLogs
  • GetActionLogs
  • ExecutionStatus
  • EventStream

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_action with shell echo SECRET_FROM_ACTION
  • user low matched by ACL:
  • exec: true
  • logs: false
  • view: false
  • kill: 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 ...AndWait endpoints 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:

  1. 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"))
}
  1. 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:

  • StartActionAndWait
  • StartActionByGetAndWait

References

  • service/internal/api/api.go
  • service/internal/config/config.go
  • service/internal/acl/acl.go
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
}
Mitigation
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.
Mitigation
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].

Mitigation MIT-4.4
Architecture and Design

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
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.
Mitigation
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.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list