Vulnerability-Lookup

GHSA-4MR2-FG2P-W63C

Vulnerability from github – Published: 2026-06-19 21:15 – Updated: 2026-07-20 21:13

Summary

Traefik Kubernetes Ingress NGINX provider fails open when auth-secret resolution fails

Details

Summary

There is a medium severity vulnerability in Traefik's Kubernetes Ingress NGINX provider that causes affected routes to fail open. When an Ingress explicitly enables BasicAuth or DigestAuth through the supported nginx.ingress.kubernetes.io/auth-type and auth-secret annotations, but the referenced auth Secret cannot be resolved or parsed, Traefik logs the resolution error, skips installing the authentication middleware, and still emits a router to the backend service. A route that operators intended to protect is therefore published to the data plane without its authentication control, allowing unauthenticated access to the backend. The trigger is an invalid or unresolved auth dependency — a missing, malformed, unreadable, or policy-denied Secret — rather than an intentionally unprotected route.

Patches

https://github.com/traefik/traefik/releases/tag/v3.7.5

For more information

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

Original Description ### Summary Traefik's Kubernetes Ingress NGINX provider can fail open for routes that explicitly configure BasicAuth or DigestAuth through supported ingress-nginx annotations. When an Ingress contains `nginx.ingress.kubernetes.io/auth-type: basic` or `digest`, but the referenced `nginx.ingress.kubernetes.io/auth-secret` cannot be resolved or parsed, Traefik logs the auth resolution error, skips installing the BasicAuth/DigestAuth middleware, and still emits a router to the backend service. This can expose a route that operators intended to protect. The issue is not that an invalid Secret exists; the issue is that an explicitly auth-protected Ingress location is translated into a live backend route where the authentication control is removed from the generated data-plane configuration, with only a controller log entry, instead of failing closed. Tested affected versions: - Current `master`: `29406d42898547f1ffabd904f66af06c212740cf` - Latest tag tested by me: `v3.7.1` / `fa49e2bcad7ffd8a80accdf1fae1ae480913d93d` The KubernetesIngressNGINX provider is documented as no longer experimental as of v3.6.2, and the `auth-type`, `auth-secret`, `auth-secret-type`, and `auth-realm` annotations are documented supported annotations. ### Details The root cause is in `pkg/provider/kubernetes/ingress-nginx/build.go`. During provider translation, auth is pre-resolved for each location:

if ing.config.AuthType != nil {
    basic, digest, err := p.resolveBasicAuth(ing.Namespace, ing.config)
    if err != nil {
        logger.Error().
            Err(err).
            Str("ingress", fmt.Sprintf("%s/%s rule-%d path-%d", ing.Namespace, ing.Name, ri, pi)).
            Msg("Cannot resolve auth secret, skipping auth middleware")
    } else {
        loc.BasicAuth = basic
        loc.DigestAuth = digest
    }
}

The error is logged, but `loc.Error` is not set. Later, `pkg/provider/kubernetes/ingress-nginx/translator.go` only routes to `unavailable-service` when `loc.Error` is true. Since this auth error leaves `loc.Error` false, the generated router continues to use the real backend service, and `applyMiddlewares` has no BasicAuth/DigestAuth middleware to attach. This differs from nearby fail-closed behavior for comparable provider translation failures: - `auth-tls-secret` resolution failure skips the affected ingress. - `custom-headers` ConfigMap resolution failure sets `loc.Error = true`, causing the translator to avoid normal backend exposure. Security invariant: > If an Ingress location explicitly configures BasicAuth/DigestAuth, Traefik should not forward that location to the backend unless the corresponding auth middleware is installed. Reasonable fail-closed behaviors would include omitting the router, routing it to `unavailable-service`, returning 503, or attaching a deny-all middleware until the auth dependency is valid. ### Expected behavior An Ingress location with explicit `auth-type: basic` or `auth-type: digest` must not forward requests to the backend unless the generated Traefik router has the corresponding BasicAuth/DigestAuth middleware attached. If the referenced auth Secret is missing, malformed, unreadable, denied by namespace policy, or otherwise unusable, Traefik should fail closed for that location. ### Actual behavior When `auth-secret` resolution fails, Traefik still creates a router to the backend service and only omits the BasicAuth/DigestAuth middleware. The only indication is a controller log entry:

Cannot resolve auth secret, skipping auth middleware

