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.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-3GH3-7V6R-4Q8W

Vulnerability from github – Published: 2026-02-05 21:32 – Updated: 2026-02-05 21:32
VLAI
Details

Tanium addressed an improper access controls vulnerability in Reputation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-15342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-05T19:15:55Z",
    "severity": "MODERATE"
  },
  "details": "Tanium addressed an improper access controls vulnerability in Reputation.",
  "id": "GHSA-3gh3-7v6r-4q8w",
  "modified": "2026-02-05T21:32:42Z",
  "published": "2026-02-05T21:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15342"
    },
    {
      "type": "WEB",
      "url": "https://security.tanium.com/TAN-2025-030"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3GJX-HG47-FQ76

Vulnerability from github – Published: 2025-05-09 00:30 – Updated: 2025-05-09 00:30
VLAI
Details

Improper Authorization in Azure Automation allows an authorized attacker to elevate privileges over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-29827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-08T23:15:52Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Authorization in Azure Automation allows an authorized attacker to elevate privileges over a network.",
  "id": "GHSA-3gjx-hg47-fq76",
  "modified": "2025-05-09T00:30:35Z",
  "published": "2025-05-09T00:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29827"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3GP5-Q4JW-3V94

Vulnerability from github – Published: 2026-06-12 18:28 – Updated: 2026-06-12 18:28
VLAI
Summary
Budibase: Basic app users can exfiltrate stored REST datasource auth by rewriting datasource base URL
Details

Summary

Budibase stores external REST datasource credentials server-side and documents that database credentials are applied server-side and are not exposed in the UI. The REST datasource implementation redacts stored Basic/Bearer/OAuth2 auth secrets before returning datasource data to clients. However, the single-datasource GET and PUT routes are guarded by generic TABLE READ, not by Builder/Admin permission or datasource-specific ownership/resource checks.

The built-in Basic app user role maps to the WRITE permission set, which includes table read/write and query write. A Basic user can therefore read an existing REST datasource, receive redacted authConfigs values, submit an update that changes only config.url while keeping the redacted placeholders, and trigger an existing saved relative-path REST query. During update, mergeConfigs() restores the old stored secret when it sees the redaction placeholder. During query execution, Budibase prefixes the attacker-controlled datasource config.url to the relative query path and applies the resolved stored auth headers. The result is server-side disclosure of the builder-configured REST Authorization secret to an attacker-controlled listener.

Source evidence

  • packages/server/src/api/routes/datasource.ts: datasource list/create/delete routes are on builderRoutes, but GET /api/datasources/:datasourceId and PUT /api/datasources/:datasourceId are in authorizedRoutes guarded only by PermissionType.TABLE and PermissionLevel.READ.
  • packages/server/src/api/routes/datasource.ts: the :datasourceId routes do not attach datasource-specific resource authorization.
  • packages/backend-core/src/security/roles.ts: built-in Basic user maps to BuiltinPermissionID.WRITE.
  • packages/backend-core/src/security/permissions.ts: WRITE grants READ/EXECUTE levels and includes QUERY WRITE and TABLE WRITE.
  • packages/server/src/api/controllers/datasource.ts: datasourceController.update reads the stored datasource, merges ctx.request.body into it, writes the result back, and returns a redacted copy.
  • packages/server/src/sdk/workspace/datasources/datasources.ts: removeSecrets() redacts REST Basic/Bearer/OAuth2 secrets to PASSWORD_REPLACEMENT.
  • packages/server/src/sdk/workspace/datasources/datasources.ts: mergeConfigs() restores the old stored auth-secret field when the update body sends the redaction placeholder for the same auth config.
  • packages/server/src/integrations/rest.ts: relative REST query paths are prefixed with datasource config.url.
  • packages/server/src/integrations/rest.ts: REST execution resolves the selected auth config and applies the resulting auth headers to the outbound request.
  • packages/server/src/api/routes/query.ts: saved query execution POST /api/v2/queries/:queryId is guarded by QUERY WRITE, which the Basic role has through the WRITE permission set.

Reproduction outline

No production systems were tested. This is source-backed and has a local static verifier plus a proof helper for an already-running authorized instance.

  1. Deploy a current Budibase instance.
  2. As a builder/admin, create and publish an app.
  3. As the builder/admin, create a REST datasource with:
  4. config.url set to a benign legitimate API base URL.
  5. a stored REST auth config containing a sentinel secret, such as a Bearer token BUDIBASE_REST_TOKEN_SENTINEL.
  6. As the builder/admin, create a saved REST query that uses a relative path and that auth config.
  7. Add a non-builder Basic app user.
  8. As the Basic user, confirm negative controls:
  9. Builder-only datasource list/create/preview routes are denied.
  10. The user is not a builder/admin.
  11. As the Basic user, call GET /api/datasources/{datasourceId}. The response returns the datasource and redacted auth placeholders, not the raw secret.
  12. As the Basic user, call PUT /api/datasources/{datasourceId} with the same redacted datasource body but with config.url changed to an attacker-controlled HTTP listener.
  13. As the Basic user, execute the saved query with POST /api/v2/queries/{queryId}.
  14. Expected vulnerable result: the attacker listener receives the server-side REST request with the preserved stored Authorization material, even though the Basic user never knew the raw secret and should not be able to administer datasource credentials.

Local source verifier:

python3 docker-proofs/s60/verify_budibase_basic_user_datasource_source_path.py

Expected success line:

SOURCE_PATH_VERIFIED budibase_basic_user_datasource_rest_secret_exfil

Observed May 1, 2026:

  • origin/master was 8e6bf89acf1f602f3334592c4c8cd14e79f5362a.
  • Latest release was 3.37.2 from Apr 30, 2026.
  • The source verifier passed and confirmed the route, role, redaction, merge, URL-prefixing, auth-header, and saved-query execution conditions.

Proof-assist helper:

python3 docker-proofs/s60/proof_budibase_basic_user_datasource_update_rest_secret_exfil.py \
  --base-url http://127.0.0.1:10000 \
  --app-id <published-app-id> \
  --datasource-id <rest-datasource-id> \
  --query-id <saved-relative-rest-query-id> \
  --cookie '<basic-user-session-cookie>' \
  --expected-secret BUDIBASE_REST_TOKEN_SENTINEL

The helper does not start, stop, or delete containers/resources. It targets an authorized already-running instance, rewrites only config.url, captures the outbound Authorization material, and restores the original datasource by default.

Impact

This breaks the intended application-user versus builder/admin boundary for external REST datasource credentials. A Basic app user should be able to use published app functionality, but should not be able to administer datasource connection settings or extract builder-configured REST auth secrets. In a realistic internal-tool deployment, REST datasource auth configs often contain bearer tokens, API keys, Basic credentials, OAuth client secrets, service account tokens, or integration credentials for ticketing, CRM, ERP, security, and operational systems.

An attacker with only Basic app-user access to an app that uses an authenticated REST datasource can redirect future query traffic to an attacker-controlled endpoint and collect the preserved server-side Authorization header. This is distinct from public REST datasource SSRF issues because the core impact is stored credential disclosure across the role boundary, and it works with an external attacker-controlled URL rather than depending on internal-network reachability.

Remediation ideas

  • Move GET/PUT /api/datasources/:datasourceId behind Builder/Admin datasource permissions, or add datasource-specific resource authorization.
  • Do not allow non-builder app users to update datasource config, authConfigs, base URL, default headers, or plugin connection settings.
  • Split non-sensitive datasource metadata reads from credential-bearing/admin datasource reads.
  • Treat redaction placeholders as valid only in trusted builder/admin update flows.
  • Consider rotating REST datasource auth secrets for affected deployments after patching.

Duplicate/nearby public issue notes

Public triage found known Budibase REST datasource SSRF and protected-endpoint auth-bypass CVEs, but no obvious public duplicate for this specific Basic app-user PUT /api/datasources/:id role-boundary issue combined with preserved REST authConfigs secret exfiltration through a changed datasource base URL.

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": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.39.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T18:28:40Z",
    "nvd_published_at": "2026-05-27T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nBudibase stores external REST datasource credentials server-side and documents that database credentials are applied server-side and are not exposed in the UI. The REST datasource implementation redacts stored Basic/Bearer/OAuth2 auth secrets before returning datasource data to clients. However, the single-datasource `GET` and `PUT` routes are guarded by generic `TABLE READ`, not by Builder/Admin permission or datasource-specific ownership/resource checks.\n\nThe built-in Basic app user role maps to the `WRITE` permission set, which includes table read/write and query write. A Basic user can therefore read an existing REST datasource, receive redacted `authConfigs` values, submit an update that changes only `config.url` while keeping the redacted placeholders, and trigger an existing saved relative-path REST query. During update, `mergeConfigs()` restores the old stored secret when it sees the redaction placeholder. During query execution, Budibase prefixes the attacker-controlled datasource `config.url` to the relative query path and applies the resolved stored auth headers. The result is server-side disclosure of the builder-configured REST Authorization secret to an attacker-controlled listener.\n\n### Source evidence\n- `packages/server/src/api/routes/datasource.ts`: datasource list/create/delete routes are on `builderRoutes`, but `GET /api/datasources/:datasourceId` and `PUT /api/datasources/:datasourceId` are in `authorizedRoutes` guarded only by `PermissionType.TABLE` and `PermissionLevel.READ`.\n- `packages/server/src/api/routes/datasource.ts`: the `:datasourceId` routes do not attach datasource-specific resource authorization.\n- `packages/backend-core/src/security/roles.ts`: built-in Basic user maps to `BuiltinPermissionID.WRITE`.\n- `packages/backend-core/src/security/permissions.ts`: `WRITE` grants `READ`/`EXECUTE` levels and includes `QUERY WRITE` and `TABLE WRITE`.\n- `packages/server/src/api/controllers/datasource.ts`: `datasourceController.update` reads the stored datasource, merges `ctx.request.body` into it, writes the result back, and returns a redacted copy.\n- `packages/server/src/sdk/workspace/datasources/datasources.ts`: `removeSecrets()` redacts REST Basic/Bearer/OAuth2 secrets to `PASSWORD_REPLACEMENT`.\n- `packages/server/src/sdk/workspace/datasources/datasources.ts`: `mergeConfigs()` restores the old stored auth-secret field when the update body sends the redaction placeholder for the same auth config.\n- `packages/server/src/integrations/rest.ts`: relative REST query paths are prefixed with datasource `config.url`.\n- `packages/server/src/integrations/rest.ts`: REST execution resolves the selected auth config and applies the resulting auth headers to the outbound request.\n- `packages/server/src/api/routes/query.ts`: saved query execution `POST /api/v2/queries/:queryId` is guarded by `QUERY WRITE`, which the Basic role has through the `WRITE` permission set.\n\n### Reproduction outline\nNo production systems were tested. This is source-backed and has a local static verifier plus a proof helper for an already-running authorized instance.\n\n1. Deploy a current Budibase instance.\n2. As a builder/admin, create and publish an app.\n3. As the builder/admin, create a REST datasource with:\n   - `config.url` set to a benign legitimate API base URL.\n   - a stored REST auth config containing a sentinel secret, such as a Bearer token `BUDIBASE_REST_TOKEN_SENTINEL`.\n4. As the builder/admin, create a saved REST query that uses a relative path and that auth config.\n5. Add a non-builder Basic app user.\n6. As the Basic user, confirm negative controls:\n   - Builder-only datasource list/create/preview routes are denied.\n   - The user is not a builder/admin.\n7. As the Basic user, call `GET /api/datasources/{datasourceId}`. The response returns the datasource and redacted auth placeholders, not the raw secret.\n8. As the Basic user, call `PUT /api/datasources/{datasourceId}` with the same redacted datasource body but with `config.url` changed to an attacker-controlled HTTP listener.\n9. As the Basic user, execute the saved query with `POST /api/v2/queries/{queryId}`.\n10. Expected vulnerable result: the attacker listener receives the server-side REST request with the preserved stored Authorization material, even though the Basic user never knew the raw secret and should not be able to administer datasource credentials.\n\nLocal source verifier:\n\n```bash\npython3 docker-proofs/s60/verify_budibase_basic_user_datasource_source_path.py\n```\n\nExpected success line:\n\n```text\nSOURCE_PATH_VERIFIED budibase_basic_user_datasource_rest_secret_exfil\n```\n\nObserved May 1, 2026:\n\n- `origin/master` was `8e6bf89acf1f602f3334592c4c8cd14e79f5362a`.\n- Latest release was `3.37.2` from Apr 30, 2026.\n- The source verifier passed and confirmed the route, role, redaction, merge, URL-prefixing, auth-header, and saved-query execution conditions.\n\nProof-assist helper:\n\n```bash\npython3 docker-proofs/s60/proof_budibase_basic_user_datasource_update_rest_secret_exfil.py \\\n  --base-url http://127.0.0.1:10000 \\\n  --app-id \u003cpublished-app-id\u003e \\\n  --datasource-id \u003crest-datasource-id\u003e \\\n  --query-id \u003csaved-relative-rest-query-id\u003e \\\n  --cookie \u0027\u003cbasic-user-session-cookie\u003e\u0027 \\\n  --expected-secret BUDIBASE_REST_TOKEN_SENTINEL\n```\n\nThe helper does not start, stop, or delete containers/resources. It targets an authorized already-running instance, rewrites only `config.url`, captures the outbound Authorization material, and restores the original datasource by default.\n\n### Impact\nThis breaks the intended application-user versus builder/admin boundary for external REST datasource credentials. A Basic app user should be able to use published app functionality, but should not be able to administer datasource connection settings or extract builder-configured REST auth secrets. In a realistic internal-tool deployment, REST datasource auth configs often contain bearer tokens, API keys, Basic credentials, OAuth client secrets, service account tokens, or integration credentials for ticketing, CRM, ERP, security, and operational systems.\n\nAn attacker with only Basic app-user access to an app that uses an authenticated REST datasource can redirect future query traffic to an attacker-controlled endpoint and collect the preserved server-side Authorization header. This is distinct from public REST datasource SSRF issues because the core impact is stored credential disclosure across the role boundary, and it works with an external attacker-controlled URL rather than depending on internal-network reachability.\n\n### Remediation ideas\n- Move `GET`/`PUT /api/datasources/:datasourceId` behind Builder/Admin datasource permissions, or add datasource-specific resource authorization.\n- Do not allow non-builder app users to update datasource `config`, `authConfigs`, base URL, default headers, or plugin connection settings.\n- Split non-sensitive datasource metadata reads from credential-bearing/admin datasource reads.\n- Treat redaction placeholders as valid only in trusted builder/admin update flows.\n- Consider rotating REST datasource auth secrets for affected deployments after patching.\n\n### Duplicate/nearby public issue notes\nPublic triage found known Budibase REST datasource SSRF and protected-endpoint auth-bypass CVEs, but no obvious public duplicate for this specific Basic app-user `PUT /api/datasources/:id` role-boundary issue combined with preserved REST `authConfigs` secret exfiltration through a changed datasource base URL.",
  "id": "GHSA-3gp5-q4jw-3v94",
  "modified": "2026-06-12T18:28:40Z",
  "published": "2026-06-12T18:28:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-3gp5-q4jw-3v94"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48152"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "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": "Budibase: Basic app users can exfiltrate stored REST datasource auth by rewriting datasource base URL"
}

