Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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

7172 vulnerabilities reference this CWE, most recent first.

GHSA-QQCV-FJFG-8RP6

Vulnerability from github – Published: 2026-06-17 21:34 – Updated: 2026-07-21 15:30
VLAI
Details

Sonatype Nexus Repository Manager before 3.93.0 contains an authorization vulnerability in the proxy repository configuration that allows a delegated repository administrator to disclose stored upstream proxy credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-10741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T20:16:48Z",
    "severity": "MODERATE"
  },
  "details": "Sonatype Nexus Repository Manager before 3.93.0 contains an authorization vulnerability in the proxy repository configuration that allows a delegated repository administrator to disclose stored upstream proxy credentials.",
  "id": "GHSA-qqcv-fjfg-8rp6",
  "modified": "2026-07-21T15:30:29Z",
  "published": "2026-06-17T21:34:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10741"
    },
    {
      "type": "WEB",
      "url": "https://help.sonatype.com/en/sonatype-nexus-repository-3-93-0-release-notes.html"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/articles/52341191736851"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:L/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-QQG7-GCXW-GMJ3

Vulnerability from github – Published: 2022-05-17 03:57 – Updated: 2025-04-14 20:50
VLAI
Summary
Apache Ranger allows users to bypass intended access restrictions via the REST API
Details

The Policy Admin Tool in Apache Ranger before 0.5.1 allows remote authenticated users to bypass intended access restrictions via the REST API.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.ranger:ranger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2015-5167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-14T20:50:41Z",
    "nvd_published_at": "2016-04-12T14:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The Policy Admin Tool in Apache Ranger before 0.5.1 allows remote authenticated users to bypass intended access restrictions via the REST API.",
  "id": "GHSA-qqg7-gcxw-gmj3",
  "modified": "2025-04-14T20:50:42Z",
  "published": "2022-05-17T03:57:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5167"
    },
    {
      "type": "WEB",
      "url": "https://cwiki.apache.org/confluence/display/RANGER/Vulnerabilities+found+in+Ranger"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/ranger"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.apache.org/mod_mbox/ranger-dev/201602.mbox/%3CD2D9A4C5.114ECA%25vel%40apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.apache.org/mod_mbox/ranger-dev/201602.mbox/%3CD2D9A4C5.114ECA%25vel@apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200501000000*/http://www.securityfocus.com/bid/82871"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Ranger allows users to bypass intended access restrictions via the REST API"
}

GHSA-QQHH-VFCP-578H

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

antd-admin 5.5.0 is affected by an incorrect access control vulnerability. Unauthorized access to some interfaces in the foreground leads to leakage of sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-46371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-14T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "antd-admin 5.5.0 is affected by an incorrect access control vulnerability. Unauthorized access to some interfaces in the foreground leads to leakage of sensitive information.",
  "id": "GHSA-qqhh-vfcp-578h",
  "modified": "2022-07-13T00:01:51Z",
  "published": "2022-02-15T00:02:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46371"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zuiidea/antd-admin/issues/1127"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QQJF-53CJ-PWVV

Vulnerability from github – Published: 2026-09-10 23:04 – Updated: 2026-09-10 23:04
VLAI
Summary
Traefik HTTP/3 Backend NTLM Connection Reuse
Details

Summary

Traefik's HTTP/3 request path did not initialize the connection-scoped backend transport holder that isolates connection-bound NTLM and Negotiate (Kerberos) authentication on the HTTP/1.1 and HTTP/2 paths. The HTTP/3 entrypoint reuses the HTTPS handler chain and reaches the same backend round-tripper, but its ConnContext never called service.AddTransportOnContext, so kerberosRoundTripper fell back to the shared backend transport instead of a per-frontend-connection pool. On a route served over HTTP/3 to a backend that binds identity to a persistent connection via NTLM or Negotiate, an unrelated HTTP/3 client could be assigned a backend connection already authenticated as a victim and inherit that identity, reading victim-only data and performing actions as the victim without presenting the victim's credentials. Affected deployments require HTTP/3 enabled on the entrypoint, a backend using connection-bound NTLM/Negotiate authentication, and backend keep-alive; deployments using ordinary per-request authentication are not affected.