### PoC I reproduced this with a clean fake Kubernetes provider state. The reproduction does not use Docker provider labels, dashboard/API routing, lab backends, or public network targets. Minimal Kubernetes objects: - `IngressClass` named `nginx` with controller `k8s.io/ingress-nginx` - `Service` named `whoami` in namespace `default` - `EndpointSlice` for the `whoami` service - `Ingress` with `ingressClassName: nginx`, a backend pointing to `whoami`, and these annotations:

nginx.ingress.kubernetes.io/auth-type: "basic"
nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
nginx.ingress.kubernetes.io/auth-secret: "default/missing-basic-auth"

The referenced Secret intentionally does not exist. The expected secure behavior is fail-closed for this auth-configured route. The observed behavior is a normal router to the backend without BasicAuth/DigestAuth. Key failing assertion from the regression harness:

router forwards to backend service without BasicAuth/DigestAuth when auth-secret is missing; middlewares=[default-auth-missing-secret-rule-0-path-0-retry] service="default-auth-missing-secret-whoami-80"

The same behavior reproduces on both current `master` and `v3.7.1`. I also tested a matrix of auth-secret resolution failures. In each error case, Traefik still emitted the backend router without BasicAuth/DigestAuth: - missing `auth-secret` - omitted/empty `auth-secret` - invalid `auth-secret-type` - `auth-file` Secret missing the required `auth` key - empty `auth-map` Secret - missing DigestAuth Secret - cross-namespace `auth-secret` denied by default policy The same matrix includes a positive control where a valid `auth-file` Secret correctly attaches BasicAuth, confirming that the harness is exercising the intended provider path. I also performed a clean-room revalidation from fresh `git archive` source trees for both source/master and v3.7.1. Only the two minimal test harnesses were copied into each archived source tree. This avoided contamination from lab compose files, Docker provider state, dashboard/API routes, prior source-tree test files, or running lab backends. ### Threat model This does not require an attacker to modify Traefik static configuration or Traefik process state. The relevant security boundary is the Kubernetes-declared route policy: an Ingress explicitly declares BasicAuth/DigestAuth, but Traefik publishes the data-plane route without that control when the auth dependency is invalid. In multi-tenant or GitOps-managed clusters, the actor or automation that can affect Secret existence, Secret contents, namespace policy, or deployment ordering is not necessarily the same actor that owns the protected backend or Traefik deployment. As a result, a mistake, rollback, pruning job, policy change, or compromise limited to Kubernetes application resources can remove the effective auth boundary while the Ingress continues to declare that auth is required. ### Impact This is a fail-open authentication control issue leading to unintended unauthenticated route exposure. The trigger is an invalid or unresolved auth dependency, but the security consequence is a data-plane route that violates explicit auth intent. This is materially different from intentionally deploying an unprotected route: the Ingress declares `auth-type: basic` or `digest`, yet Traefik publishes the backend without the corresponding auth middleware. Realistic scenarios include: - GitOps, Helm, or CI/CD deploys Ingress and Secret resources separately. Ordering issues, rollbacks, pruning, or typos can leave the Ingress active while the auth Secret is absent or unreadable. - Kubernetes RBAC commonly separates ownership of Ingress objects, Secrets, and namespace policies. A lower-privileged namespace actor or deployment automation may be able to affect the referenced Secret or cross-namespace reference outcome without having direct access to Traefik static configuration. - During ingress-nginx migration, operators reasonably expect supported `nginx.ingress.kubernetes.io/auth-*` annotations to preserve the authentication boundary. Publishing the backend without auth is a worse failure mode than rejecting the invalid location. - A transient Secret deletion, malformed Secret update, or policy change can turn an already protected route into an unprotected route without changing the Ingress rule itself. Controller logs are not a sufficient mitigation. Logs do not prevent exposure, may not page the service owner, and the first externally visible symptom can be unauthenticated access to the protected backend. ### Suggested remediation Fail closed on any `resolveBasicAuth` error. A minimal tested change is to mark the location as errored:

 if err != nil {
     logger.Error().
         Err(err).
         Str("ingress", fmt.Sprintf("%s/%s rule-%d path-%d", ing.Namespace, ing.Name, ri, pi)).
         Msg("Cannot resolve auth secret, skipping auth middleware")
+    loc.Error = true
 } else {

This reuses the existing `loc.Error` / `unavailable-service` path. In my local validation, this change made the no-backend-without-auth regression pass while preserving the valid-secret positive control.

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

5.9 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-ea.1"
            },
            {
              "fixed": "3.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54762"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:15:56Z",
    "nvd_published_at": "2026-06-23T20:16:49Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a medium severity vulnerability in Traefik\u0027s Kubernetes Ingress NGINX provider that causes affected routes to fail open. When an Ingress explicitly enables BasicAuth or DigestAuth through the supported `nginx.ingress.kubernetes.io/auth-type` and `auth-secret` annotations, but the referenced auth Secret cannot be resolved or parsed, Traefik logs the resolution error, skips installing the authentication middleware, and still emits a router to the backend service. A route that operators intended to protect is therefore published to the data plane without its authentication control, allowing unauthenticated access to the backend. The trigger is an invalid or unresolved auth dependency \u2014 a missing, malformed, unreadable, or policy-denied Secret \u2014 rather than an intentionally unprotected route.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.7.5\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### Summary\n\nTraefik\u0027s Kubernetes Ingress NGINX provider can fail open for routes that explicitly configure BasicAuth or DigestAuth through supported ingress-nginx annotations.\n\nWhen an Ingress contains `nginx.ingress.kubernetes.io/auth-type: basic` or `digest`, but the referenced `nginx.ingress.kubernetes.io/auth-secret` cannot be resolved or parsed, Traefik logs the auth resolution error, skips installing the BasicAuth/DigestAuth middleware, and still emits a router to the backend service.\n\nThis can expose a route that operators intended to protect. The issue is not that an invalid Secret exists; the issue is that an explicitly auth-protected Ingress location is translated into a live backend route where the authentication control is removed from the generated data-plane configuration, with only a controller log entry, instead of failing closed.\n\nTested affected versions:\n\n- Current `master`: `29406d42898547f1ffabd904f66af06c212740cf`\n- Latest tag tested by me: `v3.7.1` / `fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`\n\nThe KubernetesIngressNGINX provider is documented as no longer experimental as of v3.6.2, and the `auth-type`, `auth-secret`, `auth-secret-type`, and `auth-realm` annotations are documented supported annotations.\n\n### Details\n\nThe root cause is in `pkg/provider/kubernetes/ingress-nginx/build.go`. During provider translation, auth is pre-resolved for each location:\n\n```go\nif ing.config.AuthType != nil {\n    basic, digest, err := p.resolveBasicAuth(ing.Namespace, ing.config)\n    if err != nil {\n        logger.Error().\n            Err(err).\n            Str(\"ingress\", fmt.Sprintf(\"%s/%s rule-%d path-%d\", ing.Namespace, ing.Name, ri, pi)).\n            Msg(\"Cannot resolve auth secret, skipping auth middleware\")\n    } else {\n        loc.BasicAuth = basic\n        loc.DigestAuth = digest\n    }\n}\n```\n\nThe error is logged, but `loc.Error` is not set. Later, `pkg/provider/kubernetes/ingress-nginx/translator.go` only routes to `unavailable-service` when `loc.Error` is true. Since this auth error leaves `loc.Error` false, the generated router continues to use the real backend service, and `applyMiddlewares` has no BasicAuth/DigestAuth middleware to attach.\n\nThis differs from nearby fail-closed behavior for comparable provider translation failures:\n\n- `auth-tls-secret` resolution failure skips the affected ingress.\n- `custom-headers` ConfigMap resolution failure sets `loc.Error = true`, causing the translator to avoid normal backend exposure.\n\nSecurity invariant:\n\n\u003e If an Ingress location explicitly configures BasicAuth/DigestAuth, Traefik should not forward that location to the backend unless the corresponding auth middleware is installed.\n\nReasonable fail-closed behaviors would include omitting the router, routing it to `unavailable-service`, returning 503, or attaching a deny-all middleware until the auth dependency is valid.\n\n### Expected behavior\n\nAn Ingress location with explicit `auth-type: basic` or `auth-type: digest` must not forward requests to the backend unless the generated Traefik router has the corresponding BasicAuth/DigestAuth middleware attached.\n\nIf the referenced auth Secret is missing, malformed, unreadable, denied by namespace policy, or otherwise unusable, Traefik should fail closed for that location.\n\n### Actual behavior\n\nWhen `auth-secret` resolution fails, Traefik still creates a router to the backend service and only omits the BasicAuth/DigestAuth middleware. The only indication is a controller log entry:\n\n```text\nCannot resolve auth secret, skipping auth middleware\n```\n\n### PoC\n\nI reproduced this with a clean fake Kubernetes provider state. The reproduction does not use Docker provider labels, dashboard/API routing, lab backends, or public network targets.\n\nMinimal Kubernetes objects:\n\n- `IngressClass` named `nginx` with controller `k8s.io/ingress-nginx`\n- `Service` named `whoami` in namespace `default`\n- `EndpointSlice` for the `whoami` service\n- `Ingress` with `ingressClassName: nginx`, a backend pointing to `whoami`, and these annotations:\n\n```yaml\nnginx.ingress.kubernetes.io/auth-type: \"basic\"\nnginx.ingress.kubernetes.io/auth-secret-type: \"auth-file\"\nnginx.ingress.kubernetes.io/auth-secret: \"default/missing-basic-auth\"\n```\n\nThe referenced Secret intentionally does not exist. The expected secure behavior is fail-closed for this auth-configured route. The observed behavior is a normal router to the backend without BasicAuth/DigestAuth.\n\nKey failing assertion from the regression harness:\n\n```text\nrouter forwards to backend service without BasicAuth/DigestAuth when auth-secret is missing; middlewares=[default-auth-missing-secret-rule-0-path-0-retry] service=\"default-auth-missing-secret-whoami-80\"\n```\n\nThe same behavior reproduces on both current `master` and `v3.7.1`.\n\nI also tested a matrix of auth-secret resolution failures. In each error case, Traefik still emitted the backend router without BasicAuth/DigestAuth:\n\n- missing `auth-secret`\n- omitted/empty `auth-secret`\n- invalid `auth-secret-type`\n- `auth-file` Secret missing the required `auth` key\n- empty `auth-map` Secret\n- missing DigestAuth Secret\n- cross-namespace `auth-secret` denied by default policy\n\nThe same matrix includes a positive control where a valid `auth-file` Secret correctly attaches BasicAuth, confirming that the harness is exercising the intended provider path.\n\nI also performed a clean-room revalidation from fresh `git archive` source trees for both source/master and v3.7.1. Only the two minimal test harnesses were copied into each archived source tree. This avoided contamination from lab compose files, Docker provider state, dashboard/API routes, prior source-tree test files, or running lab backends.\n\n### Threat model\n\nThis does not require an attacker to modify Traefik static configuration or Traefik process state. The relevant security boundary is the Kubernetes-declared route policy: an Ingress explicitly declares BasicAuth/DigestAuth, but Traefik publishes the data-plane route without that control when the auth dependency is invalid.\n\nIn multi-tenant or GitOps-managed clusters, the actor or automation that can affect Secret existence, Secret contents, namespace policy, or deployment ordering is not necessarily the same actor that owns the protected backend or Traefik deployment. As a result, a mistake, rollback, pruning job, policy change, or compromise limited to Kubernetes application resources can remove the effective auth boundary while the Ingress continues to declare that auth is required.\n\n### Impact\n\nThis is a fail-open authentication control issue leading to unintended unauthenticated route exposure.\n\nThe trigger is an invalid or unresolved auth dependency, but the security consequence is a data-plane route that violates explicit auth intent. This is materially different from intentionally deploying an unprotected route: the Ingress declares `auth-type: basic` or `digest`, yet Traefik publishes the backend without the corresponding auth middleware.\n\nRealistic scenarios include:\n\n- GitOps, Helm, or CI/CD deploys Ingress and Secret resources separately. Ordering issues, rollbacks, pruning, or typos can leave the Ingress active while the auth Secret is absent or unreadable.\n- Kubernetes RBAC commonly separates ownership of Ingress objects, Secrets, and namespace policies. A lower-privileged namespace actor or deployment automation may be able to affect the referenced Secret or cross-namespace reference outcome without having direct access to Traefik static configuration.\n- During ingress-nginx migration, operators reasonably expect supported `nginx.ingress.kubernetes.io/auth-*` annotations to preserve the authentication boundary. Publishing the backend without auth is a worse failure mode than rejecting the invalid location.\n- A transient Secret deletion, malformed Secret update, or policy change can turn an already protected route into an unprotected route without changing the Ingress rule itself.\n\nController logs are not a sufficient mitigation. Logs do not prevent exposure, may not page the service owner, and the first externally visible symptom can be unauthenticated access to the protected backend.\n\n### Suggested remediation\n\nFail closed on any `resolveBasicAuth` error. A minimal tested change is to mark the location as errored:\n\n```diff\n if err != nil {\n     logger.Error().\n         Err(err).\n         Str(\"ingress\", fmt.Sprintf(\"%s/%s rule-%d path-%d\", ing.Namespace, ing.Name, ri, pi)).\n         Msg(\"Cannot resolve auth secret, skipping auth middleware\")\n+    loc.Error = true\n } else {\n```\n\nThis reuses the existing `loc.Error` / `unavailable-service` path. In my local validation, this change made the no-backend-without-auth regression pass while preserving the valid-secret positive control.\n\n\u003c/details\u003e\n\n---",
  "id": "GHSA-4mr2-fg2p-w63c",
  "modified": "2026-07-20T21:13:42Z",
  "published": "2026-06-19T21:15:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-4mr2-fg2p-w63c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54762"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik Kubernetes Ingress NGINX provider fails open when auth-secret resolution fails"
}