GHSA-3GPX-P63P-PR5R

Vulnerability from github – Published: 2025-03-21 09:30 – Updated: 2025-03-21 21:25
VLAI
Summary
Mattermost Fails to Enforce Certain Search APIs
Details

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8 fail to enforce MFA on certain search APIs, which allows authenticated attackers to bypass MFA protections via user search, channel search, or team search queries.

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/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.4.0"
            },
            {
              "fixed": "10.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "10.5.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T21:25:30Z",
    "nvd_published_at": "2025-03-21T09:15:13Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.4.x \u003c= 10.4.2, 10.3.x \u003c= 10.3.3, 9.11.x \u003c= 9.11.8 fail to enforce MFA on certain search APIs, which allows authenticated attackers to bypass MFA protections via user search, channel search, or team search queries.",
  "id": "GHSA-3gpx-p63p-pr5r",
  "modified": "2025-03-21T21:25:30Z",
  "published": "2025-03-21T09:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30179"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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": "Mattermost Fails to Enforce Certain Search APIs"
}

GHSA-3GRG-4GWX-FP3C

Vulnerability from github – Published: 2023-05-12 21:30 – Updated: 2024-04-04 04:04
VLAI
Details

VMware Aria Operations contains a privilege escalation vulnerability. A malicious actor with administrative access to the local system can escalate privileges to 'root'.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-20880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-12T21:15:09Z",
    "severity": "MODERATE"
  },
  "details": "VMware Aria Operations contains a privilege escalation vulnerability. A malicious actor with administrative access to the local system can escalate privileges to \u0027root\u0027.",
  "id": "GHSA-3grg-4gwx-fp3c",
  "modified": "2024-04-04T04:04:41Z",
  "published": "2023-05-12T21:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20880"
    },
    {
      "type": "WEB",
      "url": "https://www.vmware.com/security/advisories/VMSA-2023-0009.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3GW8-RMRM-8CWC

Vulnerability from github – Published: 2026-09-01 21:31 – Updated: 2026-09-01 21:31
VLAI
Details

A privilege escalation vulnerability exists in the web-based management interface of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to complete state-changing actions that should not be allowed by their current level of authorization on the platform.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-73723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-01T20:17:19Z",
    "severity": "HIGH"
  },
  "details": "A privilege escalation vulnerability exists in the web-based management interface of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to complete state-changing actions that should not be allowed by their current level of authorization on the platform.",
  "id": "GHSA-3gw8-rmrm-8cwc",
  "modified": "2026-09-01T21:31:49Z",
  "published": "2026-09-01T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73723"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05133en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3H2Q-J2V4-6W5R

