Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

6718 vulnerabilities reference this CWE, most recent first.

GHSA-625P-XH6M-38MC

Vulnerability from github – Published: 2024-10-15 21:30 – Updated: 2024-10-15 21:30
VLAI
Details

Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.22 and prior to 7.1.2. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-21259"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-15T20:15:16Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core).  Supported versions that are affected are Prior to 7.0.22 and  prior to 7.1.2. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox.  While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).",
  "id": "GHSA-625p-xh6m-38mc",
  "modified": "2024-10-15T21:30:38Z",
  "published": "2024-10-15T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21259"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-62FC-8686-HFMQ

Vulnerability from github – Published: 2026-08-06 16:38 – Updated: 2026-08-06 16:38
VLAI
Summary
Traefik: `allowCrossNamespace=false` bypass via `@kubernetescrd` TraefikService backendRef
Details

Summary

There is a medium severity vulnerability in Traefik's Kubernetes CRD provider. When providers.kubernetesCRD.allowCrossNamespace is disabled — the default — cross-namespace @kubernetescrd references are rejected for middlewares, TLS options and HTTP/TCP ServersTransports, but the same restriction was not applied to TraefikService backend references resolved by the service resolver. A tenant confined by RBAC to a single namespace can therefore bind its own router to a TraefikService owned by another namespace and expose or reroute that namespace's backend, defeating the namespace isolation allowCrossNamespace=false is meant to enforce. Traefik v2 releases and the unmaintained v3 minor lines below v3.6 are affected and will not receive a patch on their own line; the remedy for those users is upgrading to a maintained, patched release.

Patches

  • https://github.com/traefik/traefik/releases/tag/v2.11.54
  • https://github.com/traefik/traefik/releases/tag/v3.6.25
  • https://github.com/traefik/traefik/releases/tag/v3.7.10

For more information

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

