Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package gitlab-runner version 18.11.1-r0 fixes 21 vulnerabilities: ghsa-6g7g-w4f8-9c9x, ghsa-pjcq-xvwq-hhpj, ghsa-p77j-4mvh-x3m3, ghsa-pc3f-x583-g7j2, ghsa-78h2-9frx-2jm8...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "gitlab-runner"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "18.11.1-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"18.11.1-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package gitlab-runner version 18.11.1-r0 fixes 21 vulnerabilities: ghsa-6g7g-w4f8-9c9x, ghsa-pjcq-xvwq-hhpj, ghsa-p77j-4mvh-x3m3, ghsa-pc3f-x583-g7j2, ghsa-78h2-9frx-2jm8...",
"id": "CLEANSTART-2026-KJ23421",
"modified": "2026-07-30T09:34:34Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab-runner"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in gitlab-runner 18.11.1-r0",
"upstream": [
"ghsa-6g7g-w4f8-9c9x",
"ghsa-pjcq-xvwq-hhpj",
"ghsa-p77j-4mvh-x3m3",
"ghsa-pc3f-x583-g7j2",
"ghsa-78h2-9frx-2jm8",
"ghsa-hfvc-g4fc-pqhx",
"ghsa-gm2x-2g9h-ccm8",
"ghsa-jhf3-xxhw-2wpp",
"ghsa-xmrv-pmrh-hhx2",
"ghsa-3xc5-wrhm-f963",
"CVE-2026-32952",
"CVE-2026-32285",
"CVE-2026-34040",
"CVE-2026-33997",
"CVE-2026-34165",
"CVE-2026-33762",
"CVE-2026-34986",
"CVE-2026-35469",
"CVE-2026-39883",
"CVE-2026-33186",
"CVE-2026-27141"
]
}
CVE-2026-39883 (GCVE-0-2026-39883)
Vulnerability from cvelistv5 – Published: 2026-04-08 20:26 – Updated: 2026-08-14 12:04- CWE-426 - Untrusted Search Path
| URL | Tags |
|---|---|
| https://github.com/open-telemetry/opentelemetry-g… | x_refsource_CONFIRM |
| http://github.com/open-telemetry/opentelemetry-go… | x_refsource_MISC |
| https://access.redhat.com/security/cve/CVE-2026-39883 | vdb-entryx_refsource_REDHAT |
| https://bugzilla.redhat.com/show_bug.cgi?id=2456718 | issue-trackingx_refsource_REDHAT |
| https://security.access.redhat.com/data/csaf/v2/v… | x_sadp-csaf-vex |
| https://access.redhat.com/errata/RHSA-2026:54286 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:54274 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:37387 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:26257 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:26254 | vendor-advisoryx_refsource_REDHAT |
| Vendor | Product | Version | |
|---|---|---|---|
| open-telemetry | opentelemetry-go |
Affected:
>= 1.15.0, < 1.43.0
|
|
| Red Hat | multicluster engine for Kubernetes 2.8 |
Unaffected:
1781539691 , < *
(rpm)
cpe:/a:redhat:multicluster_engine:2.8::el8 |
|
| Red Hat | multicluster engine for Kubernetes 2.8 |
Unaffected:
1781539725 , < *
(rpm)
cpe:/a:redhat:multicluster_engine:2.8::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932114 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782931768 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932104 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783536000 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783535989 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783536515 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932521 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783018461 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783018421 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932812 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783537001 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932919 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783537586 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782932969 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933015 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933042 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783537392 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933235 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933251 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783537955 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933417 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783537742 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782933602 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1783019377 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782934054 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782934036 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat Openshift Data Foundation 4.22 |
Unaffected:
1782934284 , < *
(rpm)
cpe:/a:redhat:openshift_data_foundation:4.22::el9 |
|
| Red Hat | Red Hat OpenShift Workload Availability 0.3 |
Unaffected:
1785203474 , < *
(rpm)
cpe:/a:redhat:workload_availability_sbr:0.3::el9 |
|
| Red Hat | Red Hat OpenShift Workload Availability 0.8 |
Unaffected:
1785203079 , < *
(rpm)
cpe:/a:redhat:workload_availability_far:0.8::el9 |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2026-39883",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-10T20:52:34.310842Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-10T20:52:54.819Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"affected": [
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:multicluster_engine:2.8::el8"
],
"defaultStatus": "affected",
"packageName": "multicluster-engine/assisted-service-8-rhel8",
"product": "multicluster engine for Kubernetes 2.8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1781539691",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:multicluster_engine:2.8::el9"
],
"defaultStatus": "affected",
"packageName": "multicluster-engine/assisted-service-9-rhel9",
"product": "multicluster engine for Kubernetes 2.8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1781539725",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/cephcsi-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932114",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/cephcsi-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782931768",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/devicefinder-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932104",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/mcg-core-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783536000",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/mcg-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783535989",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/ocs-client-console-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783536515",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/ocs-client-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932521",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/ocs-metrics-exporter-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783018461",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/ocs-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783018421",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-blackbox-exporter-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932812",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-cli-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783537001",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-cloudnative-pg-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932919",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-console-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783537586",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-cosi-sidecar-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782932969",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-csi-addons-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933015",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-csi-addons-sidecar-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933042",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-drbd-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783537392",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-external-snapshotter-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933235",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-external-snapshotter-sidecar-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933251",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-multicluster-console-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783537955",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-multicluster-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933417",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-must-gather-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783537742",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odf-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782933602",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odr-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1783019377",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odr-volsync-plugin-mover-rhel9",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782934054",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/odr-volsync-plugin-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782934036",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:openshift_data_foundation:4.22::el9"
],
"defaultStatus": "affected",
"packageName": "odf4/rook-ceph-rhel9-operator",
"product": "Red Hat Openshift Data Foundation 4.22",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1782934284",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:workload_availability_sbr:0.3::el9"
],
"defaultStatus": "affected",
"packageName": "workload-availability/storage-based-remediation-rhel9-operator",
"product": "Red Hat OpenShift Workload Availability 0.3",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1785203474",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://catalog.redhat.com/software/containers/",
"cpes": [
"cpe:/a:redhat:workload_availability_far:0.8::el9"
],
"defaultStatus": "affected",
"packageName": "workload-availability/fence-agents-remediation-rhel9-operator",
"product": "Red Hat OpenShift Workload Availability 0.8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "1785203079",
"versionType": "rpm"
}
]
}
],
"datePublic": "2026-04-08T20:26:41.731Z",
"descriptions": [
{
"lang": "en",
"value": "A flaw was found in OpenTelemetry-Go. On BSD and Solaris platforms, a local attacker could exploit a vulnerability related to the `kenv` command. By manipulating the system\u0027s PATH environment variable, an attacker could achieve arbitrary code execution or privilege escalation, leading to a compromise of system integrity and confidentiality."
}
],
"metrics": [
{
"other": {
"content": {
"namespace": "https://access.redhat.com/security/updates/classification/",
"value": "Important"
},
"type": "Red Hat severity rating"
}
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-426",
"description": "Untrusted Search Path",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-14T12:04:38.343Z",
"orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"shortName": "redhat-SADP"
},
"references": [
{
"tags": [
"vdb-entry",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/security/cve/CVE-2026-39883"
},
{
"name": "RHBZ#2456718",
"tags": [
"issue-tracking",
"x_refsource_REDHAT"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2456718"
},
{
"tags": [
"x_sadp-csaf-vex"
],
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-39883.json"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:54286"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:54274"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:37387"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:26257"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:26254"
}
],
"solutions": [
{
"lang": "en",
"value": "RHSA-2026:54286: Red Hat OpenShift Workload Availability 0.3"
},
{
"lang": "en",
"value": "RHSA-2026:54274: Red Hat OpenShift Workload Availability 0.8"
},
{
"lang": "en",
"value": "RHSA-2026:37387: Red Hat Openshift Data Foundation 4.22"
},
{
"lang": "en",
"value": "RHSA-2026:26257: multicluster engine for Kubernetes 2.8"
},
{
"lang": "en",
"value": "RHSA-2026:26254: multicluster engine for Kubernetes 2.8"
}
],
"timeline": [
{
"lang": "en",
"time": "2026-04-08T21:01:31.690Z",
"value": "Reported to Red Hat."
},
{
"lang": "en",
"time": "2026-04-08T20:26:41.731Z",
"value": "Made public."
}
],
"title": "github.com/open-telemetry/opentelemetry-go: OpenTelemetry-Go: Arbitrary code execution via PATH hijacking on BSD/Solaris",
"x_adpType": "supplier",
"x_generator": {
"engine": "sadp-cli 1.0.0"
}
}
],
"cna": {
"affected": [
{
"product": "opentelemetry-go",
"vendor": "open-telemetry",
"versions": [
{
"status": "affected",
"version": "\u003e= 1.15.0, \u003c 1.43.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.15.0 to 1.42.0, the fix for CVE-2026-24051 changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms. This vulnerability is fixed in 1.43.0."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-426",
"description": "CWE-426: Untrusted Search Path",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-08T20:26:41.731Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hfvc-g4fc-pqhx",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hfvc-g4fc-pqhx"
},
{
"name": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0",
"tags": [
"x_refsource_MISC"
],
"url": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0"
}
],
"source": {
"advisory": "GHSA-hfvc-g4fc-pqhx",
"discovery": "UNKNOWN"
},
"title": "OpenTelemetry-Go has an incomplete fix for CVE-2026-24051: BSD kenv command not using absolute path enables PATH hijacking"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-39883",
"datePublished": "2026-04-08T20:26:41.731Z",
"dateReserved": "2026-04-07T20:32:03.010Z",
"dateUpdated": "2026-08-14T12:04:38.343Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-3XC5-WRHM-F963
Vulnerability from github – Published: 2026-04-17 22:31 – Updated: 2026-05-12 13:32Impact
go-git may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations.
If a remote repository responds to the initial /info/refs request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host.
An attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim’s repositories or other resources, depending on the scope of the credential.
Clients using go-git exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue. The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data.
Patches
Users should upgrade to v5.18.0, or v6.0.0-alpha.2, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version.
The patched versions add support for configuring followRedirects. In line with upstream behaviour, the default is now initial, while users can opt into FollowRedirects or NoFollowRedirects programmatically.
Credit
Thanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the go-git project. :bow:
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.17.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.0-alpha.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0-alpha.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41506"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-17T22:31:35Z",
"nvd_published_at": "2026-05-08T14:16:33Z",
"severity": "MODERATE"
},
"details": "### Impact\n`go-git` may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations.\n\nIf a remote repository responds to the initial `/info/refs` request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host.\n\nAn attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim\u2019s repositories or other resources, depending on the scope of the credential.\n\n**Clients using `go-git` exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue.** The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data.\n\n### Patches\nUsers should upgrade to `v5.18.0`, or `v6.0.0-alpha.2`, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported `go-git` version.\n\nThe patched versions add support for configuring [followRedirects](https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpfollowRedirects). In line with upstream behaviour, the default is now `initial`, while users can opt into `FollowRedirects` or `NoFollowRedirects` programmatically.\n\n### Credit\nThanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the `go-git` project. :bow:",
"id": "GHSA-3xc5-wrhm-f963",
"modified": "2026-05-12T13:32:21Z",
"published": "2026-04-17T22:31:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/security/advisories/GHSA-3xc5-wrhm-f963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41506"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-git/go-git"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v5.18.0"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v6.0.0-alpha.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "go-git: Credential leak via cross-host redirect in smart HTTP transport"
}
GHSA-6G7G-W4F8-9C9X
Vulnerability from github – Published: 2026-03-18 13:00 – Updated: 2026-04-27 16:35The Delete function fails to properly validate offsets when processing malformed JSON input. This can lead to a negative slice index and a runtime panic, allowing a denial of service attack.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/buger/jsonparser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32285"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T13:00:19Z",
"nvd_published_at": "2026-03-26T20:16:12Z",
"severity": "HIGH"
},
"details": "The Delete function fails to properly validate offsets when processing malformed JSON input. This can lead to a negative slice index and a runtime panic, allowing a denial of service attack.",
"id": "GHSA-6g7g-w4f8-9c9x",
"modified": "2026-04-27T16:35:20Z",
"published": "2026-03-18T13:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32285"
},
{
"type": "WEB",
"url": "https://github.com/buger/jsonparser/issues/275"
},
{
"type": "WEB",
"url": "https://github.com/golang/vulndb/issues/4514"
},
{
"type": "WEB",
"url": "https://github.com/buger/jsonparser/pull/276"
},
{
"type": "WEB",
"url": "https://github.com/buger/jsonparser/commit/a69e7e01cd4ad67bdfd3ac2c080b9212af16f4b0"
},
{
"type": "PACKAGE",
"url": "https://github.com/buger/jsonparser"
},
{
"type": "WEB",
"url": "https://github.com/buger/jsonparser/releases/tag/v1.1.2"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-4514"
},
{
"type": "WEB",
"url": "https://securityinfinity.com/research/buger-jsonparser-negative-slice-panic-dos-2026"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "github.com/buger/jsonparser has a denial of service vulnerability"
}
GHSA-78H2-9FRX-2JM8
Vulnerability from github – Published: 2026-04-03 03:28 – Updated: 2026-04-06 23:11Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.
This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.
This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.
Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).
Thanks
Thanks to Datadog's Security team for finding this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34986"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T03:28:56Z",
"nvd_published_at": "2026-04-06T17:17:11Z",
"severity": "HIGH"
},
"details": "### Impact\n\nDecrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), with the exception of `A128GCMKW`, `A192GCMKW`, and `A256GCMKW`) and the `encrypted_key` field is empty. The panic happens when `cipher.KeyUnwrap()` in `key_wrap.go` attempts to allocate a slice with a zero or negative length based on the length of the `encrypted_key`.\n\nThis code path is reachable from `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` followed by `Decrypt()` on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.\n\nThis panic is also reachable by calling `cipher.KeyUnwrap()` directly with any `ciphertext` parameter less than 16 bytes long, but calling this function directly is less common.\n\nPanics can lead to denial of service.\n\n### Fixed In\n\n4.1.4 and v3.0.5\n\n### Workarounds\n\nIf the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.\n\nIf your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).\n\n### Thanks\n\nThanks to Datadog\u0027s Security team for finding this issue.",
"id": "GHSA-78h2-9frx-2jm8",
"modified": "2026-04-06T23:11:46Z",
"published": "2026-04-03T03:28:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-78h2-9frx-2jm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34986"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-jose/go-jose"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Go JOSE Panics in JWE decryption"
}
GHSA-GM2X-2G9H-CCM8
Vulnerability from github – Published: 2026-03-30 17:05 – Updated: 2026-03-31 18:50Impact
go-git’s index decoder for format version 4 fails to validate the path name prefix length before applying it to the previously decoded path name. A maliciously crafted index file can trigger an out-of-bounds slice operation, resulting in a runtime panic during normal index parsing.
This issue only affects Git index format version 4. Earlier formats (go-git supports only v2 and v3) are not vulnerable to this issue.
An attacker able to supply a crafted .git/index file can cause applications using go-git to panic while reading the index. If the application does not recover from panics, this results in process termination, leading to a denial-of-service (DoS) condition.
Exploitation requires the ability to modify or inject a Git index file within the local repository in disk. This typically implies write access to the .git directory.
Patches
Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability.
Credit
go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.17.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33762"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T17:05:23Z",
"nvd_published_at": "2026-03-31T15:16:15Z",
"severity": "LOW"
},
"details": "### Impact\n\n`go-git`\u2019s index decoder for format version 4 fails to validate the path name prefix length before applying it to the previously decoded path name. A maliciously crafted index file can trigger an out-of-bounds slice operation, resulting in a runtime panic during normal index parsing.\n\nThis issue only affects Git index format version 4. Earlier formats (`go-git` supports only `v2` and `v3`) are not vulnerable to this issue.\n\nAn attacker able to supply a crafted `.git/index` file can cause applications using go-git to panic while reading the index. If the application does not recover from panics, this results in process termination, leading to a denial-of-service (DoS) condition.\n\nExploitation requires the ability to modify or inject a Git index file within the local repository in disk. This typically implies write access to the `.git` directory.\n\n### Patches\n\nUsers should upgrade to `v5.17.1`, or the latest `v6` [pseudo-version](https://go.dev/ref/mod#pseudo-versions), in order to mitigate this vulnerability.\n\n### Credit\n\ngo-git maintainers thank @kq5y for finding and reporting this issue privately to the `go-git` project.",
"id": "GHSA-gm2x-2g9h-ccm8",
"modified": "2026-03-31T18:50:23Z",
"published": "2026-03-30T17:05:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/security/advisories/GHSA-gm2x-2g9h-ccm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33762"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-git/go-git"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v5.17.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "go-git missing validation decoding Index v4 files leads to panic"
}
GHSA-HFVC-G4FC-PQHX
Vulnerability from github – Published: 2026-04-08 19:22 – Updated: 2026-04-09 14:29Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.
Root Cause
sdk/resource/host_id.go line 42:
if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {
Compare with the fixed Darwin path at line 58:
result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")
The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.
Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.
The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.
Attack
- Attacker has local access to a system running a Go application that imports
go.opentelemetry.io/otel/sdk - Attacker places a malicious
kenvbinary earlier in$PATH - Application initializes OpenTelemetry resource detection at startup
hostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binary- Arbitrary code executes in the context of the application
Same attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {
On FreeBSD, kenv is located at /bin/kenv.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.42.0"
},
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/sdk"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.43.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39883"
],
"database_specific": {
"cwe_ids": [
"CWE-426"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T19:22:12Z",
"nvd_published_at": "2026-04-08T21:17:00Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin `ioreg` command to use an absolute path but left the BSD `kenv` command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.\n\n## Root Cause\n\n`sdk/resource/host_id.go` line 42:\n\n if result, err := r.execCommand(\"kenv\", \"-q\", \"smbios.system.uuid\"); err == nil {\n\nCompare with the fixed Darwin path at line 58:\n\n result, err := r.execCommand(\"/usr/sbin/ioreg\", \"-rd1\", \"-c\", \"IOPlatformExpertDevice\")\n\nThe `execCommand` helper at `sdk/resource/host_id_exec.go` uses `exec.Command(name, arg...)` which searches `$PATH` when the command name contains no path separator.\n\nAffected platforms (per build tag in `host_id_bsd.go:4`): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.\n\nThe `kenv` path is reached when `/etc/hostid` does not exist (line 38-40), which is common on FreeBSD systems.\n\n## Attack\n\n1. Attacker has local access to a system running a Go application that imports `go.opentelemetry.io/otel/sdk`\n2. Attacker places a malicious `kenv` binary earlier in `$PATH`\n3. Application initializes OpenTelemetry resource detection at startup\n4. `hostIDReaderBSD.read()` calls `exec.Command(\"kenv\", ...)` which resolves to the malicious binary\n5. Arbitrary code executes in the context of the application\n\nSame attack vector and impact as CVE-2026-24051.\n\n## Suggested Fix\n\nUse the absolute path:\n\n if result, err := r.execCommand(\"/bin/kenv\", \"-q\", \"smbios.system.uuid\"); err == nil {\n\nOn FreeBSD, `kenv` is located at `/bin/kenv`.",
"id": "GHSA-hfvc-g4fc-pqhx",
"modified": "2026-04-09T14:29:41Z",
"published": "2026-04-08T19:22:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hfvc-g4fc-pqhx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39883"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking"
}
GHSA-JHF3-XXHW-2WPP
Vulnerability from github – Published: 2026-03-30 17:17 – Updated: 2026-03-31 18:50Impact
A vulnerability has been identified in which a maliciously crafted .idx file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a Denial of Service (DoS) condition.
Exploitation requires write access to the local repository's .git directory, it order to create or alter existing .idx files.
Patches
Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability.
Credit
The go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.17.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v5"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34165"
],
"database_specific": {
"cwe_ids": [
"CWE-191",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T17:17:54Z",
"nvd_published_at": "2026-03-31T15:16:17Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA vulnerability has been identified in which a maliciously crafted `.idx` file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a Denial of Service (DoS) condition.\n\nExploitation requires write access to the local repository\u0027s `.git` directory, it order to create or alter existing `.idx` files. \n\n### Patches\n\nUsers should upgrade to `v5.17.1`, or the latest `v6` [pseudo-version](https://go.dev/ref/mod#pseudo-versions), in order to mitigate this vulnerability.\n\n### Credit\n\nThe go-git maintainers thank @kq5y for finding and reporting this issue privately to the `go-git` project.",
"id": "GHSA-jhf3-xxhw-2wpp",
"modified": "2026-03-31T18:50:40Z",
"published": "2026-03-30T17:17:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/security/advisories/GHSA-jhf3-xxhw-2wpp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34165"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-git/go-git"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v5.17.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "go-git: Maliciously crafted idx file can cause asymmetric memory consumption"
}
GHSA-P77J-4MVH-X3M3
Vulnerability from github – Published: 2026-03-18 20:10 – Updated: 2026-03-25 18:12Impact
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.
{
"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-PC3F-X583-G7J2
Vulnerability from github – Published: 2026-04-16 20:44 – Updated: 2026-06-08 23:36The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
Three allocation paths in the receive side are affected:
1. SETTINGS entry count -- The SETTINGS frame reader reads a 32-bit
numSettings from the payload and allocates a slice of that size
without checking it against the declared frame length. An attacker
can set numSettings to a value far exceeding the actual payload,
triggering a large allocation before any setting data is read.
2. Header count -- parseHeaderValueBlock reads a 32-bit
numHeaders from the decompressed header block and allocates an
http.Header map of that size with no upper bound.
3. Header field size -- Individual header name and value lengths are
read as 32-bit integers and used directly as allocation sizes with
no validation.
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.
Impact
Any program that accepts SPDY connections using spdystream -- directly or through a dependent library -- is affected. A remote peer that can send SPDY frames to the service can crash the process with a single crafted SPDY control frame, causing denial of service.
Affected versions
github.com/moby/spdystream <= v0.5.0
Fix
v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
Core fixes:
- SETTINGS entry-count validation -- The SETTINGS frame reader now
checks that numSettings is consistent with the declared frame
length (numSettings <= (length-4)/8) before allocating.
- Header count limit -- parseHeaderValueBlock enforces a maximum
number of headers per frame (default: 1000).
- Header field size limit -- Individual header name and value
lengths are checked against a per-field size limit (default: 1 MiB)
before allocation.
- Connection closure on protocol error -- The connection read loop
now closes the underlying net.Conn when it encounters an
InvalidControlFrame error, preventing further exploitation on the
same connection.
Additional hardening:
- Write-side bounds checks -- All frame write methods now verify
that payloads fit within the 24-bit length field, preventing the
library from producing invalid frames.
Configurable limits:
- Callers can adjust the defaults using NewConnectionWithOptions or
the lower-level spdy.NewFramerWithOptions with functional options:
WithMaxControlFramePayloadSize, WithMaxHeaderFieldSize, and
WithMaxHeaderCount.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/moby/spdystream"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35469"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T20:44:01Z",
"nvd_published_at": "2026-04-16T22:16:37Z",
"severity": "HIGH"
},
"details": "The SPDY/3 frame parser in spdystream does not validate\nattacker-controlled counts and lengths before allocating memory. A\nremote peer that can send SPDY frames to a service using spdystream can\ncause the process to allocate gigabytes of memory with a small number of\nmalformed control frames, leading to an out-of-memory crash.\n\u00a0\nThree allocation paths in the receive side are affected:\n1. **SETTINGS entry count** -- The SETTINGS frame reader reads a 32-bit\n`numSettings` from the payload and allocates a slice of that size\nwithout checking it against the declared frame length. An attacker\ncan set `numSettings` to a value far exceeding the actual payload,\ntriggering a large allocation before any setting data is read.\n\u00a0\n2. **Header count** -- `parseHeaderValueBlock` reads a 32-bit\n`numHeaders` from the decompressed header block and allocates an\n`http.Header` map of that size with no upper bound.\n\u00a0\n3. **Header field size** -- Individual header name and value lengths are\nread as 32-bit integers and used directly as allocation sizes with\nno validation.\n\u00a0\nBecause SPDY header blocks are zlib-compressed, a small on-the-wire\npayload can decompress into attacker-controlled bytes that the parser\ninterprets as 32-bit counts and lengths. A single crafted frame is\nenough to exhaust process memory.\n## Impact\n\u00a0Any program that accepts SPDY connections using spdystream -- directly\nor through a dependent library -- is affected. A remote peer that can\nsend SPDY frames to the service can crash the process with a single\ncrafted SPDY control frame, causing denial of service.\n## Affected versions\n\u00a0`github.com/moby/spdystream` \u003c= v0.5.0\n## Fix\n\u00a0v0.5.1 addresses the receive-side allocation bugs and adds related\nhardening:\n\u00a0\n**Core fixes:**\n\u00a0\n- **SETTINGS entry-count validation** -- The SETTINGS frame reader now\nchecks that `numSettings` is consistent with the declared frame\nlength (`numSettings \u003c= (length-4)/8`) before allocating.\n\u00a0\n- **Header count limit** -- `parseHeaderValueBlock` enforces a maximum\nnumber of headers per frame (default: 1000).\n\u00a0\n- **Header field size limit** -- Individual header name and value\nlengths are checked against a per-field size limit (default: 1 MiB)\nbefore allocation.\n\u00a0\n- **Connection closure on protocol error** -- The connection read loop\nnow closes the underlying `net.Conn` when it encounters an\n`InvalidControlFrame` error, preventing further exploitation on the\nsame connection.\n\u00a0\n**Additional hardening:**\n\u00a0\n- **Write-side bounds checks** -- All frame write methods now verify\nthat payloads fit within the 24-bit length field, preventing the\nlibrary from producing invalid frames.\n\u00a0\n**Configurable limits:**\n\u00a0\n- Callers can adjust the defaults using `NewConnectionWithOptions` or\nthe lower-level `spdy.NewFramerWithOptions` with functional options:\n`WithMaxControlFramePayloadSize`, `WithMaxHeaderFieldSize`, and\n`WithMaxHeaderCount`.\n\u00a0",
"id": "GHSA-pc3f-x583-g7j2",
"modified": "2026-06-08T23:36:28Z",
"published": "2026-04-16T20:44:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35469"
},
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/commit/ef6121f62c730110bf5ae604a865a8613bfb787f"
},
{
"type": "PACKAGE",
"url": "https://github.com/moby/spdystream"
},
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/releases/tag/v0.5.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SpdyStream: DOS on CRI"
}
GHSA-PJCQ-XVWQ-HHPJ
Vulnerability from github – Published: 2026-04-23 21:21 – Updated: 2026-04-27 16:35go-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.
{
"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"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.