Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6877 vulnerabilities reference this CWE, most recent first.

GHSA-QQJ6-F5MM-G546

Vulnerability from github – Published: 2022-05-14 01:56 – Updated: 2022-05-14 01:56
VLAI
Details

** DISPUTED ** An issue was discovered in the org.telegram.messenger application 4.8.11 for Android. The Passcode feature allows authentication bypass via runtime manipulation that forces a certain method's return value to true. In other words, an attacker could authenticate with an arbitrary passcode. NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes Android devices on which rooting has occurred.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-15542"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-09T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "** DISPUTED ** An issue was discovered in the org.telegram.messenger application 4.8.11 for Android. The Passcode feature allows authentication bypass via runtime manipulation that forces a certain method\u0027s return value to true. In other words, an attacker could authenticate with an arbitrary passcode.  NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes Android devices on which rooting has occurred.",
  "id": "GHSA-qqj6-f5mm-g546",
  "modified": "2022-05-14T01:56:36Z",
  "published": "2022-05-14T01:56:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15542"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/tanprathan/18d0f692a2485acfb5693e2f6dabeb5d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "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-QQQV-WFVC-WRGW

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

A limited authentication bypass vulnerability was discovered that could allow an attacker to achieve remote code execution and escalate privileges on the My Cloud devices. Addressed this vulnerability by changing access token validation logic and rewriting rule logic on PHP scripts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-22990"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-697"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-13T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A limited authentication bypass vulnerability was discovered that could allow an attacker to achieve remote code execution and escalate privileges on the My Cloud devices. Addressed this vulnerability by changing access token validation logic and rewriting rule logic on PHP scripts.",
  "id": "GHSA-qqqv-wfvc-wrgw",
  "modified": "2022-03-18T00:01:43Z",
  "published": "2022-01-14T00:01:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22990"
    },
    {
      "type": "WEB",
      "url": "https://www.westerndigital.com/support/product-security/wdc-22002-my-cloud-os5-firmware-5-19-117"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-076"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-347"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QQV4-HJ7R-XR74

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

FileDownload.jsp in ManageEngine ServiceDesk Plus 8.0 before Build 8012 does not require authentication, which allows remote attackers to read files from a specific directory via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-2756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-07-17T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "FileDownload.jsp in ManageEngine ServiceDesk Plus 8.0 before Build 8012 does not require authentication, which allows remote attackers to read files from a specific directory via unspecified vectors.",
  "id": "GHSA-qqv4-hj7r-xr74",
  "modified": "2022-05-17T05:40:16Z",
  "published": "2022-05-17T05:40:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-2756"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/543310"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QQWF-PRW2-CF87

Vulnerability from github – Published: 2022-05-17 01:33 – Updated: 2022-05-17 01:33
VLAI
Details

Session fixation vulnerability in IBM Cognos Command Center before 10.2 allows remote attackers to hijack web sessions via an authorization cookie.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-4001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-12-14T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Session fixation vulnerability in IBM Cognos Command Center before 10.2 allows remote attackers to hijack web sessions via an authorization cookie.",
  "id": "GHSA-qqwf-prw2-cf87",
  "modified": "2022-05-17T01:33:53Z",
  "published": "2022-05-17T01:33:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4001"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/85151"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21657932"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QR32-FCM4-M5H9

Vulnerability from github – Published: 2025-02-18 15:31 – Updated: 2025-02-19 15:32
VLAI
Details

A vulnerability in the TP-Link Archer c20 router with firmware version V6.6_230412 and earlier permits unauthorized individuals to bypass the authentication of some interfaces under the /cgi directory. When adding Referer: http://tplinkwifi.net to the the request, it will be recognized as passing the authentication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-57049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-18T15:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the TP-Link Archer c20 router with firmware version V6.6_230412 and earlier permits unauthorized individuals to bypass the authentication of some interfaces under the /cgi directory. When adding Referer: http://tplinkwifi.net to the the request, it will be recognized as passing the authentication.",
  "id": "GHSA-qr32-fcm4-m5h9",
  "modified": "2025-02-19T15:32:11Z",
  "published": "2025-02-18T15:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57049"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Shuanunio/CVE_Requests/blob/main/TP-Link/archer%20c20/ACL%20bypass%20Vulnerability%20in%20TP-Link%20archer%20c20.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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QR63-7PPG-Q2F9

Vulnerability from github – Published: 2026-06-01 21:30 – Updated: 2026-06-01 21:30
VLAI
Details

A vulnerability was identified in code-projects Hotel and Tourism Reservation System 1.0. This issue affects the function password_verify of the file /admin/login.php of the component Admin Login. Such manipulation of the argument Password leads to improper authentication. It is possible to launch the attack remotely. The exploit is publicly available and might be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-10288"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-01T21:16:25Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in code-projects Hotel and Tourism Reservation System 1.0. This issue affects the function password_verify of the file /admin/login.php of the component Admin Login. Such manipulation of the argument Password leads to improper authentication. It is possible to launch the attack remotely. The exploit is publicly available and might be used.",
  "id": "GHSA-qr63-7ppg-q2f9",
  "modified": "2026-06-01T21:30:44Z",
  "published": "2026-06-01T21:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10288"
    },
    {
      "type": "WEB",
      "url": "https://code-projects.org"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Xmyronn/Hotel-and-Tourism-Reservation-System---Authentication-Bypass.git"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-10288"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/825786"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367581"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367581/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-QR8C-F5QW-7CRQ

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

ABB eSOMS version 6.0.2 may allow unauthorized access to the system when LDAP is set to allow anonymous authentication, and specific key values within the eSOMS web.config file are present. Both conditions are required to exploit this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-14805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-29T16:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "ABB eSOMS version 6.0.2 may allow unauthorized access to the system when LDAP is set to allow anonymous authentication, and specific key values within the eSOMS web.config file are present. Both conditions are required to exploit this vulnerability.",
  "id": "GHSA-qr8c-f5qw-7crq",
  "modified": "2022-05-13T01:34:27Z",
  "published": "2022-05-13T01:34:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14805"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-240-04"
    },
    {
      "type": "WEB",
      "url": "https://search.abb.com/library/Download.aspx?DocumentID=9AKK107046A5821\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105169"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QR9C-FQFX-66CW

Vulnerability from github – Published: 2022-05-01 23:36 – Updated: 2025-04-09 03:55
VLAI
Details

The management interface in Akamai Client (formerly Red Swoosh) 3322 and earlier allows remote attackers to bypass authentication via an HTTP request that contains (1) no Referer header, or (2) a spoofed Referer header that matches an approved domain, which allows remote attackers to conduct cross-site request forgery (CSRF) attacks and force the client to download and execute arbitrary files.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2008-1106"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-06-09T23:32:00Z",
    "severity": "HIGH"
  },
  "details": "The management interface in Akamai Client (formerly Red Swoosh) 3322 and earlier allows remote attackers to bypass authentication via an HTTP request that contains (1) no Referer header, or (2) a spoofed Referer header that matches an approved domain, which allows remote attackers to conduct cross-site request forgery (CSRF) attacks and force the client to download and execute arbitrary files.",
  "id": "GHSA-qr9c-fqfx-66cw",
  "modified": "2025-04-09T03:55:17Z",
  "published": "2022-05-01T23:36:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1106"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42895"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30135"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/secunia_research/2008-19/advisory"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/3930"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/493169/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/493170/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1020208"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/1761/references"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QRW2-P44V-4F43

Vulnerability from github – Published: 2026-03-20 09:32 – Updated: 2026-03-20 09:32
VLAI
Details

A vulnerability was found in Yi Technology YI Home Camera 2 2.1.1_20171024151200. The impacted element is an unknown function of the file home/web/ipc of the component CGI Endpoint. Performing a manipulation results in missing authentication. Access to the local network is required for this attack. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-20T07:16:14Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Yi Technology YI Home Camera 2 2.1.1_20171024151200. The impacted element is an unknown function of the file home/web/ipc of the component CGI Endpoint. Performing a manipulation results in missing authentication. Access to the local network is required for this attack. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-qrw2-p44v-4f43",
  "modified": "2026-03-20T09:32:09Z",
  "published": "2026-03-20T09:32:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4476"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.351766"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.351766"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.773070"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.