Original Description ### Summary When `providers.kubernetesCRD.allowCrossNamespace=false` (the default), Traefik correctly rejects cross-namespace `@kubernetescrd` references for middlewares, TLS options, and HTTP/TCP `ServersTransport`, but it does not apply the same restriction to service (`TraefikService`) backendRefs. As a result, a Kubernetes tenant who is confined by RBAC to their own namespace can bind their own router to a `TraefikService` owned by another namespace simply by referencing it as `-@kubernetescrd`, defeating the namespace-isolation boundary that `allowCrossNamespace=false` is meant to enforce. This is the service-resolver sibling of the cross-namespace isolation family that Traefik has been fixing one resolver at a time (`df00d82f` / CVE-2026-41174 for Chain middlewares, and `67501cbe` for TCP `ServersTransport`, which shipped in v3.7.7 only four days before the analyzed commit). The `TraefikService` resolver in `configBuilder.nameAndService` was never given the guard its sibling resolvers received. ### Details ### Root cause `nameAndService` only performs the same-namespace check (`isNamespaceAllowed`) inside the branch that handles names without an `@` separator. For names that contain an `@` separator (that is, `@kubernetescrd` cross-namespace references) it applies only the `crossProviderNamespaces` allowlist check, and that check returns `true` by default because a `nil` allowlist means "unrestricted". It never applies the `!allowCrossNamespace && strings.HasSuffix(name, "@kubernetescrd")` rejection that the sibling resolvers all apply, so `allowCrossNamespace=false` is effectively never consulted for `@kubernetescrd` service references. ### Vulnerable code 
// pkg/provider/kubernetes/crd/kubernetes_http.go:662-695 — nameAndService (VULNERABLE)
func (c configBuilder) nameAndService(ctx context.Context, parentNamespace string, service traefikv1alpha1.LoadBalancerSpec) (string, *dynamic.Service, error) {
    svcCtx := log.Ctx(ctx).With().Str(logs.ServiceName, service.Name).Logger().WithContext(ctx)

    if !strings.Contains(service.Name, providerNamespaceSeparator) { // 665: only names WITHOUT "@"
        service = *service.DeepCopy()
        service.Namespace = namespaceOrParentNamespace(service.Namespace, parentNamespace)
        if !isNamespaceAllowed(c.allowCrossNamespace, parentNamespace, service.Namespace) { // 669
            return "", nil, fmt.Errorf("service %s/%s not in the parent resource namespace %s", ...)
        }
    }

    // 674: for "@"-names, the ONLY gate is crossProviderNamespaces, which defaults to allow-all (nil).
    if !isCrossProviderNamespaceAllowed(c.crossProviderNamespaces, parentNamespace) && strings.Contains(service.Name, providerNamespaceSeparator) {
        return "", nil, fmt.Errorf("service %q reference is not allowed: ...", service.Name)
    }
    // ^-- MISSING: no `!c.allowCrossNamespace && strings.HasSuffix(service.Name, "@"+ProviderName)` rejection.

    switch service.Kind {
    case "TraefikService":
        return fullServiceName(svcCtx, service, intstr.FromInt(0)), nil, nil // 690: returns the cross-namespace reference
    ...
    }
}
For comparison, the sibling resolver used for middleware and TLS references does carry the guard: 
// pkg/provider/kubernetes/crd/kubernetes.go:1653-1668 — resolveReference (CORRECT)
func resolveReference(ctx context.Context, parentNs, ns, name string, crossProviderNamespaces []string, allowCrossNamespace bool) (string, error) {
    if strings.Contains(name, providerNamespaceSeparator) {
        if !allowCrossNamespace && strings.HasSuffix(name, providerNamespaceSeparator+ProviderName) {
            return "", errors.New("when allowCrossNamespace is disabled, @kubernetescrd references are disallowed") // 1656 — THE GUARD
        }
        ...
    }
    ...
}
The same guard is also present at `pkg/provider/kubernetes/crd/kubernetes_http.go:500` (`makeServersTransportKey`, HTTP) and `pkg/provider/kubernetes/crd/kubernetes_tcp.go:316` (`makeTCPServersTransportKey`, TCP, added by commit `67501cbe`). Only the service resolver `nameAndService` lacks it. ### Data flow An `IngressRoute` created by a tenant in namespace `attacker` declares a route service `{ name: "victim-backend@kubernetescrd", kind: TraefikService }`; the tenant controls this reference string. In `nameAndService`, because the name contains `@`, the same-namespace check at line 669 is skipped, and `isCrossProviderNamespaceAllowed(nil, "attacker")` returns `true` under the default `nil` allowlist, so no rejection fires. `fullServiceName` then resolves the reference to the victim namespace's `TraefikService`, and the attacker's HTTP router is generated and bound to the victim's backend. At runtime the attacker's `Host(...)` route forwards to namespace `victim`'s backend pods. ### Default reachability `AllowCrossNamespace` defaults to `false` (`pkg/provider/kubernetes/crd/kubernetes.go:57`, never set to `true` by any `SetDefaults`), so the isolation this bug bypasses is on by default. `CrossProviderNamespaces` defaults to `nil`, and `isCrossProviderNamespaceAllowed` returns `true` for a `nil` allowlist (`pkg/provider/kubernetes/crd/kubernetes.go:1645-1651`), so the only check `nameAndService` applies to an `@`-name is inert by default. The attacker needs only namespace-scoped RBAC to create an `IngressRoute` or `TraefikService` in their own namespace (the standard hard-multi-tenant Traefik setup) and knowledge of the target `TraefikService`'s namespace and name. ### PoC A table-style harness was added to the CRD provider package. It defines a victim `TraefikService` (`backend` in namespace `victim`, backed by a real endpoint) and an attacker `IngressRoute` (namespace `attacker`) that references it via `victim-backend@kubernetescrd`, plus a control route that references a victim `Middleware` via `victim-mw@kubernetescrd`. The control route is given a valid local service so that the only reason it could be dropped is the cross-namespace middleware guard. The provider is run with `AllowCrossNamespace: false` and `CrossProviderNamespaces: nil` (both defaults). 
$ go test -run TestPoC_CrossNamespaceServiceBypass ./pkg/provider/kubernetes/crd/ -v