GHSA-6WRF-MXFJ-PF5P

Vulnerability from github – Published: 2023-04-04 21:11 – Updated: 2023-04-05 23:15

Summary

Docker Swarm encrypted overlay network with a single endpoint is unauthenticated

Details

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker.

Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.

The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.

Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.

When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.

The overlay driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.

Impact

Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.

Patches

Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.

Workarounds

In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For example, use the registry.k8s.io/pause image and a --mode global service.
For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in host mode instead of ingress mode (allowing the use of an external load balancer), and removing the ingress network.
If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec. For example, iptables -A INPUT -m udp —-dport 4789 -m policy --dir in --pol none -j DROP.

Background

This issue was discovered while characterizing and mitigating CVE-2023-28840 and CVE-2023-28841.

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "20.10.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-420",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-04T21:11:24Z",
    "nvd_published_at": "2023-04-04T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "[Moby](https://mobyproject.org/) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of [SwarmKit](https://github.com/moby/swarmkit) and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of [VXLAN](https://en.wikipedia.org/wiki/Virtual_Extensible_LAN), which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the [IPsec Encapsulating Security Payload](https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) protocol in [Transport mode](https://en.wikipedia.org/wiki/IPsec#Transport_mode). By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three [iptables](https://www.netfilter.org/projects/iptables/index.html) (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet\u0027s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nThe `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.\n\n## Impact\nEncrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and [GHSA-vwm3-crmr-xfxw](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw) should be referenced for a deeper exploration.\n\n## Patches\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime\u0027s 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\n## Workarounds\n* In multi-node clusters, deploy a global \u2018pause\u2019 container for each encrypted overlay network, on every node. For example, use the `registry.k8s.io/pause` image and a `--mode global` service.\n* For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features.\nThe Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network.\n* If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec. For example, `iptables -A INPUT -m udp \u2014-dport 4789 -m policy --dir in --pol none -j DROP`.\n\n## Background\n* This issue was discovered while characterizing and mitigating [CVE-2023-28840](https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp) and [CVE-2023-28841](https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237).\n\n## Related\n* [CVE-2023-28841: Encrypted overlay network traffic may be unencrypted](https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237)\n* [CVE-2023-28840: Encrypted overlay network may be unauthenticated](https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp)\n* [GHSA-vwm3-crmr-xfxw: The Swarm VXLAN port may be exposed to attack due to ambiguous documentation](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw)\n* [GHSA-gvm4-2qqg-m333: Security issues in encrypted overlay networks](https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333) (libnetwork)",
  "id": "GHSA-6wrf-mxfj-pf5p",
  "modified": "2023-04-05T23:15:38Z",
  "published": "2023-04-04T21:11:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28842"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker Swarm encrypted overlay network with a single endpoint is unauthenticated"
}