Patches

  • https://github.com/traefik/traefik/releases/tag/v2.11.57
  • https://github.com/traefik/traefik/releases/tag/v3.7.13

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description ## Traefik HTTP/3 Backend NTLM Connection Reuse ### Summary Traefik's HTTP/3 request path does not initialize the connection-scoped backend transport state that Traefik uses to isolate connection-bound NTLM and Negotiate authentication for HTTP/1.1 and HTTP/2. When a backend keeps authenticated identity on a persistent HTTP/1.1 TCP connection, an unrelated HTTP/3 client can reuse a victim-authenticated backend connection and inherit that backend identity. In the attached reproduction, the HTTPS/HTTP/1.1 control case behaves correctly and isolates the attacker, but the HTTP/3 case allows a second unauthenticated client to read victim-only data and execute a state-changing request as `actor=victim`. Validated target: - Repository: `traefik/traefik` - Commit: `f2d0794417e4d06343e6e7c4722143f5b34bee45` - Validation time: `2026-08-25T06:48:02Z` - Commit time: `2026-08-24T08:26:06Z` - Patched status: not evaluated ### Details The issue is caused by a protocol-parity gap between the normal TCP HTTP entrypoint path and the HTTP/3 entrypoint path. For HTTP/1.1 and HTTP/2, Traefik explicitly creates a connection-scoped holder that can later store a dedicated RoundTripper for NTLM or Negotiate:
// pkg/server/server_entrypoint_tcp.go:691-703
var connContext multipleConnContext
connContext.AddConnContextFunc(func(ctx context.Context, c net.Conn) context.Context {
    // This adds an empty struct in order to store a RoundTripper in the ConnContext in case of Kerberos or NTLM.
    ctx = service.AddTransportOnContext(ctx)

    if tlsConn, ok := c.(*tls.Conn); ok {
        if tlsConnWithOptionsName, ok := tlsConn.NetConn().(tcp.TLSConn); ok {
            return tcp.AddTLSOptionsNameInContext(ctx, tlsConnWithOptionsName.TLSOptionsName)
        }
    }

    return ctx
})
That helper installs the per-connection holder, and `kerberosRoundTripper` depends on it. If the holder is absent, it falls back to the shared original backend transport. If NTLM or Negotiate is detected, it stores a dedicated cloned RoundTripper into that holder so future requests stay on the authenticated backend connection:
// pkg/server/service/transport.go:374-402
func AddTransportOnContext(ctx context.Context) context.Context {
    return context.WithValue(ctx, transportKey, &stickyRoundTripper{})
}

type kerberosRoundTripper struct {
    new                  func() http.RoundTripper
    OriginalRoundTripper http.RoundTripper
}

