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.
122 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-9V84-CC9J-PXR6
Vulnerability from github – Published: 2025-01-28 03:31 – Updated: 2025-01-28 03:31
VLAI
Details
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.
Severity
7.6 (High)
{
"affected": [],
"aliases": [
"CVE-2024-0135"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-28T03:15:07Z",
"severity": "HIGH"
},
"details": "NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.",
"id": "GHSA-9v84-cc9j-pxr6",
"modified": "2025-01-28T03:31:14Z",
"published": "2025-01-28T03:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0135"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5599"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C63V-MMF4-HG2W
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:34
VLAI
Details
An authenticated attacker can leverage an exposed “box” object to read and write arbitrary files from disk, provided those files can be parsed as yaml or JSON. This issue was resolved in the Managed and SaaS deployments on February 1, 2023, and in version 23.2.1 of the Self-Managed version of InsightCloudSec.
Severity
8.1 (High)
{
"affected": [],
"aliases": [
"CVE-2023-1305"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-21T17:15:00Z",
"severity": "HIGH"
},
"details": "An authenticated attacker can leverage an exposed \u201cbox\u201d object to read and write arbitrary files from disk, provided those files can be parsed as yaml or JSON. This issue was resolved in the Managed and SaaS deployments on February 1, 2023, and in version 23.2.1 of the Self-Managed version of InsightCloudSec.",
"id": "GHSA-c63v-mmf4-hg2w",
"modified": "2024-04-04T05:34:59Z",
"published": "2023-07-06T19:24:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1305"
},
{
"type": "WEB",
"url": "https://docs.divvycloud.com/changelog/23321-release-notes"
},
{
"type": "WEB",
"url": "https://nephosec.com/exploiting-rapid7s-insightcloudsec"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-C7PJ-2F8J-JC8M
Vulnerability from github – Published: 2026-07-20 15:32 – Updated: 2026-07-21 18:30
VLAI
Details
Improper Isolation or Compartmentalization vulnerability in Apache Syncope.
An administrator with adequate entitlements can achieve remote code execution through the connector subsystem by relying on scripted connectors' (REST and SQL) capability to run Groovy scripts.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1.
Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by hardening the Groovy security sandbox.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-53421"
],
"database_specific": {
"cwe_ids": [
"CWE-653"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T15:16:43Z",
"severity": "CRITICAL"
},
"details": "Improper Isolation or Compartmentalization vulnerability in Apache Syncope.\n\n\n\nAn administrator with adequate entitlements can achieve remote code execution through the connector subsystem by relying on scripted connectors\u0027 (REST and SQL) capability to run Groovy scripts.\n\nThis issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1.\n\n\n\n\nUsers are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue by hardening the Groovy security sandbox.",
"id": "GHSA-c7pj-2f8j-jc8m",
"modified": "2026-07-21T18:30:54Z",
"published": "2026-07-20T15:32:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53421"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/nmzvz6gb2ldm30wvyk613r8dfrb6r8yx"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/20/7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C98H-7HP9-V9HQ
Vulnerability from github – Published: 2025-03-17 21:26 – Updated: 2025-03-19 14:59
VLAI
Summary
Bare Metal Operator (BMO) can expose any secret from other namespaces via BMCEventSubscription CRD
Details
Impact
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3.
Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource BMCEventSubscription (BMCES). An adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a BMCES in their authorized namespace and then load Secrets from their unauthorized namespaces to their authorized namespace via the Baremetal Operator controller's cluster scoped privileges, causing Secret leakage.
Patches
The patch makes BMO refuse to read Secrets from other namespace than where the corresponding Bare Metal Host (BMH) resource is. The patch does not change the BMCEventSubscription API in BMO, but stricter validation will deny the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES resource has already been deployed.
The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by BMCEventSubscription's httpHeadersRef to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets.
Workarounds
Operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use WATCH_NAMESPACE configuration option to limit BMO to single namespace.
References
Credits
Metal3 Security Team thanks WHALEEYE and debuggerchen of Lab for Internet and Security Technology for responsible vulnerability disclosure.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/metal3-io/baremetal-operator/apis"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.9.0"
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/metal3-io/baremetal-operator/apis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29781"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-653"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-17T21:26:14Z",
"nvd_published_at": "2025-03-17T22:15:14Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. \n\nBaremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription` (BMCES). An adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a BMCES in their authorized namespace and then load Secrets from their unauthorized namespaces to their authorized namespace via the Baremetal Operator controller\u0027s cluster scoped privileges, causing Secret leakage.\n\n### Patches\n\nThe patch makes BMO refuse to read Secrets from other namespace than where the corresponding Bare Metal Host (BMH) resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will deny the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES resource has already been deployed.\n\nThe issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`\u0027s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets.\n\n### Workarounds\n\nOperator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace.\n\n### References\n\n- [patch to main](https://github.com/metal3-io/baremetal-operator/commit/19f8443b1fe182f76dd81b43122e8dd102f8b94c)\n- [patch to release-0.9](https://github.com/metal3-io/baremetal-operator/pull/2321)\n- [patch to release-0.8](https://github.com/metal3-io/baremetal-operator/pull/2322)\n- [BMCEventSubscription design document](https://github.com/metal3-io/metal3-docs/blob/main/design/baremetal-operator/bmc-events.md)\n\n### Credits\n\nMetal3 Security Team thanks [WHALEEYE](https://github.com/WHALEEYE) and [debuggerchen](https://github.com/debuggerchen) of [Lab for Internet and Security Technology](https://users.cs.northwestern.edu/~list/) for responsible vulnerability disclosure.",
"id": "GHSA-c98h-7hp9-v9hq",
"modified": "2025-03-19T14:59:19Z",
"published": "2025-03-17T21:26:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/security/advisories/GHSA-c98h-7hp9-v9hq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29781"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/pull/2321"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/pull/2322"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/commit/19f8443b1fe182f76dd81b43122e8dd102f8b94c"
},
{
"type": "PACKAGE",
"url": "https://github.com/metal3-io/baremetal-operator"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/metal3-docs/blob/main/design/baremetal-operator/bmc-events.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bare Metal Operator (BMO) can expose any secret from other namespaces via BMCEventSubscription CRD"
}
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.