HTTP routers:  [attacker-attacker-svc-route-7df4381938699bd21215]
HTTP services: [victim-whoami-victim-80 victim-backend]
CONTROL OK: cross-ns MIDDLEWARE ref (victim-mw@kubernetescrd) rejected -> router dropped
BYPASS CONFIRMED: attacker router bound to cross-ns service "victim-backend" despite AllowCrossNamespace=false
The control route (middleware reference) is dropped even though it has a valid local service, confirming that the isolation control is active for middlewares; the service route survives and its `Service` field resolves to `victim-backend`, with the victim's services pulled into the generated configuration and reachable through the attacker's router. The harness also runs two corroborating cases. With `AllowCrossNamespace=false` and `CrossProviderNamespaces=["someotherns"]` (an allowlist that excludes the attacker), the service reference is blocked, which proves that the only gate ever applied to an `@kubernetescrd` service name is `crossProviderNamespaces` (inert by default) and that `allowCrossNamespace=false` is never consulted. With `AllowCrossNamespace=true`, both the service and middleware references are accepted, as expected when isolation is intentionally disabled. ### Impact In a multi-tenant cluster relying on `allowCrossNamespace=false` for namespace isolation, a tenant confined to their own namespace can attach their own router (their own `Host` rule and entrypoint) to another tenant's `TraefikService` backend, exposing an otherwise internal-only service on the data plane under the attacker's hostname, and can route or mirror traffic to another namespace's backend that they should not be able to reference.
Severity
4.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.11.53"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.54"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.24"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.6.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.9"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-653",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T16:38:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a medium severity vulnerability in Traefik\u0027s Kubernetes CRD provider. When `providers.kubernetesCRD.allowCrossNamespace` is disabled \u2014 the default \u2014 cross-namespace `@kubernetescrd` references are rejected for middlewares, TLS options and HTTP/TCP ServersTransports, but the same restriction was not applied to `TraefikService` backend references resolved by the service resolver. A tenant confined by RBAC to a single namespace can therefore bind its own router to a `TraefikService` owned by another namespace and expose or reroute that namespace\u0027s backend, defeating the namespace isolation `allowCrossNamespace=false` is meant to enforce. Traefik v2 releases and the unmaintained v3 minor lines below v3.6 are affected and will not receive a patch on their own line; the remedy for those users is upgrading to a maintained, patched release.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.54\n- https://github.com/traefik/traefik/releases/tag/v3.6.25\n- https://github.com/traefik/traefik/releases/tag/v3.7.10\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\nWhen `providers.kubernetesCRD.allowCrossNamespace=false` (the default), Traefik correctly rejects cross-namespace `@kubernetescrd` references for middlewares, TLS options, and HTTP/TCP `ServersTransport`, but it does not apply the same restriction to service (`TraefikService`) backendRefs. As a result, a Kubernetes tenant who is confined by RBAC to their own namespace can bind their own router to a `TraefikService` owned by another namespace simply by referencing it as `\u003cvictim-namespace\u003e-\u003cname\u003e@kubernetescrd`, defeating the namespace-isolation boundary that `allowCrossNamespace=false` is meant to enforce.\n\nThis is the service-resolver sibling of the cross-namespace isolation family that Traefik has been fixing one resolver at a time (`df00d82f` / CVE-2026-41174 for Chain middlewares, and `67501cbe` for TCP `ServersTransport`, which shipped in v3.7.7 only four days before the analyzed commit). The `TraefikService` resolver in `configBuilder.nameAndService` was never given the guard its sibling resolvers received.\n\n### Details\n### Root cause\n\n`nameAndService` only performs the same-namespace check (`isNamespaceAllowed`) inside the branch that handles names without an `@` separator. For names that contain an `@` separator (that is, `@kubernetescrd` cross-namespace references) it applies only the `crossProviderNamespaces` allowlist check, and that check returns `true` by default because a `nil` allowlist means \"unrestricted\". It never applies the `!allowCrossNamespace \u0026\u0026 strings.HasSuffix(name, \"@kubernetescrd\")` rejection that the sibling resolvers all apply, so `allowCrossNamespace=false` is effectively never consulted for `@kubernetescrd` service references.\n\n### Vulnerable code\n\n```go\n// pkg/provider/kubernetes/crd/kubernetes_http.go:662-695 \u2014 nameAndService (VULNERABLE)\nfunc (c configBuilder) nameAndService(ctx context.Context, parentNamespace string, service traefikv1alpha1.LoadBalancerSpec) (string, *dynamic.Service, error) {\n\tsvcCtx := log.Ctx(ctx).With().Str(logs.ServiceName, service.Name).Logger().WithContext(ctx)\n\n\tif !strings.Contains(service.Name, providerNamespaceSeparator) { // 665: only names WITHOUT \"@\"\n\t\tservice = *service.DeepCopy()\n\t\tservice.Namespace = namespaceOrParentNamespace(service.Namespace, parentNamespace)\n\t\tif !isNamespaceAllowed(c.allowCrossNamespace, parentNamespace, service.Namespace) { // 669\n\t\t\treturn \"\", nil, fmt.Errorf(\"service %s/%s not in the parent resource namespace %s\", ...)\n\t\t}\n\t}\n\n\t// 674: for \"@\"-names, the ONLY gate is crossProviderNamespaces, which defaults to allow-all (nil).\n\tif !isCrossProviderNamespaceAllowed(c.crossProviderNamespaces, parentNamespace) \u0026\u0026 strings.Contains(service.Name, providerNamespaceSeparator) {\n\t\treturn \"\", nil, fmt.Errorf(\"service %q reference is not allowed: ...\", service.Name)\n\t}\n\t// ^-- MISSING: no `!c.allowCrossNamespace \u0026\u0026 strings.HasSuffix(service.Name, \"@\"+ProviderName)` rejection.\n\n\tswitch service.Kind {\n\tcase \"TraefikService\":\n\t\treturn fullServiceName(svcCtx, service, intstr.FromInt(0)), nil, nil // 690: returns the cross-namespace reference\n\t...\n\t}\n}\n```\n\nFor comparison, the sibling resolver used for middleware and TLS references does carry the guard:\n\n```go\n// pkg/provider/kubernetes/crd/kubernetes.go:1653-1668 \u2014 resolveReference (CORRECT)\nfunc resolveReference(ctx context.Context, parentNs, ns, name string, crossProviderNamespaces []string, allowCrossNamespace bool) (string, error) {\n\tif strings.Contains(name, providerNamespaceSeparator) {\n\t\tif !allowCrossNamespace \u0026\u0026 strings.HasSuffix(name, providerNamespaceSeparator+ProviderName) {\n\t\t\treturn \"\", errors.New(\"when allowCrossNamespace is disabled, @kubernetescrd references are disallowed\") // 1656 \u2014 THE GUARD\n\t\t}\n\t\t...\n\t}\n\t...\n}\n```\n\nThe same guard is also present at `pkg/provider/kubernetes/crd/kubernetes_http.go:500` (`makeServersTransportKey`, HTTP) and `pkg/provider/kubernetes/crd/kubernetes_tcp.go:316` (`makeTCPServersTransportKey`, TCP, added by commit `67501cbe`). Only the service resolver `nameAndService` lacks it.\n\n### Data flow\n\nAn `IngressRoute` created by a tenant in namespace `attacker` declares a route service `{ name: \"victim-backend@kubernetescrd\", kind: TraefikService }`; the tenant controls this reference string. In `nameAndService`, because the name contains `@`, the same-namespace check at line 669 is skipped, and `isCrossProviderNamespaceAllowed(nil, \"attacker\")` returns `true` under the default `nil` allowlist, so no rejection fires. `fullServiceName` then resolves the reference to the victim namespace\u0027s `TraefikService`, and the attacker\u0027s HTTP router is generated and bound to the victim\u0027s backend. At runtime the attacker\u0027s `Host(...)` route forwards to namespace `victim`\u0027s backend pods.\n\n### Default reachability\n\n`AllowCrossNamespace` defaults to `false` (`pkg/provider/kubernetes/crd/kubernetes.go:57`, never set to `true` by any `SetDefaults`), so the isolation this bug bypasses is on by default. `CrossProviderNamespaces` defaults to `nil`, and `isCrossProviderNamespaceAllowed` returns `true` for a `nil` allowlist (`pkg/provider/kubernetes/crd/kubernetes.go:1645-1651`), so the only check `nameAndService` applies to an `@`-name is inert by default. The attacker needs only namespace-scoped RBAC to create an `IngressRoute` or `TraefikService` in their own namespace (the standard hard-multi-tenant Traefik setup) and knowledge of the target `TraefikService`\u0027s namespace and name.\n\n### PoC\nA table-style harness was added to the CRD provider package. It defines a victim `TraefikService` (`backend` in namespace `victim`, backed by a real endpoint) and an attacker `IngressRoute` (namespace `attacker`) that references it via `victim-backend@kubernetescrd`, plus a control route that references a victim `Middleware` via `victim-mw@kubernetescrd`. The control route is given a valid local service so that the only reason it could be dropped is the cross-namespace middleware guard. The provider is run with `AllowCrossNamespace: false` and `CrossProviderNamespaces: nil` (both defaults).\n\n```\n$ go test -run TestPoC_CrossNamespaceServiceBypass ./pkg/provider/kubernetes/crd/ -v\n\nHTTP routers:  [attacker-attacker-svc-route-7df4381938699bd21215]\nHTTP services: [victim-whoami-victim-80 victim-backend]\nCONTROL OK: cross-ns MIDDLEWARE ref (victim-mw@kubernetescrd) rejected -\u003e router dropped\nBYPASS CONFIRMED: attacker router bound to cross-ns service \"victim-backend\" despite AllowCrossNamespace=false\n```\n\nThe control route (middleware reference) is dropped even though it has a valid local service, confirming that the isolation control is active for middlewares; the service route survives and its `Service` field resolves to `victim-backend`, with the victim\u0027s services pulled into the generated configuration and reachable through the attacker\u0027s router.\n\nThe harness also runs two corroborating cases. With `AllowCrossNamespace=false` and `CrossProviderNamespaces=[\"someotherns\"]` (an allowlist that excludes the attacker), the service reference is blocked, which proves that the only gate ever applied to an `@kubernetescrd` service name is `crossProviderNamespaces` (inert by default) and that `allowCrossNamespace=false` is never consulted. With `AllowCrossNamespace=true`, both the service and middleware references are accepted, as expected when isolation is intentionally disabled.\n\n### Impact\nIn a multi-tenant cluster relying on `allowCrossNamespace=false` for namespace isolation, a tenant confined to their own namespace can attach their own router (their own `Host` rule and entrypoint) to another tenant\u0027s `TraefikService` backend, exposing an otherwise internal-only service on the data plane under the attacker\u0027s hostname, and can route or mirror traffic to another namespace\u0027s backend that they should not be able to reference.\n\n\n\u003c/details\u003e\n---",
  "id": "GHSA-62fc-8686-hfmq",
  "modified": "2026-08-06T16:38:37Z",
  "published": "2026-08-06T16:38:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-62fc-8686-hfmq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/65ebf4b47fbdc33e3856803a5844a404e094d52d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.54"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik: `allowCrossNamespace=false` bypass via `@kubernetescrd` TraefikService backendRef"
}