func (k *kerberosRoundTripper) RoundTrip(request *http.Request) (*http.Response, error) {
    value, ok := request.Context().Value(transportKey).(*stickyRoundTripper)
    if !ok {
        return k.OriginalRoundTripper.RoundTrip(request)
    }

    if value.RoundTripper != nil {
        return value.RoundTripper.RoundTrip(request)
    }

    resp, err := k.OriginalRoundTripper.RoundTrip(request)

    // If we found that we are authenticating with Kerberos (Negotiate) or NTLM.
    // We put a dedicated roundTripper in the ConnContext.
    // This will stick the next calls to the same connection with the backend.
    if err == nil && containsNTLMorNegotiate(resp.Header.Values("WWW-Authenticate")) {
        value.RoundTripper = k.new()
    }
    return resp, err
}
For HTTP/3, the server reuses the normal HTTPS handler chain, but its `ConnContext` only propagates the TLS options name and does not call `service.AddTransportOnContext`:
// pkg/server/server_entrypoint_tcp_http3.go:65-80
h3.Server = &http3.Server{
    Addr:      config.GetAddress(),
    Port:      config.HTTP3.AdvertisedPort,
    Handler:   httpsServer.Server.(*http.Server).Handler,
    TLSConfig: &tls.Config{GetConfigForClient: h3.getTLSConfigForClient},
    QUICConfig: &quic.Config{
        Allow0RTT: false,
    },
    ConnContext: func(ctx context.Context, c *quic.Conn) context.Context {
        tlsOptionsName, err := h3.getTLSOptionsName(c)
        if err != nil {
            log.Error().Msgf("Error getting TLS options name for client: %v", err)
            return ctx
        }
        return tcp.AddTLSOptionsNameInContext(ctx, tlsOptionsName)
    },
}
This means HTTP/3 requests reach the same reverse-proxy and backend transport logic as HTTPS, but without the connection-scoped transport holder that NTLM and Negotiate isolation relies on. In practice, the flow is: 1. A victim authenticates through Traefik to a backend that binds identity to the backend TCP connection using NTLM or Negotiate. 2. Because the HTTP/3 request context does not contain `transportKey`, `kerberosRoundTripper` uses the shared `OriginalRoundTripper`. 3. No frontend-connection-specific dedicated backend pool is installed for that HTTP/3 client. 4. A second unrelated HTTP/3 client can be assigned the same backend TCP connection after the victim has authenticated it. 5. That second client inherits the victim's backend identity without sending the victim's credentials. The attached verifier demonstrates both the negative control and the exploit path: - HTTPS/HTTP/1.1 control case: the attacker uses a separate frontend connection and correctly receives `401` - HTTP/3 exploit case: the attacker uses a separate HTTP/3 client with no `Authorization` header, reads `resource=secret actor=victim`, executes `action=transfer actor=victim to=attacker amount=5000`, and hits the same backend TCP connection identifier as the victim ### PoC See the reproduction materials at: https://gist.github.com/OneZ3r0/41da8e8b79ebbe444a94f8a2a3a30895 The gist can also be downloaded as a ZIP archive. Files included in this gist: - `run.sh` - `Dockerfile` - `.dockerignore` - `go.mod` - `go.sum` - `verify.go` The package is intentionally kept as a single-container reproduction: 1. `run.sh` builds a local image for the pinned target commit 2. the Dockerfile builds both Traefik and the verifier during image build 3. the container runs the verifier directly as its entrypoint 4. the verifier starts a synthetic backend, launches Traefik, runs the HTTPS/HTTP/1.1 control case, then runs the HTTP/3 exploit case Run:
./run.sh
`run.sh` defaults to the validated commit above. To override it explicitly:
PRODUCT_COMMIT=f2d0794417e4d06343e6e7c4722143f5b34bee45 ./run.sh
Expected terminal result:
REPRODUCED: HTTP/1.1 isolates the authenticated backend connection, but HTTP/3 reuses the victim-authenticated backend connection for a different client and executes an unauthorized state-changing request as the victim.
Important observed behavior from the PoC: - the HTTP/1.1 control case succeeds only if a fresh attacker connection receives `401` - the HTTP/3 exploit case succeeds only if the attacker reads victim-only data without sending `Authorization` - the HTTP/3 exploit case succeeds only if the attacker performs `/transfer?to=attacker&amount=5000` as `actor=victim` - the HTTP/3 exploit case succeeds only if the attacker uses the same backend TCP connection identifier as the victim Environment notes: - Docker is required - the build fetches the target Traefik source from GitHub - no production credentials or external NTLM service are required; the verifier includes a synthetic NTLM-like backend specifically to demonstrate connection-bound identity reuse ### Impact This is a cross-client authorization bypass affecting deployments that expose HTTP/3 routes to backends using connection-bound NTLM or Negotiate authentication with persistent backend connection reuse. In the verified reproduction, an unauthenticated second client can: - read victim-only data - perform a state-changing action as the victim - reuse a backend TCP connection that has already been authenticated as the victim Attack prerequisites: - HTTP/3 enabled on the Traefik entrypoint - a routed backend using connection-bound NTLM or Negotiate authentication - backend keep-alive and backend connection reuse enabled - the attacker can reach the same route as the victim Deployments using ordinary per-request authentication are not affected by this specific issue.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.7.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.11.0"
            },
            {
              "fixed": "2.11.57"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88007"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T23:04:06Z",
    "nvd_published_at": "2026-09-10T15:17:56Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nTraefik\u0027s HTTP/3 request path did not initialize the connection-scoped backend transport holder that isolates connection-bound NTLM and Negotiate (Kerberos) authentication on the HTTP/1.1 and HTTP/2 paths. The HTTP/3 entrypoint reuses the HTTPS handler chain and reaches the same backend round-tripper, but its `ConnContext` never called `service.AddTransportOnContext`, so `kerberosRoundTripper` fell back to the shared backend transport instead of a per-frontend-connection pool. On a route served over HTTP/3 to a backend that binds identity to a persistent connection via NTLM or Negotiate, an unrelated HTTP/3 client could be assigned a backend connection already authenticated as a victim and inherit that identity, reading victim-only data and performing actions as the victim without presenting the victim\u0027s credentials. Affected deployments require HTTP/3 enabled on the entrypoint, a backend using connection-bound NTLM/Negotiate authentication, and backend keep-alive; deployments using ordinary per-request authentication are not affected.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.57\n- https://github.com/traefik/traefik/releases/tag/v3.7.13\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n## Traefik HTTP/3 Backend NTLM Connection Reuse\n\n### Summary\nTraefik\u0027s HTTP/3 request path does not initialize the connection-scoped backend transport state that Traefik uses to isolate connection-bound NTLM and Negotiate authentication for HTTP/1.1 and HTTP/2. When a backend keeps authenticated identity on a persistent HTTP/1.1 TCP connection, an unrelated HTTP/3 client can reuse a victim-authenticated backend connection and inherit that backend identity.\n\nIn the attached reproduction, the HTTPS/HTTP/1.1 control case behaves correctly and isolates the attacker, but the HTTP/3 case allows a second unauthenticated client to read victim-only data and execute a state-changing request as `actor=victim`.\n\nValidated target:\n- Repository: `traefik/traefik`\n- Commit: `f2d0794417e4d06343e6e7c4722143f5b34bee45`\n- Validation time: `2026-08-25T06:48:02Z`\n- Commit time: `2026-08-24T08:26:06Z`\n- Patched status: not evaluated\n\n### Details\nThe issue is caused by a protocol-parity gap between the normal TCP HTTP entrypoint path and the HTTP/3 entrypoint path.\n\nFor HTTP/1.1 and HTTP/2, Traefik explicitly creates a connection-scoped holder that can later store a dedicated RoundTripper for NTLM or Negotiate:\n\n```go\n// pkg/server/server_entrypoint_tcp.go:691-703\nvar connContext multipleConnContext\nconnContext.AddConnContextFunc(func(ctx context.Context, c net.Conn) context.Context {\n\t// This adds an empty struct in order to store a RoundTripper in the ConnContext in case of Kerberos or NTLM.\n\tctx = service.AddTransportOnContext(ctx)\n\n\tif tlsConn, ok := c.(*tls.Conn); ok {\n\t\tif tlsConnWithOptionsName, ok := tlsConn.NetConn().(tcp.TLSConn); ok {\n\t\t\treturn tcp.AddTLSOptionsNameInContext(ctx, tlsConnWithOptionsName.TLSOptionsName)\n\t\t}\n\t}\n\n\treturn ctx\n})\n```\n\nThat helper installs the per-connection holder, and `kerberosRoundTripper` depends on it. If the holder is absent, it falls back to the shared original backend transport. If NTLM or Negotiate is detected, it stores a dedicated cloned RoundTripper into that holder so future requests stay on the authenticated backend connection:\n\n```go\n// pkg/server/service/transport.go:374-402\nfunc AddTransportOnContext(ctx context.Context) context.Context {\n\treturn context.WithValue(ctx, transportKey, \u0026stickyRoundTripper{})\n}\n\ntype kerberosRoundTripper struct {\n\tnew                  func() http.RoundTripper\n\tOriginalRoundTripper http.RoundTripper\n}\n\nfunc (k *kerberosRoundTripper) RoundTrip(request *http.Request) (*http.Response, error) {\n\tvalue, ok := request.Context().Value(transportKey).(*stickyRoundTripper)\n\tif !ok {\n\t\treturn k.OriginalRoundTripper.RoundTrip(request)\n\t}\n\n\tif value.RoundTripper != nil {\n\t\treturn value.RoundTripper.RoundTrip(request)\n\t}\n\n\tresp, err := k.OriginalRoundTripper.RoundTrip(request)\n\n\t// If we found that we are authenticating with Kerberos (Negotiate) or NTLM.\n\t// We put a dedicated roundTripper in the ConnContext.\n\t// This will stick the next calls to the same connection with the backend.\n\tif err == nil \u0026\u0026 containsNTLMorNegotiate(resp.Header.Values(\"WWW-Authenticate\")) {\n\t\tvalue.RoundTripper = k.new()\n\t}\n\treturn resp, err\n}\n```\n\nFor HTTP/3, the server reuses the normal HTTPS handler chain, but its `ConnContext` only propagates the TLS options name and does not call `service.AddTransportOnContext`:\n\n```go\n// pkg/server/server_entrypoint_tcp_http3.go:65-80\nh3.Server = \u0026http3.Server{\n\tAddr:      config.GetAddress(),\n\tPort:      config.HTTP3.AdvertisedPort,\n\tHandler:   httpsServer.Server.(*http.Server).Handler,\n\tTLSConfig: \u0026tls.Config{GetConfigForClient: h3.getTLSConfigForClient},\n\tQUICConfig: \u0026quic.Config{\n\t\tAllow0RTT: false,\n\t},\n\tConnContext: func(ctx context.Context, c *quic.Conn) context.Context {\n\t\ttlsOptionsName, err := h3.getTLSOptionsName(c)\n\t\tif err != nil {\n\t\t\tlog.Error().Msgf(\"Error getting TLS options name for client: %v\", err)\n\t\t\treturn ctx\n\t\t}\n\t\treturn tcp.AddTLSOptionsNameInContext(ctx, tlsOptionsName)\n\t},\n}\n```\n\nThis means HTTP/3 requests reach the same reverse-proxy and backend transport logic as HTTPS, but without the connection-scoped transport holder that NTLM and Negotiate isolation relies on.\n\nIn practice, the flow is:\n1. A victim authenticates through Traefik to a backend that binds identity to the backend TCP connection using NTLM or Negotiate.\n2. Because the HTTP/3 request context does not contain `transportKey`, `kerberosRoundTripper` uses the shared `OriginalRoundTripper`.\n3. No frontend-connection-specific dedicated backend pool is installed for that HTTP/3 client.\n4. A second unrelated HTTP/3 client can be assigned the same backend TCP connection after the victim has authenticated it.\n5. That second client inherits the victim\u0027s backend identity without sending the victim\u0027s credentials.\n\nThe attached verifier demonstrates both the negative control and the exploit path:\n- HTTPS/HTTP/1.1 control case: the attacker uses a separate frontend connection and correctly receives `401`\n- HTTP/3 exploit case: the attacker uses a separate HTTP/3 client with no `Authorization` header, reads `resource=secret actor=victim`, executes `action=transfer actor=victim to=attacker amount=5000`, and hits the same backend TCP connection identifier as the victim\n\n### PoC\n\nSee the reproduction materials at:\nhttps://gist.github.com/OneZ3r0/41da8e8b79ebbe444a94f8a2a3a30895\n\nThe gist can also be downloaded as a ZIP archive.\n\nFiles included in this gist:\n- `run.sh`\n- `Dockerfile`\n- `.dockerignore`\n- `go.mod`\n- `go.sum`\n- `verify.go`\n\nThe package is intentionally kept as a single-container reproduction:\n1. `run.sh` builds a local image for the pinned target commit\n2. the Dockerfile builds both Traefik and the verifier during image build\n3. the container runs the verifier directly as its entrypoint\n4. the verifier starts a synthetic backend, launches Traefik, runs the HTTPS/HTTP/1.1 control case, then runs the HTTP/3 exploit case\n\nRun:\n\n```bash\n./run.sh\n```\n\n`run.sh` defaults to the validated commit above. To override it explicitly:\n\n```bash\nPRODUCT_COMMIT=f2d0794417e4d06343e6e7c4722143f5b34bee45 ./run.sh\n```\n\nExpected terminal result:\n\n```text\nREPRODUCED: HTTP/1.1 isolates the authenticated backend connection, but HTTP/3 reuses the victim-authenticated backend connection for a different client and executes an unauthorized state-changing request as the victim.\n```\n\nImportant observed behavior from the PoC:\n- the HTTP/1.1 control case succeeds only if a fresh attacker connection receives `401`\n- the HTTP/3 exploit case succeeds only if the attacker reads victim-only data without sending `Authorization`\n- the HTTP/3 exploit case succeeds only if the attacker performs `/transfer?to=attacker\u0026amount=5000` as `actor=victim`\n- the HTTP/3 exploit case succeeds only if the attacker uses the same backend TCP connection identifier as the victim\n\nEnvironment notes:\n- Docker is required\n- the build fetches the target Traefik source from GitHub\n- no production credentials or external NTLM service are required; the verifier includes a synthetic NTLM-like backend specifically to demonstrate connection-bound identity reuse\n\n### Impact\nThis is a cross-client authorization bypass affecting deployments that expose HTTP/3 routes to backends using connection-bound NTLM or Negotiate authentication with persistent backend connection reuse.\n\nIn the verified reproduction, an unauthenticated second client can:\n- read victim-only data\n- perform a state-changing action as the victim\n- reuse a backend TCP connection that has already been authenticated as the victim\n\nAttack prerequisites:\n- HTTP/3 enabled on the Traefik entrypoint\n- a routed backend using connection-bound NTLM or Negotiate authentication\n- backend keep-alive and backend connection reuse enabled\n- the attacker can reach the same route as the victim\n\nDeployments using ordinary per-request authentication are not affected by this specific issue.\n\n\u003c/details\u003e\n---",
  "id": "GHSA-qqjf-53cj-pwvv",
  "modified": "2026-09-10T23:04:06Z",
  "published": "2026-09-10T23:04:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-qqjf-53cj-pwvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88007"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/pull/13812"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/ff39c47d7459dec9cd8de63c1a4e7aa7315bdc1c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.57"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik HTTP/3 Backend NTLM Connection Reuse"
}