GHSA-72FJ-C222-7598

Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31

Details

OpenClaw before 2026.3.31 contains a decompression bomb vulnerability in image processing that fails to properly enforce pixel-limit guards on sips. Attackers can exploit this by uploading oversized images to cause denial of service through excessive memory consumption.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-41334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-23T22:16:39Z",
    "severity": "HIGH"
  },
  "details": "OpenClaw before 2026.3.31 contains a decompression bomb vulnerability in image processing that fails to properly enforce pixel-limit guards on sips. Attackers can exploit this by uploading oversized images to cause denial of service through excessive memory consumption.",
  "id": "GHSA-72fj-c222-7598",
  "modified": "2026-04-24T00:31:51Z",
  "published": "2026-04-24T00:31:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w85g-3h6x-4xh2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41334"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0ed4f8a72bb140045962e97ab01c94c076b758a4"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-decompression-bomb-denial-of-service-via-image-pixel-limit-guard-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/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-73P9-6HRP-8QHR

Vulnerability from github – Published: 2026-08-28 19:20 – Updated: 2026-08-28 19:20

Summary

AIIR verification and policy gates could report success without enforcing the control (fail-open)

Details

Summary

Several of AIIR's verification and policy paths could return a success/"verified" result without actually enforcing the control they represent — they could fail open rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.