GHSA-62G6-4J9C-6V7P

Vulnerability from github – Published: 2026-07-10 18:32 – Updated: 2026-07-10 18:32
VLAI
Details

Simple Machines Forum 2.1 prior to 2.1.8 and 3.0 prior to 3.0 Alpha 5 contains an authorization bypass vulnerability in Sources/Actions/AttachmentApprove.php where a single-character operator error causes the permission check to always pass regardless of user permissions. An authenticated low-privileged user can approve, reject, or delete any pending attachments on any board without holding the required approve_posts permission, bypass moderation queues for their own uploads, and enumerate and delete other users' pending attachments.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-39903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T17:16:57Z",
    "severity": "HIGH"
  },
  "details": "Simple Machines Forum 2.1 prior to 2.1.8 and 3.0 prior to 3.0 Alpha 5 contains an authorization bypass vulnerability in Sources/Actions/AttachmentApprove.php where a single-character operator error causes the permission check to always pass regardless of user permissions. An authenticated low-privileged user can approve, reject, or delete any pending attachments on any board without holding the required approve_posts permission, bypass moderation queues for their own uploads, and enumerate and delete other users\u0027 pending attachments.",
  "id": "GHSA-62g6-4j9c-6v7p",
  "modified": "2026-07-10T18:32:19Z",
  "published": "2026-07-10T18:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39903"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/pull/9181"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/pull/9182"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/commit/7d048f8d66aab9af51cd6ee110fbad103cf673e8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/commit/a7875e876a647572dd4c45da881b875092caac3d"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/simple-machines-forum-authorization-bypass-via-attachmentapprove-php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/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-62J7-J842-X6R6