GHSA-QQMV-5P3G-PX89

Vulnerability from github – Published: 2026-04-04 06:11 – Updated: 2026-04-07 14:20
VLAI
Summary
Directus: TUS Upload Authorization Bypass Allows Arbitrary File Overwrite
Details

Summary

Directus' TUS resumable upload endpoint (/files/tus) allows any authenticated user with basic file upload permissions to overwrite arbitrary existing files by UUID. The TUS controller performs only collection-level authorization checks, verifying the user has some permission on directus_files, but never validates item-level access to the specific file being replaced. As a result, row-level permission rules (e.g., "users can only update their own files") are completely bypassed via the TUS path while being correctly enforced on the standard REST upload path.

Impact

  • Arbitrary file overwrite: Any authenticated user with basic TUS upload permissions can overwrite any file in directus_files by UUID, regardless of row-level permission rules.
  • Permanent data loss: The victim file's original stored bytes are deleted from storage and replaced with attacker-controlled content.
  • Metadata corruption: The victim file's database record is updated with the attacker's filename, type, and size metadata. Privilege escalation potential: If admin-owned files (e.g., application assets, templates) are stored in directus_files, a low-privilege user could replace them with malicious content.

Workaround

Disable TUS uploads by setting TUS_ENABLED=false if resumable uploads are not required.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.16.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35412"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-04T06:11:18Z",
    "nvd_published_at": "2026-04-06T22:16:22Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nDirectus\u0027 TUS resumable upload endpoint (`/files/tus`) allows any authenticated user with basic file upload permissions to overwrite arbitrary existing files by UUID. The TUS controller performs only collection-level authorization checks, verifying the user has some permission on `directus_files`, but never validates item-level access to the specific file being replaced. As a result, row-level permission rules (e.g., \"users can only update their own files\") are completely bypassed via the TUS path while being correctly enforced on the standard REST upload path.\n\n## Impact\n\n- **Arbitrary file overwrite:** Any authenticated user with basic TUS upload permissions can overwrite any file in `directus_files` by UUID, regardless of row-level permission rules.\n- **Permanent data loss:** The victim file\u0027s original stored bytes are deleted from storage and replaced with attacker-controlled content.\n- **Metadata corruption:** The victim file\u0027s database record is updated with the attacker\u0027s filename, type, and size metadata.\nPrivilege escalation potential: If admin-owned files (e.g., application assets, templates) are stored in `directus_files`, a low-privilege user could replace them with malicious content.\n\n## Workaround\n\nDisable TUS uploads by setting `TUS_ENABLED=false` if resumable uploads are not required.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-qqmv-5p3g-px89",
  "modified": "2026-04-07T14:20:12Z",
  "published": "2026-04-04T06:11:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-qqmv-5p3g-px89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35412"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus: TUS Upload Authorization Bypass Allows Arbitrary File Overwrite"
}

