Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-05-18 13:48
Modified
2026-05-02 17:55
Summary
Security fixes for CVE-2025-54410, CVE-2026-32952, CVE-2026-33186, ghsa-4vq8-7jfc-9cvp, ghsa-p77j-4mvh-x3m3, ghsa-pjcq-xvwq-hhpj applied in versions: 9.2.8-r0, 9.2.8-r1
Details
Multiple security vulnerabilities affect the elastic-beats package. These issues are resolved in later releases. See references for individual vulnerability details.
References
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "elastic-beats"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.2.8-r1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the elastic-beats package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-TK12973",
"modified": "2026-05-02T17:55:32Z",
"published": "2026-05-18T13:48:32.148921Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-TK12973.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2025-54410"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-32952"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-33186"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-4vq8-7jfc-9cvp"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-p77j-4mvh-x3m3"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-pjcq-xvwq-hhpj"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32952"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for CVE-2025-54410, CVE-2026-32952, CVE-2026-33186, ghsa-4vq8-7jfc-9cvp, ghsa-p77j-4mvh-x3m3, ghsa-pjcq-xvwq-hhpj applied in versions: 9.2.8-r0, 9.2.8-r1",
"upstream": [
"CVE-2025-54410",
"CVE-2026-32952",
"CVE-2026-33186",
"ghsa-4vq8-7jfc-9cvp",
"ghsa-p77j-4mvh-x3m3",
"ghsa-pjcq-xvwq-hhpj"
]
}
CVE-2025-54410 (GCVE-0-2025-54410)
Vulnerability from cvelistv5 – Published: 2025-07-30 13:24 – Updated: 2025-07-30 13:38
VLAI?
EPSS
Title
Moby's Firewalld reload removes bridge network isolation
Summary
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. A firewalld vulnerability affects Moby releases before 28.0.0. When firewalld reloads, Docker fails to re-create iptables rules that isolate bridge networks, allowing any container to access all ports on any other container across different bridge networks on the same host. This breaks network segmentation between containers that should be isolated, creating significant risk in multi-tenant environments. Only containers in --internal networks remain protected.
Workarounds include reloading firewalld and either restarting the docker daemon, re-creating bridge networks, or using rootless mode. Maintainers anticipate a fix for this issue in version 25.0.13.
Severity ?
CWE
- CWE-909 - Missing Initialization of Resource
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/moby/moby/security/advisories/… | x_refsource_CONFIRM |
| https://firewalld.org/documentation/howto/reload-… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-54410",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-07-30T13:37:49.901547Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-07-30T13:38:40.357Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "moby",
"vendor": "moby",
"versions": [
{
"status": "affected",
"version": "\u003c= 25.0.12"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. A firewalld vulnerability affects Moby releases before 28.0.0. When firewalld reloads, Docker fails to re-create iptables rules that isolate bridge networks, allowing any container to access all ports on any other container across different bridge networks on the same host. This breaks network segmentation between containers that should be isolated, creating significant risk in multi-tenant environments. Only containers in --internal networks remain protected.\nWorkarounds include reloading firewalld and either restarting the docker daemon, re-creating bridge networks, or using rootless mode. Maintainers anticipate a fix for this issue in version 25.0.13."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 3.3,
"baseSeverity": "LOW",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-909",
"description": "CWE-909: Missing Initialization of Resource",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-07-30T13:24:50.818Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp"
},
{
"name": "https://firewalld.org/documentation/howto/reload-firewalld.html",
"tags": [
"x_refsource_MISC"
],
"url": "https://firewalld.org/documentation/howto/reload-firewalld.html"
}
],
"source": {
"advisory": "GHSA-4vq8-7jfc-9cvp",
"discovery": "UNKNOWN"
},
"title": "Moby\u0027s Firewalld reload removes bridge network isolation"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2025-54410",
"datePublished": "2025-07-30T13:24:50.818Z",
"dateReserved": "2025-07-21T23:18:10.280Z",
"dateUpdated": "2025-07-30T13:38:40.357Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2026-32952 (GCVE-0-2026-32952)
Vulnerability from cvelistv5 – Published: 2026-04-24 01:46 – Updated: 2026-04-24 16:29
VLAI?
EPSS
Title
go-ntlmssp NTLM challenges can panic on malformed payloads
Summary
go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.
Severity ?
5.3 (Medium)
CWE
- CWE-190 - Integer Overflow or Wraparound
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/Azure/go-ntlmssp/security/advi… | x_refsource_CONFIRM |
| https://github.com/Azure/go-ntlmssp/releases/tag/v0.1.1 | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Azure | go-ntlmssp |
Affected:
< 0.1.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-32952",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-24T16:29:17.449582Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-24T16:29:28.264Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "go-ntlmssp",
"vendor": "Azure",
"versions": [
{
"status": "affected",
"version": "\u003c 0.1.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-190",
"description": "CWE-190: Integer Overflow or Wraparound",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-24T01:46:31.573Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/Azure/go-ntlmssp/security/advisories/GHSA-pjcq-xvwq-hhpj",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/Azure/go-ntlmssp/security/advisories/GHSA-pjcq-xvwq-hhpj"
},
{
"name": "https://github.com/Azure/go-ntlmssp/releases/tag/v0.1.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Azure/go-ntlmssp/releases/tag/v0.1.1"
}
],
"source": {
"advisory": "GHSA-pjcq-xvwq-hhpj",
"discovery": "UNKNOWN"
},
"title": "go-ntlmssp NTLM challenges can panic on malformed payloads"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-32952",
"datePublished": "2026-04-24T01:46:31.573Z",
"dateReserved": "2026-03-17T00:05:53.285Z",
"dateUpdated": "2026-04-24T16:29:28.264Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-33186 (GCVE-0-2026-33186)
Vulnerability from cvelistv5 – Published: 2026-03-20 22:23 – Updated: 2026-03-24 18:09
VLAI?
EPSS
Title
gRPC-Go has an authorization bypass via missing leading slash in :path
Summary
gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.
Severity ?
9.1 (Critical)
CWE
- CWE-285 - Improper Authorization
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/grpc/grpc-go/security/advisori… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-33186",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-03-24T18:08:38.989284Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-03-24T18:09:13.422Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "grpc-go",
"vendor": "grpc",
"versions": [
{
"status": "affected",
"version": "\u003c 1.79.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-285",
"description": "CWE-285: Improper Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-03-20T22:23:32.147Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
}
],
"source": {
"advisory": "GHSA-p77j-4mvh-x3m3",
"discovery": "UNKNOWN"
},
"title": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-33186",
"datePublished": "2026-03-20T22:23:32.147Z",
"dateReserved": "2026-03-17T22:16:36.720Z",
"dateUpdated": "2026-03-24T18:09:13.422Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-4VQ8-7JFC-9CVP
Vulnerability from github – Published: 2025-07-29 19:56 – Updated: 2026-03-27 17:37
VLAI?
Summary
Moby firewalld reload removes bridge network isolation
Details
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.
Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.
Impact
The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".
When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.
Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.
Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.
Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.
Patches
Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.
Workarounds
After reloading firewalld, either: - Restart the docker daemon, - Re-create bridge networks, or - Use rootless mode.
References
https://firewalld.org/ https://firewalld.org/documentation/howto/reload-firewalld.html
Severity ?
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 25.0.12"
},
"package": {
"ecosystem": "Go",
"name": "github.com/docker/docker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "25.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/docker/docker"
},
"ranges": [
{
"events": [
{
"introduced": "26.0.0-rc1"
},
{
"fixed": "28.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-54410"
],
"database_specific": {
"cwe_ids": [
"CWE-909"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-29T19:56:25Z",
"nvd_published_at": "2025-07-30T14:15:28Z",
"severity": "LOW"
},
"details": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as Docker, or Docker Engine.\n\nFirewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.\n\n### Impact\n\nThe iptables rules created by Docker are removed when firewalld is reloaded using, for example \"firewall-cmd --reload\", \"killall -HUP firewalld\", or \"systemctl reload firewalld\".\n\nWhen that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.\n\nOnce these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.\n\nContainers running in networks created with `--internal` or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.\n\nWhere Docker Engine is not running in the host\u0027s network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.\n\n### Patches\n\nMoby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.\n\n### Workarounds\nAfter reloading firewalld, either:\n- Restart the docker daemon,\n- Re-create bridge networks, or\n- Use rootless mode.\n\n### References\nhttps://firewalld.org/\nhttps://firewalld.org/documentation/howto/reload-firewalld.html",
"id": "GHSA-4vq8-7jfc-9cvp",
"modified": "2026-03-27T17:37:52Z",
"published": "2025-07-29T19:56:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/pull/49443"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/pull/49728"
},
{
"type": "WEB",
"url": "https://firewalld.org/documentation/howto/reload-firewalld.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/moby/moby"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moby firewalld reload removes bridge network isolation"
}
GHSA-P77J-4MVH-X3M3
Vulnerability from github – Published: 2026-03-18 20:10 – Updated: 2026-03-25 18:12
VLAI?
Summary
gRPC-Go has an authorization bypass via missing leading slash in :path
Details
Impact
What kind of vulnerability is it? Who is impacted?
It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.
The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.
Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:
1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).
The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.
Users should upgrade to the following versions (or newer): * v1.79.3 * The latest master branch.
It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:
1. Use a Validating Interceptor (Recommended Mitigation)
Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:
func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
if info.FullMethod == "" || info.FullMethod[0] != '/' {
return nil, status.Errorf(codes.Unimplemented, "malformed method name")
}
return handler(ctx, req)
}
// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization
If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.
3. Policy Hardening
Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.
Severity ?
9.1 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.79.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33186"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T20:10:29Z",
"nvd_published_at": "2026-03-20T23:16:45Z",
"severity": "CRITICAL"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIt is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.\n\nThe gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present.\n\n**Who is impacted?**\nThis affects gRPC-Go servers that meet both of the following criteria:\n1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`.\n2. Their security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule).\n\nThe vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, the issue has been patched. The fix ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.\n\nUsers should upgrade to the following versions (or newer):\n* **v1.79.3**\n* The latest **master** branch.\n\nIt is recommended that all users employing path-based authorization (especially `grpc/authz`) upgrade as soon as the patch is available in a tagged release.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nWhile upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:\n\n#### 1. Use a Validating Interceptor (Recommended Mitigation)\nAdd an \"outermost\" interceptor to your server that validates the path before any other authorization logic runs:\n\n```go\nfunc pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {\n if info.FullMethod == \"\" || info.FullMethod[0] != \u0027/\u0027 {\n return nil, status.Errorf(codes.Unimplemented, \"malformed method name\")\n } \n return handler(ctx, req)\n}\n\n// Ensure this is the FIRST interceptor in your chain\ns := grpc.NewServer(\n grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),\n)\n```\n\n#### 2. Infrastructure-Level Normalization\nIf your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the `:path` header does not start with a leading slash.\n\n#### 3. Policy Hardening\nSwitch to a \"default deny\" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.",
"id": "GHSA-p77j-4mvh-x3m3",
"modified": "2026-03-25T18:12:09Z",
"published": "2026-03-18T20:10:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
},
{
"type": "PACKAGE",
"url": "https://github.com/grpc/grpc-go"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}
GHSA-PJCQ-XVWQ-HHPJ
Vulnerability from github – Published: 2026-04-23 21:21 – Updated: 2026-04-27 16:35
VLAI?
Summary
go-ntlmssp NTLM challenges can panic on malformed payloads
Details
go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using ntlmssp.Negotiator as an HTTP transport. Version 0.1.1 patches the issue.
Severity ?
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/Azure/go-ntlmssp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32952"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:21:58Z",
"nvd_published_at": "2026-04-24T03:16:07Z",
"severity": "MODERATE"
},
"details": "go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.",
"id": "GHSA-pjcq-xvwq-hhpj",
"modified": "2026-04-27T16:35:38Z",
"published": "2026-04-23T21:21:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Azure/go-ntlmssp/security/advisories/GHSA-pjcq-xvwq-hhpj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32952"
},
{
"type": "PACKAGE",
"url": "https://github.com/Azure/go-ntlmssp"
},
{
"type": "WEB",
"url": "https://github.com/Azure/go-ntlmssp/releases/tag/v0.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "go-ntlmssp NTLM challenges can panic on malformed payloads"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…