Common Weakness Enumeration
CWE-653
AllowedImproper Isolation or Compartmentalization
Abstraction: Class · Status: Draft
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
114 vulnerabilities reference this CWE, most recent first.
GHSA-3J8X-8X9Q-3M4R
Vulnerability from github – Published: 2024-09-26 21:31 – Updated: 2024-09-26 21:31
VLAI
Details
In Grafana, the wrong permission is applied to the alert rule write API endpoint, allowing users with permission to write external alert instances to also write alert rules.
Severity
{
"affected": [],
"aliases": [
"CVE-2024-8118"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-26T19:15:07Z",
"severity": "MODERATE"
},
"details": "In Grafana, the wrong permission is applied to the alert rule write API endpoint, allowing users with permission to write external alert instances to also write alert rules.",
"id": "GHSA-3j8x-8x9q-3m4r",
"modified": "2024-09-26T21:31:11Z",
"published": "2024-09-26T21:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8118"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/cve-2024-8118"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/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-3QPR-9M66-7297
Vulnerability from github – Published: 2025-09-19 21:31 – Updated: 2025-09-24 21:30
VLAI
Details
Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) run many Docker containers on shared internal networks without firewalling or segmentation between instances. A compromise of any single container allows direct access to internal services (HTTP, Redis, MySQL, etc.) on the overlay network. From a compromised container, an attacker can reach and exploit other services, enabling lateral movement, data theft, and system-wide compromise.
Severity
{
"affected": [],
"aliases": [
"CVE-2025-34201"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T19:15:40Z",
"severity": "HIGH"
},
"details": "Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA and SaaS deployments) run many Docker containers on shared internal networks without firewalling or segmentation between instances. A compromise of any single container allows direct access to internal services (HTTP, Redis, MySQL, etc.) on the overlay network. From a compromised container, an attacker can reach and exploit other services, enabling lateral movement, data theft, and system-wide compromise.",
"id": "GHSA-3qpr-9m66-7297",
"modified": "2025-09-24T21:30:36Z",
"published": "2025-09-19T21:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34201"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm"
},
{
"type": "WEB",
"url": "https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-lack-of-fw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vasion-print-printerlogic-lack-of-network-segmentation-between-docker-instances"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4G9C-3X4P-MFPP
Vulnerability from github – Published: 2026-04-28 15:30 – Updated: 2026-05-06 19:59
VLAI
Summary
Spring gRPC SecurityContext leaks across requests upon authorization failure
Details
When an authenticated user is denied access to a gRPC method, their authenticated identity remains bound to the gRPC worker thread and can be inherited by a subsequent unauthenticated request on the same thread. This may allow the subsequent user to gain escalated permissions.
Affected versions: Spring gRPC: 1.0.0 - 1.0.2 (fixed in 1.0.3). Older, unsupported versions are also affected.
Severity
4.2 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.grpc:spring-grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40968"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T19:59:34Z",
"nvd_published_at": "2026-04-28T15:16:30Z",
"severity": "MODERATE"
},
"details": "When an authenticated user is denied access to a gRPC method, their authenticated identity remains bound to the gRPC worker thread and can be inherited by a subsequent unauthenticated request on the same thread. This may allow the subsequent user to gain escalated permissions.\n\nAffected versions:\nSpring gRPC: 1.0.0 - 1.0.2 (fixed in 1.0.3). Older, unsupported versions are also affected.",
"id": "GHSA-4g9c-3x4p-mfpp",
"modified": "2026-05-06T19:59:34Z",
"published": "2026-04-28T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40968"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-grpc"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-40968"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring gRPC SecurityContext leaks across requests upon authorization failure"
}
GHSA-627Q-2HVV-P867
Vulnerability from github – Published: 2025-12-18 21:31 – Updated: 2025-12-18 21:31
VLAI
Details
Due to a product misconfiguration in certain deployment types, it was possible from different pods in the same namespace to communicate with each other. This issue resulted in bypass of access control due to the presence of a vulnerable endpoint in Foundry Container Service that executed user-controlled commands locally.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2025-53710"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T21:15:53Z",
"severity": "HIGH"
},
"details": "Due to a product misconfiguration in certain deployment types, it was possible from different pods in the same namespace to communicate with each other. This issue resulted in bypass of access control due to the presence of a vulnerable endpoint in Foundry Container Service that executed user-controlled commands locally.",
"id": "GHSA-627q-2hvv-p867",
"modified": "2025-12-18T21:31:44Z",
"published": "2025-12-18T21:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53710"
},
{
"type": "WEB",
"url": "https://palantir.safebase.us/?tcuUid=4dbae101-79da-433c-8184-c70b78f4701b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/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
...
}
}
// 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
}
...
}
...
}
$ 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
Severity
{
"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-6GPC-PR73-3Q2J
Vulnerability from github – Published: 2025-03-17 21:30 – Updated: 2025-03-17 21:30
VLAI
Details
SolarWinds Service Desk is affected by a broken access control vulnerability. The issue allows authenticated users to escalate privileges, leading to unauthorized data manipulation.
Severity
5.4 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-26393"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-17T20:15:14Z",
"severity": "MODERATE"
},
"details": "SolarWinds Service Desk is affected by a broken access control vulnerability. The issue allows authenticated users to escalate privileges, leading to unauthorized data manipulation.",
"id": "GHSA-6gpc-pr73-3q2j",
"modified": "2025-03-17T21:30:35Z",
"published": "2025-03-17T21:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26393"
},
{
"type": "WEB",
"url": "https://www.solarwinds.com/trust-center/security-advisories/CVE-2025-26393"
}
],
"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"
}
]
}
GHSA-825G-MM5V-GGQ4
Vulnerability from github – Published: 2025-10-20 15:30 – Updated: 2025-11-05 20:49
VLAI
Summary
Apache Syncope allows malicious administrators to inject Groovy code
Details
Apache Syncope offers the ability to extend / customize the base behavior on every deployment by allowing to provide custom implementations of a few Java interfaces; such implementations can be provided either as Java or Groovy classes, with the latter being particularly attractive as the machinery is set for runtime reload. Such a feature has been available for a while, but recently it was discovered that a malicious administrator can inject Groovy code that can be executed remotely by a running Apache Syncope Core instance. Users are recommended to upgrade to version 3.0.14 / 4.0.2, which fix this issue by forcing the Groovy code to run in a sandbox.
Severity
7.2 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.syncope.core:syncope-core-spring"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.syncope.core:syncope-core-spring"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-M0"
},
{
"fixed": "4.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-57738"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-20T20:08:22Z",
"nvd_published_at": "2025-10-20T15:15:33Z",
"severity": "HIGH"
},
"details": "Apache Syncope offers the ability to extend / customize the base behavior on every deployment by allowing to provide custom implementations of a few Java interfaces; such implementations can be provided either as Java or Groovy classes, with the latter being particularly attractive as the machinery is set for runtime reload.\nSuch a feature has been available for a while, but recently it was discovered that a malicious administrator can inject Groovy code that can be executed remotely by a running Apache Syncope Core instance.\nUsers are recommended to upgrade to version 3.0.14 / 4.0.2, which fix this issue by forcing the Groovy code to run in a sandbox.",
"id": "GHSA-825g-mm5v-ggq4",
"modified": "2025-11-05T20:49:44Z",
"published": "2025-10-20T15:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57738"
},
{
"type": "WEB",
"url": "https://github.com/apache/syncope/commit/88c2b5b0be9e2ed66007d672e786165bc266e717"
},
{
"type": "WEB",
"url": "https://github.com/apache/syncope/commit/8b08c4d5785599a0e38830dcff89738b93f02a16"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/SYNCOPE-1907"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/x7cv6xv7z76y49grdr1hgj1pzw5zbby6"
},
{
"type": "WEB",
"url": "https://syncope.apache.org/security#CVE-2025-57738"
},
{
"type": "PACKAGE",
"url": "http://github.com/apache/syncope"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/10/20/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache Syncope allows malicious administrators to inject Groovy code"
}
GHSA-8H66-RPJM-6PWC
Vulnerability from github – Published: 2026-02-25 21:31 – Updated: 2026-02-25 21:31
VLAI
Details
ServiceNow has addressed a remote code execution vulnerability that was identified in the ServiceNow AI platform. This vulnerability could enable an unauthenticated user, in certain circumstances, to execute code within the ServiceNow Sandbox.
ServiceNow addressed this vulnerability by deploying a security update to hosted instances. Relevant security updates also have been provided to ServiceNow self-hosted customers and partners. Further, the vulnerability is addressed in the listed patches and hot fixes. While we are not currently aware of exploitation against customer instances, we recommend customers promptly apply appropriate updates or upgrade if they have not already done so.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-0542"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-25T21:16:36Z",
"severity": "CRITICAL"
},
"details": "ServiceNow has addressed a remote code execution vulnerability that was identified in the ServiceNow AI platform. This vulnerability could enable an unauthenticated user, in certain circumstances, to execute code within the ServiceNow Sandbox.\u00a0\u00a0\u00a0\n\n\n\n\n\nServiceNow addressed this vulnerability by deploying a security update to hosted instances. Relevant security updates also have been provided to ServiceNow self-hosted customers and partners. Further, the vulnerability is addressed in the listed patches and hot fixes. While we are not currently aware of exploitation against customer instances, we recommend customers promptly apply appropriate updates or upgrade if they have not already done so.",
"id": "GHSA-8h66-rpjm-6pwc",
"modified": "2026-02-25T21:31:19Z",
"published": "2026-02-25T21:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0542"
},
{
"type": "WEB",
"url": "https://support.servicenow.com/kb?id=kb_article_view\u0026sysparm_article=KB2693566"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-9JJV-9V55-QM2C
Vulnerability from github – Published: 2026-08-28 21:30 – Updated: 2026-08-28 21:30
VLAI
Details
A control logic defect in a specific built-in webpage of Kids Mode allows users to view local gallery photos directly within the page
Severity
{
"affected": [],
"aliases": [
"CVE-2026-15366"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-26T07:16:45Z",
"severity": "LOW"
},
"details": "A control logic defect in a specific built-in webpage of Kids Mode allows users to view local gallery photos directly within the page",
"id": "GHSA-9jjv-9v55-qm2c",
"modified": "2026-08-28T21:30:57Z",
"published": "2026-08-28T21:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15366"
},
{
"type": "WEB",
"url": "https://www.vivo.com/en/support/security-advisory-detail?id=24"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-9QX4-7755-7GXR
Vulnerability from github – Published: 2025-05-13 15:32 – Updated: 2025-05-13 15:32
VLAI
Details
An improper isolation or compartmentalization vulnerability [CWE-653] in FortiClientMac version 7.4.2 and below, version 7.2.8 and below, 7.0 all versions and FortiVoiceUCDesktop 3.0 all versions desktop application may allow an authenticated attacker to inject code via Electron environment variables.
Severity
{
"affected": [],
"aliases": [
"CVE-2024-35281"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-13T15:15:52Z",
"severity": "LOW"
},
"details": "An improper isolation or compartmentalization vulnerability [CWE-653] in FortiClientMac version 7.4.2 and below, version 7.2.8 and below, 7.0 all versions and FortiVoiceUCDesktop 3.0 all versions desktop application may allow an authenticated attacker to inject code via Electron environment variables.",
"id": "GHSA-9qx4-7755-7gxr",
"modified": "2025-05-13T15:32:16Z",
"published": "2025-05-13T15:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35281"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-025"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Architecture and Design
Break up privileges between different modules, objects, or entities. Minimize the interfaces between modules and require strong access control between them.
No CAPEC attack patterns related to this CWE.