GHSA-QR3P-6238-2P49

Vulnerability from github – Published: 2026-08-24 12:31 – Updated: 2026-08-24 12:31
VLAI
Details

Firmware in KAON PG5298A and PG5298B routers allow an authenticated user to send crafted JSON-RPC requests and perform operations not possible via GUI, e.g. system file read or command execution.    This vulnerability has been fixed in firmware version: 3.0.82 for PG5298A and 4.0.82 for PG5298B.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-63080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T12:16:47Z",
    "severity": "HIGH"
  },
  "details": "Firmware in KAON PG5298A and PG5298B routers allow an authenticated user to send crafted JSON-RPC requests and perform operations not possible via GUI, e.g. system file read or command execution.\u00a0\u00a0\u00a0\nThis vulnerability has been fixed in firmware version: 3.0.82 for PG5298A and 4.0.82 for PG5298B.",
  "id": "GHSA-qr3p-6238-2p49",
  "modified": "2026-08-24T12:31:38Z",
  "published": "2026-08-24T12:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63080"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/08/CVE-2025-63080"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/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-QR5P-M4C8-89VQ

Vulnerability from github – Published: 2024-08-19 18:32 – Updated: 2024-08-19 18:32
VLAI
Details

Incorrect Authorization vulnerability in Bit Apps Bit Form Pro bitformpro allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Bit Form Pro: from n/a through 2.6.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-19T18:15:11Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization vulnerability in Bit Apps Bit Form Pro bitformpro allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Bit Form Pro: from n/a through 2.6.4.",
  "id": "GHSA-qr5p-m4c8-89vq",
  "modified": "2024-08-19T18:32:09Z",
  "published": "2024-08-19T18:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43250"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/bitformpro/wordpress-bit-form-pro-plugin-2-6-4-authenticated-plugin-settings-change-vulnerability?_s_id=cve"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QR6C-GP8P-XCWH

Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-12-03 18:31
VLAI
Details