Vulnerability from github – Published: 2026-03-09 19:53 – Updated: 2026-03-09 19:53
VLAI
Summary
OpenClaw's system.run allowlist approval parsing missed PowerShell encoded-command wrappers
Details

OpenClaw's system.run shell-wrapper detection did not recognize PowerShell -EncodedCommand forms as inline-command wrappers.

In allowlist mode, a caller with access to system.run could invoke pwsh or powershell using -EncodedCommand, -enc, or -e, and the request would fall back to plain argv analysis instead of the normal shell-wrapper approval path. This could allow a PowerShell inline payload to execute without the approval step that equivalent -Command invocations would require.

Latest published npm version: 2026.3.2

Fixed on main on March 7, 2026 in 1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d by recognizing PowerShell encoded-command aliases during shell-wrapper parsing, so allowlist mode continues to require approval for those payloads. Normal approved PowerShell wrapper flows continue to work.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.3.2
  • Patched version: >= 2026.3.7

Fix Commit(s)

  • 1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d

Release Process Note

npm 2026.3.7 was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-09T19:53:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "OpenClaw\u0027s `system.run` shell-wrapper detection did not recognize PowerShell `-EncodedCommand` forms as inline-command wrappers.\n\nIn `allowlist` mode, a caller with access to `system.run` could invoke `pwsh` or `powershell` using `-EncodedCommand`, `-enc`, or `-e`, and the request would fall back to plain argv analysis instead of the normal shell-wrapper approval path. This could allow a PowerShell inline payload to execute without the approval step that equivalent `-Command` invocations would require.\n\nLatest published npm version: `2026.3.2`\n\nFixed on `main` on March 7, 2026 in `1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d` by recognizing PowerShell encoded-command aliases during shell-wrapper parsing, so allowlist mode continues to require approval for those payloads. Normal approved PowerShell wrapper flows continue to work.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.2`\n- Patched version: `\u003e= 2026.3.7`\n\n## Fix Commit(s)\n\n- `1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d`\n\n## Release Process Note\n\nnpm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.\n\nThanks @tdjackey for reporting.",
  "id": "GHSA-3h2q-j2v4-6w5r",
  "modified": "2026-03-09T19:53:58Z",
  "published": "2026-03-09T19:53:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3h2q-j2v4-6w5r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw\u0027s system.run allowlist approval parsing missed PowerShell encoded-command wrappers"
}

