Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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

7130 vulnerabilities reference this CWE, most recent first.

GHSA-3G7M-G8QM-X6J5

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2025-11-07 23:21
VLAI
Summary
Magento discloses sensitive information
Details

Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an improper input validation vulnerability via the quoteId parameter. An attacker can abuse this vulnerability to disclose sensitive information.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.7-p1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.3.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.2-p1"
            },
            {
              "fixed": "2.4.2-p2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.2"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-36039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-07T23:21:00Z",
    "nvd_published_at": "2021-09-01T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Magento Commerce versions 2.4.2 (and earlier), 2.4.2-p1 (and earlier) and 2.3.7 (and earlier) are affected by an improper input validation vulnerability via the `quoteId` parameter. An attacker can abuse this vulnerability to disclose sensitive information.",
  "id": "GHSA-3g7m-g8qm-x6j5",
  "modified": "2025-11-07T23:21:00Z",
  "published": "2022-05-24T19:12:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36039"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb21-64.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento discloses sensitive information"
}

GHSA-3GFJ-FXX4-F22W

Vulnerability from github – Published: 2022-11-08 22:31 – Updated: 2022-11-10 14:32
VLAI
Summary
OpenFGA Authorization Bypass
Details

Overview

During our internal security assessment, it was discovered that OpenFGA versions v0.2.4 and prior are vulnerable to authorization bypass under certain conditions.

Am I Affected?

You are affected by this vulnerability if you are using openfga/openfga version v0.2.4 or prior, and have tuples where the user field is set to a userset e.g. folder:test#owner, and the tuple's relation is used on the right-hand side of a from statement.

How to fix that?

Upgrade to version 0.2.5.

Backward Compatibility

This update is not backward compatible. Any tuples where the user field is set to a userset, and the tuple's relation is used on the right-hand side of a from statement have to be rewritten.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-08T22:31:25Z",
    "nvd_published_at": "2022-11-08T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Overview\nDuring our internal security assessment, it was discovered that OpenFGA versions v0.2.4 and prior are vulnerable to authorization bypass under certain conditions.\n\n### Am I Affected?\nYou are affected by this vulnerability if you are using `openfga/openfga` version v0.2.4 or prior, and have tuples where the `user` field is set to a `userset` e.g. `folder:test#owner`, and the tuple\u0027s relation is used on the right-hand side of a `from` statement.\n\n### How to fix that?\nUpgrade to version 0.2.5.\n\n### Backward Compatibility\nThis update is not backward compatible.\nAny tuples where the `user` field is set to a `userset`, and the tuple\u0027s relation is used on the right-hand side of a `from` statement have to be rewritten.",
  "id": "GHSA-3gfj-fxx4-f22w",
  "modified": "2022-11-10T14:32:09Z",
  "published": "2022-11-08T22:31:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-3gfj-fxx4-f22w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39352"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/commit/776e80505e8d184b2286acc8268d8d74f36a9984"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/releases/tag/v0.2.5"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenFGA Authorization Bypass"
}

GHSA-3GFV-Q5HP-JPCF

Vulnerability from github – Published: 2026-08-14 21:31 – Updated: 2026-08-17 21:31
VLAI
Details

OpenStack Octavia through 18.0.0 mishandles quality of service (QoS) policy authorization. By associating another project's QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-74248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-14T21:17:58Z",
    "severity": "MODERATE"
  },
  "details": "OpenStack Octavia through 18.0.0 mishandles quality of service (QoS) policy authorization. By associating another project\u0027s QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected.",
  "id": "GHSA-3gfv-q5hp-jpcf",
  "modified": "2026-08-17T21:31:18Z",
  "published": "2026-08-14T21:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74248"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/octavia/+bug/2161500"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/08/13/12"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/17/2"
    }
  ],
  "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-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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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'.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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"
}

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.