The python_food ordering system V1.0 has an unauthorized vulnerability that leads to the leakage of sensitive user information. Attackers can access it through https://ip:port/api/myapp/index/user/info?id=1 And modify the ID value to obtain sensitive user information beyond authorization.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-15T16:15:36Z",
    "severity": "HIGH"
  },
  "details": "The python_food ordering system V1.0 has an unauthorized vulnerability that leads to the leakage of sensitive user information. Attackers can access it through https://ip:port/api/myapp/index/user/info?id=1 And modify the ID value to obtain sensitive user information beyond authorization.",
  "id": "GHSA-qr6c-gp8p-xcwh",
  "modified": "2024-12-03T18:31:02Z",
  "published": "2024-11-15T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yllxx03/CVE/blob/main/python_food_Information_Disclosure.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yllxx03/CVE/tree/main/CVE-2024-50647"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QR8F-CJW7-838M

Vulnerability from github – Published: 2024-02-09 15:31 – Updated: 2024-11-18 16:26
VLAI
Summary
Mattermost Jira Plugin does not properly check security levels
Details

Mattermost Jira Plugin handling subscriptions fails to check the security level of an incoming issue or limit it based on the user who created the subscription resulting in registered users on Jira being able to create webhooks that give them access to all Jira issues.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-plugin-jira"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0-rc1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-24774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-09T18:18:58Z",
    "nvd_published_at": "2024-02-09T15:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost Jira Plugin handling subscriptions fails to check the security level of an incoming issue or limit it based on the user who created the subscription resulting in\u00a0registered users on Jira being able to create webhooks that give them access to all Jira issues.\n\n",
  "id": "GHSA-qr8f-cjw7-838m",
  "modified": "2024-11-18T16:26:36Z",
  "published": "2024-02-09T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost-plugin-jira/commit/5f5e084d169bf6b82d5c46a7a7eb033e1a01c6de"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "PACKAGE",
      "url": "mattermost/mattermost-plugin-jira"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Mattermost Jira Plugin does not properly check security levels"
}