GHSA-3H5J-FWX4-2458

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable improper authorization vulnerability exists in admin_addPeer API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-12112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-19T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable improper authorization vulnerability exists in admin_addPeer API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.",
  "id": "GHSA-3h5j-fwx4-2458",
  "modified": "2022-05-13T01:01:38Z",
  "published": "2022-05-13T01:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12112"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0464"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3H92-XGH6-5M97

Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2025-10-15 15:30
VLAI
Details

In gaizhenbiao/chuanhuchatgpt, specifically the version tagged as 20240121, there exists a vulnerability due to improper access control mechanisms. This flaw allows an authenticated attacker to bypass intended access restrictions and read the history files of other users, potentially leading to unauthorized access to sensitive information. The vulnerability is present in the application's handling of access control for the history path, where no adequate mechanism is in place to prevent an authenticated user from accessing another user's chat history files. This issue poses a significant risk as it could allow attackers to obtain sensitive information from the chat history of other users.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-3404"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T19:16:01Z",
    "severity": "MODERATE"
  },
  "details": "In gaizhenbiao/chuanhuchatgpt, specifically the version tagged as 20240121, there exists a vulnerability due to improper access control mechanisms. This flaw allows an authenticated attacker to bypass intended access restrictions and read the `history` files of other users, potentially leading to unauthorized access to sensitive information. The vulnerability is present in the application\u0027s handling of access control for the `history` path, where no adequate mechanism is in place to prevent an authenticated user from accessing another user\u0027s chat history files. This issue poses a significant risk as it could allow attackers to obtain sensitive information from the chat history of other users.",
  "id": "GHSA-3h92-xgh6-5m97",
  "modified": "2025-10-15T15:30:19Z",
  "published": "2024-06-06T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3404"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gaizhenbiao/chuanhuchatgpt/commit/ccc7479ace5c9e1a1d9f4daf2e794ffd3865fc2b"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/ed32fc32-cb8f-4fbd-8209-cc835d279699"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3HJ7-6VMJ-H8V4