Found during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in 1.7.0.

Affected paths

A require_signing policy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a "signing required" check without a valid signature.
A CI verification path could report success regardless of the underlying verification result.
A release-verification gate could advertise policy limits it did not actually enforce.
A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.

Impact

A consumer relying on these gates (e.g. require_signing, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false "verified"/"pass". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.

Patches

Fixed in 1.7.0. Every affected path now fails closed, each with a regression test. Upgrade to aiir >= 1.7.0.

Workarounds

None for earlier versions other than upgrading. Full cryptographic Sigstore verification (pip install aiir[sign], --verify-signature with --signer-identity/--signer-issuer) provides defense in depth.

Scope note

This advisory covers code present in released versions (< 1.7.0). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped — those were never in a released version and are out of scope.

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aiir"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T19:20:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nSeveral of AIIR\u0027s verification and policy paths could return a success/\"verified\" result without actually enforcing the control they represent \u2014 they could **fail open** rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.\n\nFound during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in **1.7.0**.\n\n### Affected paths\n- A `require_signing` policy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a \"signing required\" check without a valid signature.\n- A CI verification path could report `success` regardless of the underlying verification result.\n- A release-verification gate could advertise policy limits it did not actually enforce.\n- A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.\n\n### Impact\nA consumer relying on these gates (e.g. `require_signing`, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false \"verified\"/\"pass\". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.\n\n### Patches\nFixed in **1.7.0**. Every affected path now fails closed, each with a regression test. Upgrade to `aiir \u003e= 1.7.0`.\n\n### Workarounds\nNone for earlier versions other than upgrading. Full cryptographic Sigstore verification (`pip install aiir[sign]`, `--verify-signature` with `--signer-identity`/`--signer-issuer`) provides defense in depth.\n\n### Scope note\nThis advisory covers code present in released versions (`\u003c 1.7.0`). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped \u2014 those were never in a released version and are out of scope.",
  "id": "GHSA-73p9-6hrp-8qhr",
  "modified": "2026-08-28T19:20:32Z",
  "published": "2026-08-28T19:20:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/invariant-systems-ai/aiir/security/advisories/GHSA-73p9-6hrp-8qhr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/invariant-systems-ai/aiir"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AIIR verification and policy gates could report success without enforcing the control (fail-open)"
}

