{"id":"CVE-2024-51744","aliases":["AZL-52171","AZL-52174","AZL-52180","AZL-52183","AZL-52186","AZL-52189","AZL-52192","AZL-52195","AZL-52198","AZL-52201","AZL-52204","AZL-52207","AZL-52210","AZL-52213","AZL-52216","AZL-52219","AZL-52221","AZL-52224","AZL-52227","AZL-52230","AZL-52233","AZL-52236","AZL-52239","AZL-52242","AZL-52248","AZL-52251","AZL-52254","AZL-52257","AZL-52260","AZL-52265","AZL-52266","AZL-52272","AZL-52275","AZL-52278","DEBIAN-CVE-2024-51744","EUVD-2024-3178","GHSA-29wx-vh33-7x7r","GO-2024-3250","RHSA-2026:2769","SUSE-SU-2024:4042-1","SUSE-SU-2025:01985-1","SUSE-SU-2025:0524-1","SUSE-SU-2025:0525-1","SUSE-SU-2025:0546-1","SUSE-SU-2025:1333-1","UBUNTU-CVE-2024-51744","openSUSE-SU-2024:14481-1","openSUSE-SU-2024:14484-1","openSUSE-SU-2024:14495-1","openSUSE-SU-2024:14517-1","openSUSE-SU-2024:14522-1","openSUSE-SU-2025:0131-1","openSUSE-SU-2025:14663-1","openSUSE-SU-2025:14768-1","openSUSE-SU-2025:14840-1","openSUSE-SU-2025:14988-1","openSUSE-SU-2025:20117-1","openSUSE-SU-2026:12270-1","openSUSE-SU-2026:12297-1","openSUSE-SU-2026:12300-1","openSUSE-SU-2026:20099-1","openSUSE-SU-2026:20620-1","openSUSE-SU-2026:20654-1","openSUSE-SU-2026:20798-1"],"status":"published","title":"Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","severity":{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00585,"percentile":0.48399,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-347","CWE-755"],"published":"2024-11-04T21:47:12Z","modified":"2026-11-05T05:40:51Z","fixes":[{"ecosystem":"Go","package":"github.com/golang-jwt/jwt/v4","fixed_in":["4.5.1"],"sources":["ghsa","osv"]},{"ecosystem":"Azure Linux:3","package":"coredns","fixed_in":["1.11.4-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"azcopy","fixed_in":["10.25.1-4"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"cert-manager","fixed_in":["1.12.15-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"flannel","fixed_in":["0.24.2-13"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"packer","fixed_in":["1.9.5-9"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"influxdb","fixed_in":["2.7.5-4"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"application-gateway-kubernetes-ingress","fixed_in":["1.7.7-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"dcos-cli","fixed_in":["1.2.0-18"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"keda","fixed_in":["2.14.1-7"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"kubernetes","fixed_in":["1.30.10-5"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"telegraf","fixed_in":["1.31.0-7"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"prometheus","fixed_in":["2.45.4-12"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"jx","fixed_in":["3.10.182-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"etcd","fixed_in":["3.5.18-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"moby-engine","fixed_in":["25.0.3-13"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"moby-engine","fixed_in":["24.0.9-17"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"influxdb","fixed_in":["2.6.1-22"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"kube-vip-cloud-provider","fixed_in":["0.0.2-22"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"coredns","fixed_in":["1.11.1-18"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"packer","fixed_in":["1.9.5-12"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"etcd","fixed_in":["3.5.21-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"keda","fixed_in":["2.4.0-29"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"rook","fixed_in":["1.6.2-26"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"application-gateway-kubernetes-ingress","fixed_in":["1.4.0-25"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"cf-cli","fixed_in":["8.4.0-24"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"jx","fixed_in":["3.2.236-21"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"cert-manager","fixed_in":["1.11.2-22"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"azcopy","fixed_in":["10.25.1-5"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"dcos-cli","fixed_in":["1.2.0-21"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"prometheus","fixed_in":["2.37.9-4"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"kubevirt","fixed_in":["0.59.0-27"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"kubernetes","fixed_in":["1.28.4-17"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"telegraf","fixed_in":["1.29.4-15"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"golang-github-golang-jwt-jwt","fixed_in":["5.0.0+really4.5.2-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"golang-github-golang-jwt-jwt","fixed_in":["5.0.0+really4.5.2-1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"golang-github-prometheus-prometheus","fixed_in":["2.53.3-150100.4.23.1"],"sources":["osv"]},{"ecosystem":"SUSE:Manager Proxy Module 4.3","package":"golang-github-prometheus-prometheus","fixed_in":["2.53.3-150100.4.23.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"golang-github-prometheus-prometheus","fixed_in":["2.53.3-150100.4.23.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"coredns","fixed_in":["1.11.3+git129.387f34d-1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","fixed_in":["0.0.20241112T145010-1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"rclone","fixed_in":["1.68.1-2.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"traefik2","fixed_in":["2.11.14-1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"traefik","fixed_in":["3.2.1-1.1"],"sources":["osv"]},{"ecosystem":"SUSE:Package Hub 15 SP6","package":"coredns","fixed_in":["1.12.1-bp156.4.6.5"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"coredns","fixed_in":["1.12.1-bp156.4.6.5"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"grafana","fixed_in":["11.5.1-1.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/golang-jwt/jwt/v4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.5.1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.4-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"azcopy","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.25.1-4"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"nmi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.8.17-6"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"cert-manager","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.12.15-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"flannel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.24.2-13"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"packer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.5-9"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"influxdb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.7.5-4"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"application-gateway-kubernetes-ingress","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.7.7-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"dcos-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.0-18"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"keda","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.14.1-7"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"kubernetes","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.30.10-5"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"telegraf","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.31.0-7"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.45.4-12"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"jx","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.10.182-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"etcd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.5.18-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"moby-engine","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.0.3-13"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"moby-engine","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"24.0.9-17"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"influxdb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.6.1-22"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kube-vip-cloud-provider","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.2-22"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.1-18"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"packer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.5-12"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"etcd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.5.21-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"keda","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.4.0-29"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"rook","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.2-26"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"application-gateway-kubernetes-ingress","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.0-25"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"cf-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"8.4.0-24"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"jx","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.236-21"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"cert-manager","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.2-22"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"azcopy","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.25.1-5"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"dcos-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.0-21"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.37.9-4"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.59.0-27"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kubernetes","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.28.4-17"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"telegraf","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.29.4-15"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.4.3-1","5.0.0+really4.5.0-1","5.0.0+really4.5.0-1~exp1","5.0.0+really4.5.0-2","5.0.0+really4.5.2-1","5.0.0-1"]},{"source":"osv","ecosystem":"Debian:13","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.0+really4.5.2-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.0+really4.5.2-1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/golang-jwt/jwt/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.5.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/golang-jwt/jwt/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.5.1"}]}]},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-base","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-base-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-common-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-debugsource","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-exporter-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-fuse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-fuse-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-immutable-object-cache","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-immutable-object-cache-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-mds-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-mgr-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-mib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-mon-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-osd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-radosgw-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-resource-agents","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-selinux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"ceph-test-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"cephfs-mirror-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"cephfs-top","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libcephfs-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libcephfs2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libcephfs2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libcephsqlite-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librados-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librados-devel-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librados2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librados2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libradospp-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libradosstriper1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"libradosstriper1-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librbd-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librbd1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librbd1-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librgw-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librgw2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"librgw2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-ceph-argparse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-ceph-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-cephfs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-cephfs-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rados","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rados-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rbd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rbd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rgw","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"python3-rgw-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"rbd-fuse-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"rbd-mirror-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"rbd-nbd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el8","package":"rbd-nbd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el8cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-base","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-base-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-common-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-debugsource","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-exporter-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-fuse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-fuse-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-immutable-object-cache","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-immutable-object-cache-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-mds-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-mgr-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-mib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-mon-client-nvmeof-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-mon-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-osd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-radosgw-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-resource-agents","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-selinux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"ceph-test-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"cephadm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"cephfs-mirror-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"cephfs-top","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libcephfs-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libcephfs2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libcephfs2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libcephsqlite-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librados-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librados-devel-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librados2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librados2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libradospp-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libradosstriper1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"libradosstriper1-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librbd-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librbd1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librbd1-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librgw-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librgw2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"librgw2-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-ceph-argparse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-ceph-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-cephfs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-cephfs-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rados","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rados-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rbd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rbd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rgw","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"python3-rgw-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"rbd-fuse-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"rbd-mirror-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"rbd-nbd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:ceph_storage:7.1::el9","package":"rbd-nbd-debuginfo","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2:18.2.1-381.el9cp"}]}],"bundled":11},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP5","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.5","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Server 4.3","package":"release-notes-susemanager","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.3.15.2-150400.3.133.1"}]}],"bundled":15},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"golang-github-prometheus-prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.53.3-1.56.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"golang-github-prometheus-promu","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.17.0-1.24.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"grafana","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.4.13-1.66.2"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"spacecmd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.11-38.153.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-6.25.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"supportutils-plugin-susemanager-client","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.4-6.33.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 12","package":"uyuni-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.28-1.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"dracut-saltboot","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.1728559936.c16d4fb-150000.1.56.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"golang-github-prometheus-prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.53.3-150000.3.59.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"grafana","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.4.13-150000.1.66.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"spacecmd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.11-150000.3.130.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"supportutils-plugin-susemanager-client","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.4-150000.3.27.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools 15","package":"uyuni-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.28-150000.1.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools for SLE Micro 5","package":"dracut-saltboot","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.1728559936.c16d4fb-150000.1.56.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Client Tools for SLE Micro 5","package":"uyuni-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.28-150000.1.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP6","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"golang-github-prometheus-promu","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.17.0-150000.3.24.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP3-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP3-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP3","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Proxy 4.3","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Manager Server 4.3","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Enterprise Storage 7.1","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"dracut-saltboot","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.1.1728559936.c16d4fb-150000.1.56.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"golang-github-prometheus-promu","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.17.0-150000.3.24.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"spacecmd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.11-150000.3.130.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"supportutils-plugin-salt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.3-150000.3.16.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"supportutils-plugin-susemanager-client","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.0.4-150000.3.27.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"golang-github-prometheus-prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.53.3-150100.4.23.1"}]}]},{"source":"osv","ecosystem":"SUSE:Manager Proxy Module 4.3","package":"golang-github-prometheus-prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.53.3-150100.4.23.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"golang-github-prometheus-prometheus","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.53.3-150100.4.23.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP6","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Manager Proxy 4.3","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Manager Server 4.3","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-150400.3.27.1"}]}],"bundled":6},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.1.0-1","4.1.0-2","4.2.0-1","4.2.0-1ubuntu0.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.4.3-1build1","5.0.0+really4.5.0-1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"golang-github-golang-jwt-jwt-v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.2.0-2"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0+really4.5.2-1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"golang-github-golang-jwt-jwt-v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.2.2-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0+really4.5.2-1build1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"golang-github-golang-jwt-jwt-v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.3.0-1","5.3.1-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"golang-github-golang-jwt-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.0.0+really4.5.2-1","5.0.0+really4.5.2-1build1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"golang-github-golang-jwt-jwt-v5","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["5.2.2-1","5.3.0-1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.3+git129.387f34d-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"rclone","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.68.1-2.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"traefik2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.11.14-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"traefik","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.1-1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Package Hub 15 SP6","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.12.1-bp156.4.6.5"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.12.1-bp156.4.6.5"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"velociraptor","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.7.0.4.git142.862ef23-1.1"}]}],"bundled":27},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"grafana","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"11.5.1-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"trivy","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.59.1-1.1"}]}],"bundled":2},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"cosign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-1.1"}]}],"bundled":6},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"flannel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.28.10-1.1"}]}],"bundled":4},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"kubectl-retina","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.1-1.1"}]}],"bundled":11},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"kumactl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.0.0-1.1"}]}],"bundled":14},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"coredns","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.14.0-bp160.1.1"}]}],"bundled":4}],"products":[{"vendor":"golang-jwt","product":"jwt"}],"references":[{"url":"https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r","tags":["x_refsource_CONFIRM","advisory","web","article","report"]},{"url":"https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c","tags":["x_refsource_MISC","fix","web","article","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-51744","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-29wx-vh33-7x7r"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/51xxx/CVE-2024-51744.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2024-51744","tags":["advisory"]},{"url":"https://github.com/golang-jwt/jwt","tags":["package"]},{"url":"https://access.redhat.com/errata/RHSA-2026:2769","tags":["advisory"]},{"url":"https://access.redhat.com/security/updates/classification/#important","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=1944286","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2112230","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2272997","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2273911","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2312579","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2323735","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2329426","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2345695","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2360974","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2372611","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2374412","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2389907","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2392386","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2392861","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2404076","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2404656","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2404880","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2412237","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2412474","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2414844","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2414943","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2416314","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2418462","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2428617","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2432069","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_2769.json","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2021-23358","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2021-23358","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2021-23358","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2022-34749","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2022-34749","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2022-34749","tags":["advisory"]},{"url":"https://github.com/lepture/mistune/commit/a6d43215132fe4f3d93f8d7e90ba83b16a0838b2","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2024-11831","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-11831","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-11831","tags":["advisory"]},{"url":"https://github.com/yahoo/serialize-javascript/commit/f27d65d3de42affe2aac14607066c293891cec4e","tags":["article"]},{"url":"https://github.com/yahoo/serialize-javascript/pull/173","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2024-31884","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-31884","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-31884","tags":["advisory"]},{"url":"https://github.com/ceph/ceph/pull/66089","tags":["article"]},{"url":"https://github.com/ceph/ceph/pull/66140","tags":["article"]},{"url":"https://github.com/ceph/ceph/pull/66141","tags":["article"]},{"url":"https://github.com/ceph/ceph/pull/66142","tags":["article"]},{"url":"https://github.com/ceph/ceph/security/advisories/GHSA-xj9f-7g59-m4jx","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2024-47866","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-47866","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47866","tags":["advisory"]},{"url":"https://github.com/ceph/ceph/security/advisories/GHSA-mgrm-g92q-f8h8","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2024-51744","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-51744","tags":["advisory","report"]},{"url":"https://access.redhat.com/security/cve/CVE-2024-55565","tags":["report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2331063","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-55565","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-55565","tags":["advisory"]},{"url":"https://github.com/ai/nanoid/compare/3.3.7...3.3.8","tags":["article"]},{"url":"https://github.com/ai/nanoid/pull/510","tags":["article"]},{"url":"https://github.com/ai/nanoid/releases/tag/5.0.9","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2025-26791","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-26791","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-26791","tags":["advisory"]},{"url":"https://ensy.zip/posts/dompurify-323-bypass/","tags":["article"]},{"url":"https://github.com/cure53/DOMPurify/commit/d18ffcb554e0001748865da03ac75dd7829f0f02","tags":["article"]},{"url":"https://github.com/cure53/DOMPurify/releases/tag/3.2.4","tags":["article"]},{"url":"https://nsysean.github.io/posts/dompurify-323-bypass/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2025-47913","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-47913","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-47913","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-hcg3-q754-cr77","tags":["advisory"]},{"url":"https://go.dev/cl/700295","tags":["article"]},{"url":"https://go.dev/issue/75178","tags":["article"]},{"url":"https://pkg.go.dev/vuln/GO-2025-4116","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2025-52555","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-52555","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-52555","tags":["advisory"]},{"url":"https://github.com/ceph/ceph/pull/60314","tags":["article"]},{"url":"https://github.com/ceph/ceph/security/advisories/GHSA-89hm-qq33-2fjm","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2025-61729","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-61729","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-61729","tags":["advisory"]},{"url":"https://go.dev/cl/725920","tags":["article"]},{"url":"https://go.dev/issue/76445","tags":["article"]},{"url":"https://groups.google.com/g/golang-announce/c/8FJoBkPddm4","tags":["article"]},{"url":"https://pkg.go.dev/vuln/GO-2025-4155","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2024/suse-su-20244042-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2024-10389","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-10975","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45794","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-48057","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51735","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51744","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51746","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202501985-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2023-45288","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-11741","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45337","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45339","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-47535","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-9264","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-9476","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22870","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22872","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-2703","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-27144","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-3454","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-3580","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-4123","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20250524-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1212641","tags":["report"]},{"url":"https://bugzilla.suse.com/1219912","tags":["report"]},{"url":"https://bugzilla.suse.com/1229079","tags":["report"]},{"url":"https://bugzilla.suse.com/1229104","tags":["report"]},{"url":"https://bugzilla.suse.com/1231024","tags":["report"]},{"url":"https://bugzilla.suse.com/1231497","tags":["report"]},{"url":"https://bugzilla.suse.com/1231568","tags":["report"]},{"url":"https://bugzilla.suse.com/1231759","tags":["report"]},{"url":"https://bugzilla.suse.com/1232575","tags":["report"]},{"url":"https://bugzilla.suse.com/1232769","tags":["report"]},{"url":"https://bugzilla.suse.com/1232817","tags":["report"]},{"url":"https://bugzilla.suse.com/1232970","tags":["report"]},{"url":"https://bugzilla.suse.com/1233202","tags":["report"]},{"url":"https://bugzilla.suse.com/1233279","tags":["report"]},{"url":"https://bugzilla.suse.com/1233630","tags":["report"]},{"url":"https://bugzilla.suse.com/1233660","tags":["report"]},{"url":"https://bugzilla.suse.com/1234123","tags":["report"]},{"url":"https://bugzilla.suse.com/1234554","tags":["report"]},{"url":"https://bugzilla.suse.com/1235145","tags":["report"]},{"url":"https://bugzilla.suse.com/1236301","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2023-3128","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-6152","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-22037","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-6837","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-8118","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20250525-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20250546-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20251333-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1227031","tags":["report"]},{"url":"https://bugzilla.suse.com/1232985","tags":["report"]},{"url":"https://bugzilla.suse.com/1237682","tags":["report"]},{"url":"https://bugzilla.suse.com/1238693","tags":["report"]},{"url":"https://bugzilla.suse.com/1239204","tags":["report"]},{"url":"https://bugzilla.suse.com/1239337","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-6104","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22868","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22869","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2024-51744","tags":["report"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/FRQMZTGDFOBRPKL5LYFU2R55SK6DBIPC/","tags":["advisory"]},{"url":"","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/Z2Z4KRNR3L2CXM6VPBBBFXIJ2NM4JPWE/","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/K5YH6ZA2JQ3Z35FVNJRKHS4UMH5RMAUJ/","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/2VWEFHGRWATJW5MOESA3XEER2UJZLJOD/","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/EUVFYQAJREBRWHGVJH4PINWMTHG2NH7G/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1239294","tags":["report"]},{"url":"https://bugzilla.suse.com/1239728","tags":["report"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/IL7QOYRPFRGRS6UKU6ZYHI76FWFFUJNK/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2023-1732","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-44270","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-45133","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-45683","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-46234","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-21538","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-23331","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-24786","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-28180","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-31207","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-37298","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-4067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-4068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-42459","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-42460","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-42461","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45296","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45338","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45811","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45812","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-47068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-47875","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-48948","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-48949","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-55565","tags":["web"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/6G3C2BVUXSTIXS4W727LQ5WT3V2NAP27/","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/IQWUH5CIGBJCVZRE6D76AYCLT3MS47XX/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1227010","tags":["report"]},{"url":"https://bugzilla.suse.com/1232948","tags":["report"]},{"url":"https://bugzilla.suse.com/1234512","tags":["report"]},{"url":"https://bugzilla.suse.com/1235265","tags":["report"]},{"url":"https://bugzilla.suse.com/1237618","tags":["report"]},{"url":"https://bugzilla.suse.com/1239225","tags":["report"]},{"url":"https://bugzilla.suse.com/1239385","tags":["report"]},{"url":"https://bugzilla.suse.com/1240466","tags":["report"]},{"url":"https://bugzilla.suse.com/1241724","tags":["report"]},{"url":"https://bugzilla.suse.com/1243633","tags":["report"]},{"url":"https://bugzilla.suse.com/1246151","tags":["report"]},{"url":"https://bugzilla.suse.com/1246730","tags":["report"]},{"url":"https://bugzilla.suse.com/1248897","tags":["report"]},{"url":"https://bugzilla.suse.com/1248937","tags":["report"]},{"url":"https://bugzilla.suse.com/1250625","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-3817","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-11065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-21613","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-21614","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-30204","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-46569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47291","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58058","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-32241","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46600","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56852","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54410","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58190","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33186","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34986","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53941","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-72815","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-95838","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47911","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47913","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47914","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58181","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26958","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41178","tags":["web"]},{"url":"https://bugzilla.suse.com/1249389","tags":["report"]},{"url":"https://bugzilla.suse.com/1255345","tags":["report"]},{"url":"https://bugzilla.suse.com/1256411","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58063","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-68156","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-68161","tags":["web"]},{"url":"https://bugzilla.suse.com/1232964","tags":["report"]},{"url":"https://bugzilla.suse.com/1233422","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-52522","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-68121","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-1229","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27141","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41176","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41179","tags":["web"]},{"url":"https://bugzilla.suse.com/1231844","tags":["report"]},{"url":"https://bugzilla.suse.com/1232975","tags":["report"]},{"url":"https://bugzilla.suse.com/1233343","tags":["report"]},{"url":"https://bugzilla.suse.com/1235206","tags":["report"]},{"url":"https://bugzilla.suse.com/1235574","tags":["report"]},{"url":"https://bugzilla.suse.com/1236510","tags":["report"]},{"url":"https://bugzilla.suse.com/1236559","tags":["report"]},{"url":"https://bugzilla.suse.com/1236734","tags":["report"]},{"url":"https://bugzilla.suse.com/1237671","tags":["report"]},{"url":"https://bugzilla.suse.com/1238703","tags":["report"]},{"url":"https://bugzilla.suse.com/1241683","tags":["report"]},{"url":"https://bugzilla.suse.com/1241687","tags":["report"]},{"url":"https://bugzilla.suse.com/1241809","tags":["report"]},{"url":"https://bugzilla.suse.com/1243672","tags":["report"]},{"url":"https://bugzilla.suse.com/1243714","tags":["report"]},{"url":"https://bugzilla.suse.com/1245302","tags":["report"]},{"url":"https://bugzilla.suse.com/1246735","tags":["report"]},{"url":"https://bugzilla.suse.com/1246736","tags":["report"]},{"url":"https://bugzilla.suse.com/1250616","tags":["report"]},{"url":"https://bugzilla.suse.com/1251454","tags":["report"]},{"url":"https://bugzilla.suse.com/1251657","tags":["report"]},{"url":"https://bugzilla.suse.com/1254113","tags":["report"]},{"url":"https://bugzilla.suse.com/1255340","tags":["report"]},{"url":"https://bugzilla.suse.com/1257337","tags":["report"]},{"url":"https://bugzilla.suse.com/1257349","tags":["report"]},{"url":"https://bugzilla.suse.com/1258136","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-29923","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-3415","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6023","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6197","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64751","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-21720","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-21721","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-21722","tags":["web"]},{"url":"https://bugzilla.suse.com/1251363","tags":["report"]},{"url":"https://bugzilla.suse.com/1251547","tags":["report"]},{"url":"https://bugzilla.suse.com/1253512","tags":["report"]},{"url":"https://bugzilla.suse.com/1253786","tags":["report"]},{"url":"https://bugzilla.suse.com/1253977","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2024-51744","title":"Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T21:47:12.17Z","modified":"2024-11-05T16:11:42.243Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-755"],"updated_at":"2026-11-02T14:34:01.972857Z"}],"euvd":[{"id":"EUVD-2024-3178","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T21:47:12Z","modified":"2024-11-05T16:11:42Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"}],"updated_at":"2026-11-03T00:05:10.907442Z"}],"ghsa":[{"id":"GHSA-29wx-vh33-7x7r","title":"Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations","description":"### Summary\n\nUnclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.\n\n### Fix\n\nWe have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.\n\n### Workaround \n\nWe are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.\n\n```Go\ntoken, err := /* jwt.Parse or similar */\nif token.Valid {\n\tfmt.Println(\"You look nice today\")\n} else if errors.Is(err, jwt.ErrTokenMalformed) {\n\tfmt.Println(\"That's not even a token\")\n} else if errors.Is(err, jwt.ErrTokenUnverifiable) {\n\tfmt.Println(\"We could not verify this token\")\n} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {\n\tfmt.Println(\"This token has an invalid signature\")\n} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {\n\t// Token is either expired or not active yet\n\tfmt.Println(\"Timing is everything\")\n} else {\n\tfmt.Println(\"Couldn't handle this token:\", err)\n}\n```","status":"published","published":"2024-11-04T23:22:41Z","modified":"2024-11-12T21:32:38Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N","level":"low"},{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"}],"cwes":["CWE-347","CWE-755"],"updated_at":"2026-11-02T14:38:17.357217Z"}],"nvd":[{"id":"CVE-2024-51744","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03.997Z","modified":"2026-06-17T08:06:14.123Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low","assessor":"secondary"}],"cwes":["CWE-755"],"updated_at":"2026-11-02T14:10:35.864552Z"}],"osv":[{"id":"CVE-2024-51744","title":"Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T21:47:12.17Z","modified":"2026-10-28T17:27:14.689005762Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"}],"cwes":["CWE-755"],"updated_at":"2026-11-02T15:44:44.032344Z"},{"id":"DEBIAN-CVE-2024-51744","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03.997Z","modified":"2026-11-02T12:03:07.586400741Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"}],"updated_at":"2026-11-02T15:45:44.117337Z"},{"id":"GHSA-29wx-vh33-7x7r","title":"Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations","description":"### Summary\n\nUnclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.\n\n### Fix\n\nWe have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.\n\n### Workaround \n\nWe are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.\n\n```Go\ntoken, err := /* jwt.Parse or similar */\nif token.Valid {\n\tfmt.Println(\"You look nice today\")\n} else if errors.Is(err, jwt.ErrTokenMalformed) {\n\tfmt.Println(\"That's not even a token\")\n} else if errors.Is(err, jwt.ErrTokenUnverifiable) {\n\tfmt.Println(\"We could not verify this token\")\n} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {\n\tfmt.Println(\"This token has an invalid signature\")\n} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {\n\t// Token is either expired or not active yet\n\tfmt.Println(\"Timing is everything\")\n} else {\n\tfmt.Println(\"Couldn't handle this token:\", err)\n}\n```","status":"published","published":"2024-11-04T23:22:41Z","modified":"2026-09-10T03:50:20.232143805Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"},{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-347","CWE-755"],"updated_at":"2026-11-02T15:46:34.338541Z"},{"id":"RHSA-2026:2769","title":"Red Hat Security Advisory: Red Hat Ceph Storage 7.1 security and bug fix updates","status":"published","published":"2026-04-04T10:05:14Z","modified":"2026-10-20T10:06:52Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:19.449341Z"},{"id":"UBUNTU-CVE-2024-51744","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:00Z","modified":"2026-10-17T12:56:40.206864312Z","cvss":[{"version":"3.1","score":3.1,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","level":"low"}],"updated_at":"2026-11-02T16:55:11.182485Z"},{"id":"AZL-52171","title":"CVE-2024-51744 affecting package coredns for versions less than 1.11.4-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:48:49.09215Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52174","title":"CVE-2024-51744 affecting package azcopy for versions less than 10.25.1-4","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52180","title":"CVE-2024-51744 affecting package nmi 1.8.17-6","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:21.524374Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52183","title":"CVE-2024-51744 affecting package cert-manager for versions less than 1.12.15-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:47:39.801788Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52186","title":"CVE-2024-51744 affecting package flannel for versions less than 0.24.2-13","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52189","title":"CVE-2024-51744 affecting package packer for versions less than 1.9.5-9","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52192","title":"CVE-2024-51744 affecting package influxdb for versions less than 2.7.5-4","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52195","title":"CVE-2024-51744 affecting package application-gateway-kubernetes-ingress for versions less than 1.7.7-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:55:56.581977Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52198","title":"CVE-2024-51744 affecting package dcos-cli for versions less than 1.2.0-18","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52201","title":"CVE-2024-51744 affecting package keda for versions less than 2.14.1-7","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-10-31T15:02:25Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52204","title":"CVE-2024-51744 affecting package kubernetes for versions less than 1.30.10-5","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52207","title":"CVE-2024-51744 affecting package telegraf for versions less than 1.31.0-7","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.675084Z"},{"id":"AZL-52210","title":"CVE-2024-51744 affecting package prometheus for versions less than 2.45.4-12","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:54:46.502888Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52213","title":"CVE-2024-51744 affecting package jx for versions less than 3.10.182-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:49:10.397548Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52216","title":"CVE-2024-51744 affecting package etcd for versions less than 3.5.18-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:55:25.475894Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52219","title":"CVE-2024-51744 affecting package moby-engine for versions less than 25.0.3-13","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-10-31T15:02:25Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52221","title":"CVE-2024-51744 affecting package moby-engine for versions less than 24.0.9-17","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:22.977302Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52224","title":"CVE-2024-51744 affecting package influxdb for versions less than 2.6.1-22","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:22.85438Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52227","title":"CVE-2024-51744 affecting package kube-vip-cloud-provider for versions less than 0.0.2-22","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.311815Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52230","title":"CVE-2024-51744 affecting package coredns for versions less than 1.11.1-18","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:22.838841Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52233","title":"CVE-2024-51744 affecting package packer for versions less than 1.9.5-12","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.457441Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52236","title":"CVE-2024-51744 affecting package etcd for versions less than 3.5.21-1","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.542757Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52239","title":"CVE-2024-51744 affecting package keda for versions less than 2.4.0-29","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.26551Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52242","title":"CVE-2024-51744 affecting package rook for versions less than 1.6.2-26","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.072462Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52248","title":"CVE-2024-51744 affecting package application-gateway-kubernetes-ingress for versions less than 1.4.0-25","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.631885Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52251","title":"CVE-2024-51744 affecting package cf-cli for versions less than 8.4.0-24","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.35575Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52254","title":"CVE-2024-51744 affecting package jx for versions less than 3.2.236-21","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.738832Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52257","title":"CVE-2024-51744 affecting package cert-manager for versions less than 1.11.2-22","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.699101Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52260","title":"CVE-2024-51744 affecting package azcopy for versions less than 10.25.1-5","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.866439Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52265","title":"CVE-2024-51744 affecting package dcos-cli for versions less than 1.2.0-21","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.323984Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52266","title":"CVE-2024-51744 affecting package prometheus for versions less than 2.37.9-4","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:23.92556Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52272","title":"CVE-2024-51744 affecting package kubevirt for versions less than 0.59.0-27","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:24.115034Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52275","title":"CVE-2024-51744 affecting package kubernetes for versions less than 1.28.4-17","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:24.392963Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"AZL-52278","title":"CVE-2024-51744 affecting package telegraf for versions less than 1.29.4-15","description":"golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.","status":"published","published":"2024-11-04T22:15:03Z","modified":"2026-04-21T04:33:24.387492Z","updated_at":"2026-11-02T15:28:06.3228Z"},{"id":"GO-2024-3250","title":"Improper error handling in ParseWithClaims and bad documentation may cause dangerous situations in github.com/golang-jwt/jwt","description":"Improper error handling in ParseWithClaims and bad documentation may cause dangerous situations in github.com/golang-jwt/jwt","status":"published","published":"2024-11-12T13:55:08Z","modified":"2026-02-04T02:44:04.7503Z","updated_at":"2026-11-02T15:47:01.453823Z"},{"id":"openSUSE-SU-2024:14481-1","title":"coredns-1.11.3+git129.387f34d-1.1 on GA media","description":"These are all security issues fixed in the coredns-1.11.3+git129.387f34d-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-09T00:00:00Z","modified":"2026-02-04T02:58:10.701689Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2024:14484-1","title":"govulncheck-vulndb-0.0.20241112T145010-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20241112T145010-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-12T00:00:00Z","modified":"2026-02-04T03:55:20.092039Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2024:14495-1","title":"rclone-1.68.1-2.1 on GA media","description":"These are all security issues fixed in the rclone-1.68.1-2.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-14T00:00:00Z","modified":"2026-02-04T03:37:40.964781Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2024:14517-1","title":"traefik2-2.11.14-1.1 on GA media","description":"These are all security issues fixed in the traefik2-2.11.14-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-21T00:00:00Z","modified":"2026-02-04T03:49:59.248327Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2024:14522-1","title":"traefik-3.2.1-1.1 on GA media","description":"These are all security issues fixed in the traefik-3.2.1-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-23T00:00:00Z","modified":"2025-05-07T18:16:22.815247Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2025:0131-1","title":"Security update for coredns","description":"This update for coredns fixes the following issues:\n\n- Update to version 1.12.1:\n  * core: Increase CNAME lookup limit from 7 to 10 (#7153)\n  * plugin/kubernetes: Fix handling of pods having DeletionTimestamp set\n  * plugin/kubernetes: Revert 'only create PTR records for endpoints with \n    hostname defined'\n  * plugin/forward: added option failfast_all_unhealthy_upstreams to return \n    servfail if all upstreams are down\n  * bump dependencies, fixing boo#1239294 and boo#1239728\n\n- Update to version 1.12.0:\n  * New multisocket plugin - allows CoreDNS to listen on multiple sockets\n  * bump deps\n\n- Update to version 1.11.4:\n  * forward plugin: new option next, to try alternate upstreams when receiving\n    specified response codes upstreams on (functions like the external plugin \n    alternate)\n  * dnssec plugin: new option to load keys from AWS Secrets Manager\n  * rewrite plugin: new option to revert EDNS0 option rewrites in responses\n\n- Update to version 1.11.3+git129.387f34d:\n  * fix CVE-2024-51744 (bsc#1232991)\n    build(deps): bump github.com/golang-jwt/jwt/v4 from 4.5.0 to 4.5.1 (#6955)\n  * core: set cache-control max-age as integer, not float (#6764)\n  * Issue-6671: Fixed the order of plugins. (#6729)\n  * `root`: explicit mark `dnssec` support (#6753)\n  * feat: dnssec load keys from AWS Secrets Manager (#6618)\n  * fuzzing: fix broken oss-fuzz build (#6880)\n  * Replace k8s.io/utils/strings/slices by Go stdlib slices (#6863)\n  * Update .go-version to 1.23.2 (#6920)\n  * plugin/rewrite: Add 'revert' parameter for EDNS0 options (#6893)\n  * Added OpenSSF Scorecard Badge (#6738)\n  * fix(cwd): Restored backwards compatibility of Current Workdir (#6731)\n  * fix: plugin/auto: call OnShutdown() for each zone at its own OnShutdown() (#6705)\n  * feature: log queue and buffer memory size configuration (#6591)\n  * plugin/bind: add zone for link-local IPv6 instead of skipping (#6547)\n  * only create PTR records for endpoints with hostname defined (#6898)\n  * fix: reverter should execute the reversion in reversed order (#6872)\n  * plugin/etcd: fix etcd connection leakage when reload (#6646)\n  * kubernetes: Add useragent (#6484)\n  * Update build (#6836)\n  * Update grpc library use (#6826)\n  * Bump go version from 1.21.11 to 1.21.12 (#6800)\n  * Upgrade antonmedv/expr to expr-lang/expr (#6814)\n  * hosts: add hostsfile as label for coredns_hosts_entries (#6801)\n  * fix TestCorefile1 panic for nil handling (#6802)\n","status":"published","published":"2025-04-19T22:01:42Z","modified":"2026-02-04T03:35:24.332585Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2025:14663-1","title":"velociraptor-0.7.0.4.git142.862ef23-1.1 on GA media","description":"These are all security issues fixed in the velociraptor-0.7.0.4.git142.862ef23-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-01-17T00:00:00Z","modified":"2026-02-04T03:47:20.18775Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2025:14768-1","title":"grafana-11.5.1-1.1 on GA media","description":"These are all security issues fixed in the grafana-11.5.1-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-02-12T00:00:00Z","modified":"2026-02-04T03:13:04.873323Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2025:14840-1","title":"trivy-0.59.1-1.1 on GA media","description":"These are all security issues fixed in the trivy-0.59.1-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-02-26T00:00:00Z","modified":"2026-02-04T04:32:24.953655Z","updated_at":"2026-11-02T16:58:37.399567Z"},{"id":"openSUSE-SU-2025:14988-1","title":"cosign-2.5.0-1.1 on GA media","description":"These are all security issues fixed in the cosign-2.5.0-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-04-14T00:00:00Z","modified":"2026-02-04T02:45:13.99504Z","updated_at":"2026-11-02T16:58:37.399567Z"}]},"sources_more":{"osv":14}}