Vulnerability from github – Published: 2026-02-08 00:30 – Updated: 2026-02-18 21:31
VLAI
Details

WeKan versions prior to 8.19 contain an authorization vulnerability in card move logic. A user can specify a destination board/list/swimlane without adequate authorization checks for the destination and without validating that destination objects belong to the destination board, potentially enabling unauthorized cross-board moves.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-25566"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-07T22:16:02Z",
    "severity": "HIGH"
  },
  "details": "WeKan versions prior to 8.19 contain an authorization vulnerability in card move logic. A user can specify a destination board/list/swimlane without adequate authorization checks for the destination and without validating that destination objects belong to the destination board, potentially enabling unauthorized cross-board moves.",
  "id": "GHSA-62j7-j842-x6r6",
  "modified": "2026-02-18T21:31:18Z",
  "published": "2026-02-08T00:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25566"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wekan/wekan/commit/198509e7600981400353aec6259247b3c04e043e"
    },
    {
      "type": "WEB",
      "url": "https://wekan.fi"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wekan-cross-board-card-move-without-destination-authorization"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI: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-62MH-W5CV-P88C

Vulnerability from github – Published: 2022-02-15 00:42 – Updated: 2024-05-21 15:22
VLAI
Summary
nats-io/jwt not enforcing checking of Import token permissions
Details

(This advisory is canonically https://advisories.nats.io/CVE/CVE-2021-3127.txt)

Problem Description

The NATS server provides for Subjects which are namespaced by Account; all Subjects are supposed to be private to an account, with an Export/Import system used to grant cross-account access to some Subjects. Some Exports are public, such that anyone can import the relevant subjects, and some Exports are private, such that the Import requires a token JWT to prove permission.

The JWT library's validation of the bindings in the Import Token incorrectly warned on mismatches, instead of outright rejecting the token.

As a result, any account can take an Import token used by any other account and re-use it for themselves because the binding to the importing account is not rejected, and use it to import any Subject from the Exporting account, not just the Subject referenced in the Import Token.

The NATS account-server system treats account JWTs as semi-public information, such that an attacker can easily enumerate all account JWTs and retrieve all Import Tokens from those account JWTs.

The CVE identifier should cover the JWT library repair and the nats-server containing the fixed JWT library, and any other application depending upon the fixed JWT library.

Affected versions

JWT library

  • all versions prior to 2.0.1
  • fixed after nats-io/jwt#149 landed (2021-03-14)

NATS Server

  • Version 2 prior to 2.2.0
  • 2.0.0 through and including 2.1.9 are vulnerable
  • fixed with nats-io/nats-server@423b79440c (2021-03-14)

Impact

In deployments with untrusted accounts able to update the Account Server with imports, a malicious account can access any Subject from an account which provides Exported Subjects.

Abuse of this facility requires the malicious actor to upload their tampered Account JWT to the Account Server, providing the service operator with a data-store which can be scanned for signs of abuse.

Workaround

Deny access to clients to update their account JWT in the account server.

Solution

Upgrade the JWT dependency in any application using it.

Upgrade the NATS server if using NATS Accounts (with private Exports; Account owners can create those at any time though).

Audit all accounts JWTs to scan for exploit attempts; a Python script to audit the accounts can be found at https://gist.github.com/philpennock/09d49524ad98043ff11d8a40c2bb0d5a.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3127"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-20T20:58:15Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "(This advisory is canonically \u003chttps://advisories.nats.io/CVE/CVE-2021-3127.txt\u003e)\n\n## Problem Description\n\nThe NATS server provides for Subjects which are namespaced by Account; all Subjects are supposed to be private to an account, with an Export/Import system used to grant cross-account access to some Subjects.  Some Exports are public, such that anyone can import the\nrelevant subjects, and some Exports are private, such that the Import requires a token JWT to prove permission.\n\nThe JWT library\u0027s validation of the bindings in the Import Token incorrectly warned on mismatches, instead of outright rejecting the token.\n\nAs a result, any account can take an Import token used by any other account and re-use it for themselves because the binding to the\nimporting account is not rejected, and use it to import *any* Subject from the Exporting account, not just the Subject referenced in the Import Token.\n\nThe NATS account-server system treats account JWTs as semi-public information, such that an attacker can easily enumerate all account JWTs and retrieve all Import Tokens from those account JWTs.\n\nThe CVE identifier should cover the JWT library repair and the nats-server containing the fixed JWT library, and any other application depending upon the fixed JWT library.\n\n\n## Affected versions\n\n#### JWT library\n\n * all versions prior to 2.0.1\n * fixed after nats-io/jwt#149 landed (2021-03-14)\n\n#### NATS Server\n\n * Version 2 prior to 2.2.0\n   + 2.0.0 through and including 2.1.9 are vulnerable\n * fixed with nats-io/nats-server@423b79440c (2021-03-14)\n\n\n## Impact\n\nIn deployments with untrusted accounts able to update the Account Server with imports, a malicious account can access any Subject from an account which provides Exported Subjects.\n\nAbuse of this facility requires the malicious actor to upload their tampered Account JWT to the Account Server, providing the service operator with a data-store which can be scanned for signs of abuse.\n\n\n## Workaround\n\nDeny access to clients to update their account JWT in the account server.\n\n\n## Solution\n\nUpgrade the JWT dependency in any application using it.\n\nUpgrade the NATS server if using NATS Accounts (with private Exports; Account owners can create those at any time though).\n\nAudit all accounts JWTs to scan for exploit attempts; a Python script to audit the accounts can be found at \u003chttps://gist.github.com/philpennock/09d49524ad98043ff11d8a40c2bb0d5a\u003e.",
  "id": "GHSA-62mh-w5cv-p88c",
  "modified": "2024-05-21T15:22:54Z",
  "published": "2022-02-15T00:42:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/security/advisories/GHSA-62mh-w5cv-p88c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-j756-f273-xhp4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/pull/149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/commit/6c72fdd73e82fa9ebb151d84773baf4e9164c4ab"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/CVE-2021-3127.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "nats-io/jwt not enforcing checking of Import token permissions"
}

GHSA-62PM-MGRH-7P69

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-06-27 21:10
VLAI
Summary
Incorrect Authorization in Jenkins Script Security Plugin
Details

A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.67 and earlier related to the handling of default parameter expressions in closures allowed attackers to execute arbitrary code in sandboxed scripts.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.67"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.68"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-16538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-27T21:10:52Z",
    "nvd_published_at": "2019-11-21T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.67 and earlier related to the handling of default parameter expressions in closures allowed attackers to execute arbitrary code in sandboxed scripts.",
  "id": "GHSA-62pm-mgrh-7p69",
  "modified": "2022-06-27T21:10:52Z",
  "published": "2022-05-24T17:01:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16538"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/commit/0e7da14171ed1d03ff72f6910392e630b40a8590"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-11-21/#SECURITY-1658"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/11/21/1"
    }
  ],
  "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"
    }
  ],
  "summary": "Incorrect Authorization in Jenkins Script Security Plugin"
}