GHSA-7C38-49CX-FJVW

Vulnerability from github – Published: 2026-08-29 00:31 – Updated: 2026-08-29 00:31

Details

IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB's fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device's own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

6.8 (Medium)


                  
                    CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-82018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T22:16:55Z",
    "severity": "MODERATE"
  },
  "details": "IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB\u0027s fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device\u0027s own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.",
  "id": "GHSA-7c38-49cx-fjvw",
  "modified": "2026-08-29T00:31:03Z",
  "published": "2026-08-29T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82018"
    },
    {
      "type": "WEB",
      "url": "https://blog.amberwolf.com/blog/2026/august/thin-client-thin-crypto-overview"
    },
    {
      "type": "WEB",
      "url": "https://kb.igel.com/en/security-safety/current/isn-2026-20-grub-shell-escape-in-igel-os"
    },
    {
      "type": "WEB",
      "url": "https://media.defcon.org/DEF%20CON%2034/DEF%20CON%2034%20presentations/DEF%20CON%2034%20presentations/DEF%20CON%2034%20-%20Darren%20McDonald%20-%20Thin%20Client%20Thin%20Crypto%20-%20Bypassing%20Full-Desk%20Encryption%20Across%20Three%20Major%20Thin%20Clients%20Vendors%20without%20Breaking%20a%20Ci.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/igel-os-12-11-secure-boot-bypass-via-unsigned-igel-conf-file"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8FPG-XM3F-6CX3

Vulnerability from github – Published: 2026-07-23 14:52 – Updated: 2026-08-12 20:31

Summary

Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)

Details

Impact

next-auth (Auth.js) v5 applications that gate access by checking only for the existence of the auth object — the pattern shown in the official session management / protecting resources guide — are affected.