Vulnerability from github – Published: 2026-10-09 20:42 – Updated: 2026-10-09 20:42
VLAI
Summary
pacioli: A submit consent marker licensed cancellation of caller-named pre-existing documents
Details

Impact

pacioli-guard's document-layer consent gate requires a human-minted, single-use, document-bound and act-bound marker before a credential carrying API Key Scope.require_consent may submit or cancel a document. Because ERPNext performs further document writes as a consequence of a governed act, nested acts are allowed to "ride" the consent established by the enclosing act instead of needing a marker of their own.

The ride predicate returned true for every cancel, regardless of which act the enclosing marker authorised. Riding never reaches consent_verdict, which is where the marker-to-act binding is enforced. The result: any Document.cancel() performed inside an act that had established consent reached docstatus = 2 with no marker, no act-binding check, no single-use spend, and no denial audit row.

This is reachable with the exact grant an operator is documented to give the broker, and the cancelled document's identity is caller-controlled:

  • Sales Invoice.on_submit (sales_invoice.py:507) calls process_asset_depreciation() unconditionally, reaching depreciate_asset_on_sale (:1508-1516).
  • That iterates the invoice's item rows and calls frappe.get_doc("Asset", d.asset). Sales Invoice Item.asset is a plain writable Link with no read_only and no fetch_from, so the caller supplies it in the request body. The validation that would constrain it sits behind if d.is_fixed_asset: (:428-429), a server-set field.
  • The chain reaches depreciation.py:481 and then asset_depreciation_schedule.py:215-217, which calls current_schedule.cancel() on a docstatus == 1, submittable Asset Depreciation Schedule through the document lifecycle (only should_not_cancel_depreciation_entries is set, not ignore_validate, so before_cancel does fire and the ride is what admitted it).