GHSA-62Q9-5G2H-5GXP

Vulnerability from github – Published: 2026-08-06 09:30 – Updated: 2026-08-07 00:31
VLAI
Details

Apache Polaris did not consistently validate storage locations supplied during table and view registration.

An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog's storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog's allowed storage locations.

If the catalog's underlying credentials could read an object outside that boundary, this could disclose limited information from the object.

Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.

This second condition did not itself cause Polaris to read the referenced external locations during registration.

The demonstrated impact is limited to confidentiality.

No unauthorized data modification or availability impact has been demonstrated.

The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog's underlying storage credentials can read.

Exploitation requires an authenticated principal with table- or view-registration privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-64640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T09:16:36Z",
    "severity": "MODERATE"
  },
  "details": "Apache Polaris did not consistently validate storage locations supplied during table and view registration.\n\nAn authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog\u0027s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog\u0027s allowed storage locations.\n\nIf the catalog\u0027s underlying credentials could read an object outside\u00a0that boundary, this could disclose limited information from the object.\n\n\nPolaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.\n\nThis second condition did not itself cause Polaris to read the\u00a0referenced external locations during registration.\n\n\nThe demonstrated impact is limited to confidentiality.\n\nNo unauthorized data\u00a0modification or availability impact has been demonstrated.\n\n\nThe server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog\u0027s underlying storage credentials can read.\n\nExploitation requires an authenticated principal with\u00a0table- or view-registration privileges.",
  "id": "GHSA-62q9-5g2h-5gxp",
  "modified": "2026-08-07T00:31:09Z",
  "published": "2026-08-06T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64640"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/scd8p9wy8b9j3om5wohbotpfycnmmjl4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/06/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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:N/AU:X/R:X/V:X/RE:X/U:Clear",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-62RF-FP64-GXPC

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