When the Auth.js configuration produces a server-side error, the auth object exposed by the auth() wrapper (in middleware, Route Handlers, etc.) is populated with an error object instead of being null:

{ "message": "There was a problem with the server configuration. Check the server logs for more information." }

Because this object is truthy, any authorization check of the form !!auth (or if (req.auth)) evaluates to true for every request, including unauthenticated ones. The application fails open: instead of denying access when the auth layer is broken, it grants access to everyone.

// middleware.ts — affected pattern
export default auth((req) => {
  const { nextUrl, auth } = req
  const isLoggedIn = !!auth // <-- always true when the configuration is broken
  // ...
})

A representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither issuer nor authorization endpoint set logs:

[auth][error] InvalidEndpoints: Provider "keycloak" is missing both `issuer` and `authorization` endpoint config. At least one of them is required.

…and from that point on auth is the error object above, so !!auth is permanently true. The same fail-open behavior occurs for other server-configuration errors (for example, an unset AUTH_SECRET).

There is no impact while the configuration is valid. The risk materializes when a previously-working deployment becomes misconfigured — e.g. an environment variable is changed or removed during a deploy — at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Because the failure mode is silent and grants access to everyone, the consequences can be severe.

This is an instance of CWE-636 (Not Failing Securely / "Failing Open") leading to improper authorization (CWE-285).

Patches

The fix ensures that a server-configuration error no longer surfaces as a truthy auth object: existence checks fail closed rather than open. This is released in next-auth@.

To upgrade:

npm i next-auth@beta

yarn add next-auth@beta

pnpm add next-auth@beta

Workarounds

If you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session:

// middleware.ts
export default auth((req) => {
  // `auth.user` is only present on a real session; resilient to config-error objects
  const isLoggedIn = !!req.auth?.user
  // ...
})

As defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat [auth][error] log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only — for authorization, perform an explicit role/permission check rather than relying on session existence. See the role-based access control guide.

References

Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting
Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control
Auth.js error reference: https://authjs.dev/reference/core/errors

For more information

If you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security

Credits

Reported by @marc-zollingkoffer-syzygy.

Severity

9.1 (Critical)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.0"
            },
            {
              "fixed": "5.0.0-beta.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-23T14:52:23Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\n`next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object \u2014 the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) \u2014 are affected.\n\nWhen the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**:\n\n```json\n{ \"message\": \"There was a problem with the server configuration. Check the server logs for more information.\" }\n```\n\nBecause this object is truthy, any authorization check of the form `!!auth` (or `if (req.auth)`) evaluates to `true` for **every** request, including unauthenticated ones. The application *fails open*: instead of denying access when the auth layer is broken, it grants access to everyone.\n\n```ts\n// middleware.ts \u2014 affected pattern\nexport default auth((req) =\u003e {\n  const { nextUrl, auth } = req\n  const isLoggedIn = !!auth // \u003c-- always true when the configuration is broken\n  // ...\n})\n```\n\nA representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither `issuer` nor `authorization` endpoint set logs:\n\n```\n[auth][error] InvalidEndpoints: Provider \"keycloak\" is missing both `issuer` and `authorization` endpoint config. At least one of them is required.\n```\n\n\u2026and from that point on `auth` is the error object above, so `!!auth` is permanently `true`. The same fail-open behavior occurs for other server-configuration errors (for example, an unset `AUTH_SECRET`).\n\nThere is **no impact while the configuration is valid**. The risk materializes when a previously-working deployment becomes misconfigured \u2014 e.g. an environment variable is changed or removed during a deploy \u2014 at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Because the failure mode is silent and grants access to everyone, the consequences can be severe.\n\nThis is an instance of CWE-636 (Not Failing Securely / \"Failing Open\") leading to improper authorization (CWE-285).\n\n### Patches\n\nThe fix ensures that a server-configuration error no longer surfaces as a truthy `auth` object: existence checks fail **closed** rather than open. This is released in `next-auth@\u003c!-- TODO: set patched version on publish --\u003e`.\n\nTo upgrade:\n\n```sh\nnpm i next-auth@beta\n```\n```sh\nyarn add next-auth@beta\n```\n```sh\npnpm add next-auth@beta\n```\n\n### Workarounds\n\nIf you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session:\n\n```ts\n// middleware.ts\nexport default auth((req) =\u003e {\n  // `auth.user` is only present on a real session; resilient to config-error objects\n  const isLoggedIn = !!req.auth?.user\n  // ...\n})\n```\n\nAs defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat `[auth][error]` log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only \u2014 for authorization, perform an explicit role/permission check rather than relying on session existence. See the [role-based access control guide](https://authjs.dev/guides/role-based-access-control).\n\n### References\n\n- Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting\n- Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control\n- Auth.js error reference: https://authjs.dev/reference/core/errors\n\n### For more information\n\nIf you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security\n\n### Credits\n\nReported by @marc-zollingkoffer-syzygy.",
  "id": "GHSA-8fpg-xm3f-6cx3",
  "modified": "2026-08-12T20:31:20Z",
  "published": "2026-07-23T14:52:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-8fpg-xm3f-6cx3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/commit/d008b9b764bf4b322a87e1822d1dda7789258d8f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nextauthjs/next-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
    }
  ],
  "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": "Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)"
}