GHSA-QR93-8WWF-22G4

Vulnerability from github – Published: 2025-07-30 16:34 – Updated: 2025-07-31 11:18
VLAI
Summary
GitProxy Approval Bypass When Pushing Multiple Branches
Details

Summary

This vulnerability allows a user to push to the remote repository while bypassing policies and explicit approval. Since checks and plugins are skipped, code containing secrets or unwanted changes could be pushed into a repository.

Because it can allow policy violations to go undetected, we classify this as a High impact vulnerability.

Details

The source of the vulnerability is the push parser action parsePush.ts. It reads the first branch and parses it, while ignoring subsequent branches (silently letting them go through).

Although the fix involves multiple improvements to the commit and push parsing logic, the core solution is to prevent multiple branch pushes from going through in the first place:

if (refUpdates.length !== 1) {
  step.log('Invalid number of branch updates.');
  step.log(`Expected 1, but got ${refUpdates.length}`);
  step.setError('Your push has been blocked. Please make sure you are pushing to a single branch.');
  action.addStep(step);
  return action;
}

PoC

  1. Make a commit on a branch:
git checkout -b safe-branch
echo "Approved code" > file.txt
git add .
git commit -m "Approved code"
git push proxy safe-branch
  1. Wait for approval of safe-branch.

  2. Make a commit on a separate branch with a secret, for example:

git checkout -b bad-branch
echo "SECRET=abc123" > .env
git add .
git commit -m "Bad code"
  1. Push both at the same time:

git push proxy safe-branch bad-branch

Expected Result

Ideally, this would force checks to run for the second branch while sending it out for approval. Meanwhile, the first branch would be pushed to the remote. A simpler solution is to simply prevent multiple branch pushes.

Actual Result

Both branches get pushed to the remote, and second branch bypasses the proxy.

Impact

Attackers with push access can bypass review policies, potentially inserting unwanted/malicious code into a GitProxy-protected repository.

The vulnerability impacts all users or organizations relying on GitProxy to enforce policies and prevent unapproved changes. It requires no elevated privileges beyond regular push access, and no extra user interaction. It does however, require a GitProxy administrator or designated user (canUserApproveRejectPush) to approve the first push. It is much more likely that a well-meaning user would trigger this accidentally.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.19.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@finos/git-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54583"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-30T16:34:50Z",
    "nvd_published_at": "2025-07-30T20:15:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThis vulnerability allows a user to push to the remote repository while bypassing policies and explicit approval. Since checks and plugins are skipped, code containing secrets or unwanted changes could be pushed into a repository.\n\nBecause it can allow policy violations to go undetected, we classify this as a High impact vulnerability.\n\n### Details\nThe source of the vulnerability is the push parser action `parsePush.ts`. It reads the first branch and parses it, while ignoring subsequent branches (silently letting them go through).\n\nAlthough the fix involves multiple improvements to the commit and push parsing logic, the core solution is to prevent multiple branch pushes from going through in the first place:\n\n```ts\nif (refUpdates.length !== 1) {\n  step.log(\u0027Invalid number of branch updates.\u0027);\n  step.log(`Expected 1, but got ${refUpdates.length}`);\n  step.setError(\u0027Your push has been blocked. Please make sure you are pushing to a single branch.\u0027);\n  action.addStep(step);\n  return action;\n}\n```\n\n### PoC\n\n1. Make a commit on a branch:\n\n```bash\ngit checkout -b safe-branch\necho \"Approved code\" \u003e file.txt\ngit add .\ngit commit -m \"Approved code\"\ngit push proxy safe-branch\n```\n\n2. Wait for approval of `safe-branch`.\n\n3. Make a commit on a separate branch with a secret, for example:\n\n```bash\ngit checkout -b bad-branch\necho \"SECRET=abc123\" \u003e .env\ngit add .\ngit commit -m \"Bad code\"\n```\n\n4. Push both at the same time:\n\n`git push proxy safe-branch bad-branch`\n\n#### Expected Result\nIdeally, this would force checks to run for the second branch while sending it out for approval. Meanwhile, the first branch would be pushed to the remote. A simpler solution is to simply prevent multiple branch pushes.\n\n#### Actual Result\nBoth branches get pushed to the remote, and second branch bypasses the proxy.\n\n### Impact\nAttackers with push access can bypass review policies, potentially inserting unwanted/malicious code into a GitProxy-protected repository.\n\nThe vulnerability impacts all users or organizations relying on GitProxy to enforce policies and prevent unapproved changes. It requires no elevated privileges beyond regular push access, and no extra user interaction. It does however, require a GitProxy administrator or designated user (`canUserApproveRejectPush`) to approve the first push. It is much more likely that a well-meaning user would trigger this accidentally.",
  "id": "GHSA-qr93-8wwf-22g4",
  "modified": "2025-07-31T11:18:36Z",
  "published": "2025-07-30T16:34:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/finos/git-proxy/security/advisories/GHSA-qr93-8wwf-22g4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54583"
    },
    {
      "type": "WEB",
      "url": "https://github.com/finos/git-proxy/commit/a620a2f33c39c78e01783a274580bf822af3cc3a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/finos/git-proxy/commit/bd2ecb2099cba21bca3941ee4d655d2eb887b3a9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/finos/git-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/finos/git-proxy/releases/tag/v1.19.2"
    }
  ],
  "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:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GitProxy Approval Bypass When Pushing Multiple Branches"
}

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.