A bug in Bluez may allow for the Bluetooth Discoverable state being set to on when no Bluetooth agent is registered with the system. This situation could lead to the unauthorized pairing of certain Bluetooth devices without any form of authentication. Versions before bluez 5.51 are vulnerable.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-28T15:29:00Z",
    "severity": "LOW"
  },
  "details": "A bug in Bluez may allow for the Bluetooth Discoverable state being set to on when no Bluetooth agent is registered with the system. This situation could lead to the unauthorized pairing of certain Bluetooth devices without any form of authentication. Versions before bluez 5.51 are vulnerable.",
  "id": "GHSA-62rf-fp64-gxpc",
  "modified": "2022-05-13T01:34:54Z",
  "published": "2022-05-13T01:34:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10910"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:1101"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:1912"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2018-10910"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1606203"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10910"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3856-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-62VJ-VQP8-5297

Vulnerability from github – Published: 2023-05-23 03:30 – Updated: 2024-04-04 04:17
VLAI
Details

Operation restriction bypass vulnerability in MultiReport of Cybozu Garoon 5.15.0 allows a remote authenticated attacker to alter the data of MultiReport.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-27384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-23T02:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Operation restriction bypass vulnerability in MultiReport of Cybozu Garoon 5.15.0 allows a remote authenticated attacker to alter the data of MultiReport.",
  "id": "GHSA-62vj-vqp8-5297",
  "modified": "2024-04-04T04:17:59Z",
  "published": "2023-05-23T03:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27384"
    },
    {
      "type": "WEB",
      "url": "https://cs.cybozu.co.jp/2023/007698.html"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN41694426"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-62WM-7VP9-FWXG

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-12 00:01
VLAI
Details

Improper Access Control in GitHub repository phpipam/phpipam prior to 1.4.6.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-04T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper Access Control in GitHub repository phpipam/phpipam prior to 1.4.6.",
  "id": "GHSA-62wm-7vp9-fwxg",
  "modified": "2022-04-12T00:01:01Z",
  "published": "2022-04-05T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1223"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phpipam/phpipam/commit/f6a49fd9f93b7d7e0a4fbf1d35338502eed35953"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/baec4c23-2466-4b13-b3c0-eaf1d000d4ab"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list