GHSA-8MG9-J9CF-54CJ

Vulnerability from github – Published: 2026-06-18 20:42 – Updated: 2026-06-18 20:42

Summary

OpenClaw: Empty-scope device re-pairing could confuse caller scope containment

Details

Summary

Empty-scope device re-pairing could confuse caller scope containment. In affected versions, a device re-pairing request with an empty scope set could skip the intended containment guard during re-pairing.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could restore or retain scopes broader than the caller should grant. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.4.25.

Mitigations

revoke unexpected device sessions and require fresh pairing for suspicious devices until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:42:40Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nEmpty-scope device re-pairing could confuse caller scope containment. In affected versions, a device re-pairing request with an empty scope set could skip the intended containment guard during re-pairing.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could restore or retain scopes broader than the caller should grant. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.25`.\n\n### Mitigations\n\nrevoke unexpected device sessions and require fresh pairing for suspicious devices until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-8mg9-j9cf-54cj",
  "modified": "2026-06-18T20:42:40Z",
  "published": "2026-06-18T20:42:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8mg9-j9cf-54cj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53852"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-scope-bypass-via-empty-scope-device-re-pairing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Empty-scope device re-pairing could confuse caller scope containment"
}

GHSA-8X8C-HP7F-675G

Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33

Details

Remote Registry Service Elevation of Privilege Vulnerability

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-43532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-08T18:15:17Z",
    "severity": "HIGH"
  },
  "details": "Remote Registry Service Elevation of Privilege Vulnerability",
  "id": "GHSA-8x8c-hp7f-675g",
  "modified": "2024-10-08T18:33:15Z",
  "published": "2024-10-08T18:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43532"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43532"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9FF9-572C-7RG8

Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31

Details

Not failing securely ('failing open') in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-69306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T17:19:07Z",
    "severity": "HIGH"
  },
  "details": "Not failing securely (\u0027failing open\u0027) in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.",
  "id": "GHSA-9ff9-572c-7rg8",
  "modified": "2026-08-11T18:31:46Z",
  "published": "2026-08-11T18:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69306"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69306"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CHQM-WXM2-W73W

Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-08-28 15:53

Summary

Duplicate Advisory: OpenClaw: Mattermost handlers could fall open when channel type was missing

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-gp79-m99v-gjmh. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.5.6 contains an improper access control vulnerability in Mattermost event handlers that fails to validate channel type metadata. Attackers can bypass intended DM policy decisions by sending crafted Mattermost events missing channel type information to process restricted content.

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T15:53:21Z",
    "nvd_published_at": "2026-06-12T22:16:55Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-gp79-m99v-gjmh. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.5.6 contains an improper access control vulnerability in Mattermost event handlers that fails to validate channel type metadata. Attackers can bypass intended DM policy decisions by sending crafted Mattermost events missing channel type information to process restricted content.",
  "id": "GHSA-chqm-wxm2-w73w",
  "modified": "2026-08-28T15:53:21Z",
  "published": "2026-06-13T00:34:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gp79-m99v-gjmh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53837"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-missing-channel-type-validation-in-mattermost-event-handlers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Mattermost handlers could fall open when channel type was missing",
  "withdrawn": "2026-08-28T15:53:21Z"
}

CWE-636

Not Failing Securely ('Failing Open')

Summary

Patches

For more information

Impact

Patches

Workarounds

Background

Related

Summary

Affected paths

Impact

Patches

Workarounds

Scope note

Impact

Patches

Workarounds

References

For more information

Credits

Summary

Impact

Patched Versions

Mitigations

Duplicate Advisory

Original Description

Mitigation