So one marker authorising submit Sales Invoice X cancelled a submitted document the human was never shown and never approved. Cancelling such a document reverses its ledger effect.

The same shape exists behind wider grants, for example Unreconcile Payment.on_submit (unreconcile_payment.py:59-64), which walks a child table the caller fills and reaches accounts/utils.py:857/:859 gain_loss_je.cancel() on submitted Journal Entries.

Who is affected

Only sites that had opted into consent gating: a credential must hold an API Key Scope with require_consent set. pacioli-guard is inert for principals without such a grant, and the credential-scoping floor (auth_hooks) is unaffected by this issue.

The document-layer consent gate was first published in 0.9.6, which is the only released version in the affected range.

Patches

Fixed in 0.10.0. The ride now discriminates on the enclosing act: an undo may cascade into further undos, but a submit may not cascade into the cancellation of a document that already has a name, because that is an act a human could have been asked to approve. The custody stamp carries the act it was established for rather than a bare boolean, which is the state the vulnerable code lacked.

Upgrading changes behavior. Any ERPNext flow where a submit cascades into a lifecycle cancel now requires a consent marker for that cancel as well as for the act itself. In ERPNext v16 that includes asset sale, partial-quantity asset sale, a credit note against an asset sale, Asset Repair capitalization, Asset Shift Allocation, Asset Value Adjustment, and Unreconcile Payment. To make that possible, the X-Pacioli-Consent header now accepts several markers separated by whitespace or commas; each remains bound to one document and one act, requires a different minter, and is spent exactly once.

Workarounds

On 0.9.6, remove require_consent from affected grants and rely on the credential-scoping floor alone, or scope governed credentials so they cannot submit documents whose controllers cancel other documents (for ERPNext slice-one, Sales Invoice with a populated item-row asset link is the known path). Neither is a substitute for upgrading.

Residual, stated

Under a governed cancel, a cascaded cancel of a pre-existing document still rides. That is load-bearing for undo (an ordinary invoice cancel makes ERPNext cancel the credit/debit notes and journals it generated, via accounts_controller.py:2001-2005) and cannot be narrowed without a signal that a cascaded cancel is a consequence of the enclosing document specifically. That justification does not describe everything the residual admits: at least one instance is caller-steered in the same shape as the issue fixed here, Asset Repair.on_cancel (asset_repair.py:215-222), which cancels a Serial and Batch Bundle named by a Link the caller fills in a child table. pacioli-guard also does not see writes that set flags.ignore_validate or that skip the document lifecycle entirely (raw SQL, db_update/db_set field writes); those residuals are published in the project's own documentation and are unchanged by this advisory.

Credit

Found by an internal adversarial review on 2026-07-28 that traced the predicate against frappe 16.28.0 and ERPNext v16 source rather than the project's own documentation. The prior code comment asserted that no such lever was known; that assertion had been written without the corresponding source sweep.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pacioli-guard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.6"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:42:51Z",
    "nvd_published_at": "2026-10-09T18:17:06Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`pacioli-guard`\u0027s document-layer consent gate requires a human-minted, single-use, document-bound and **act-bound** marker before a credential carrying `API Key Scope.require_consent` may submit or cancel a document. Because ERPNext performs further document writes as a consequence of a governed act, nested acts are allowed to \"ride\" the consent established by the enclosing act instead of needing a marker of their own.\n\nThe ride predicate returned `true` for **every** cancel, regardless of which act the enclosing marker authorised. Riding never reaches `consent_verdict`, which is where the marker-to-act binding is enforced. The result: any `Document.cancel()` performed inside an act that had established consent reached `docstatus = 2` with no marker, no act-binding check, no single-use spend, and **no denial audit row**.\n\nThis is reachable with the exact grant an operator is documented to give the broker, and the cancelled document\u0027s identity is caller-controlled:\n\n- `Sales Invoice.on_submit` (`sales_invoice.py:507`) calls `process_asset_depreciation()` unconditionally, reaching `depreciate_asset_on_sale` (`:1508-1516`).\n- That iterates the invoice\u0027s item rows and calls `frappe.get_doc(\"Asset\", d.asset)`. `Sales Invoice Item.asset` is a plain writable `Link` with no `read_only` and no `fetch_from`, so the caller supplies it in the request body. The validation that would constrain it sits behind `if d.is_fixed_asset:` (`:428-429`), a server-set field.\n- The chain reaches `depreciation.py:481` and then `asset_depreciation_schedule.py:215-217`, which calls `current_schedule.cancel()` on a `docstatus == 1`, submittable `Asset Depreciation Schedule` **through the document lifecycle** (only `should_not_cancel_depreciation_entries` is set, not `ignore_validate`, so `before_cancel` does fire and the ride is what admitted it).\n\nSo one marker authorising `submit Sales Invoice X` cancelled a submitted document the human was never shown and never approved. Cancelling such a document reverses its ledger effect.\n\nThe same shape exists behind wider grants, for example `Unreconcile Payment.on_submit` (`unreconcile_payment.py:59-64`), which walks a child table the caller fills and reaches `accounts/utils.py:857`/`:859` `gain_loss_je.cancel()` on submitted Journal Entries.\n\n### Who is affected\n\nOnly sites that had opted into consent gating: a credential must hold an `API Key Scope` with `require_consent` set. `pacioli-guard` is inert for principals without such a grant, and the credential-scoping floor (`auth_hooks`) is unaffected by this issue.\n\nThe document-layer consent gate was first published in 0.9.6, which is the only released version in the affected range.\n\n### Patches\n\nFixed in **0.10.0**. The ride now discriminates on the **enclosing act**: an undo may cascade into further undos, but a submit may not cascade into the cancellation of a document that already has a name, because that is an act a human could have been asked to approve. The custody stamp carries the act it was established for rather than a bare boolean, which is the state the vulnerable code lacked.\n\n**Upgrading changes behavior.** Any ERPNext flow where a submit cascades into a lifecycle cancel now requires a consent marker for that cancel as well as for the act itself. In ERPNext v16 that includes asset sale, partial-quantity asset sale, a credit note against an asset sale, Asset Repair capitalization, Asset Shift Allocation, Asset Value Adjustment, and `Unreconcile Payment`. To make that possible, the `X-Pacioli-Consent` header now accepts several markers separated by whitespace or commas; each remains bound to one document and one act, requires a different minter, and is spent exactly once.\n\n### Workarounds\n\nOn 0.9.6, remove `require_consent` from affected grants and rely on the credential-scoping floor alone, or scope governed credentials so they cannot submit documents whose controllers cancel other documents (for ERPNext slice-one, `Sales Invoice` with a populated item-row `asset` link is the known path). Neither is a substitute for upgrading.\n\n### Residual, stated\n\nUnder a governed **cancel**, a cascaded cancel of a pre-existing document still rides. That is load-bearing for undo (an ordinary invoice cancel makes ERPNext cancel the credit/debit notes and journals it generated, via `accounts_controller.py:2001-2005`) and cannot be narrowed without a signal that a cascaded cancel is a consequence of the enclosing document specifically. That justification does not describe everything the residual admits: at least one instance is caller-steered in the same shape as the issue fixed here, `Asset Repair.on_cancel` (`asset_repair.py:215-222`), which cancels a `Serial and Batch Bundle` named by a Link the caller fills in a child table. `pacioli-guard` also does not see writes that set `flags.ignore_validate` or that skip the document lifecycle entirely (raw SQL, `db_update`/`db_set` field writes); those residuals are published in the project\u0027s own documentation and are unchanged by this advisory.\n\n### Credit\n\nFound by an internal adversarial review on 2026-07-28 that traced the predicate against frappe 16.28.0 and ERPNext v16 source rather than the project\u0027s own documentation. The prior code comment asserted that no such lever was known; that assertion had been written without the corresponding source sweep.",
  "id": "GHSA-3hj7-6vmj-h8v4",
  "modified": "2026-10-09T20:42:51Z",
  "published": "2026-10-09T20:42:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/john-broadway/pacioli/security/advisories/GHSA-3hj7-6vmj-h8v4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107841"
    },
    {
      "type": "WEB",
      "url": "https://github.com/john-broadway/pacioli/commit/f3c7219f5dde6050bd7921e0ac55afd02771250c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/john-broadway/pacioli"
    },
    {
      "type": "WEB",
      "url": "https://github.com/john-broadway/pacioli/releases/tag/guard-v0.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pacioli: A submit consent marker licensed cancellation of caller-named pre-existing documents"
}
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