critical

CVE-2022-35951

redis: heap overflow in XAUTOCLAIM command's COUNT argument

Published 23 Sep 2022Modified 17 Jun 2026CWE 190

In the Trivy database since at least 24 Oct 2026, 07:11 UTCWhen it arrived before that build is not recorded.

Severity by source

NVD9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Red Hat9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Bitnami9.8CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Trivy's own label is CRITICAL. Rated critical by NVD, Bitnami, Photon OS. Rated lower by Red Hat (high).

Description

Redis is an in-memory database that persists on disk. Versions 7.0.0 and above, prior to 7.0.5 are vulnerable to an Integer Overflow. Executing an `XAUTOCLAIM` command on a stream key in a specific state, with a specially crafted `COUNT` argument may cause an integer overflow, a subsequent heap overflow, and potentially lead to remote code execution. This has been patched in Redis version 7.0.5. No known workarounds exist.

Affected packages and fixed versions

Source	Package	Fixed in
bitnami::Bitnami Vulnerability Database	keydb, redis, valkey	7.0.5
Photon OS 4.0	redis	7.0.0-4.ph4
alpine 3.16	redis	7.0.5-r0
alpine 3.17	redis	7.0.5-r0
alpine 3.18	redis	7.0.5-r0
alpine 3.19	redis	7.0.5-r0
alpine 3.20	redis	7.0.5-r0
alpine 3.21	redis	7.0.5-r0
alpine 3.22	redis	7.0.5-r0
alpine 3.23	redis	7.0.5-r0
alpine 3.24	redis	7.0.5-r0
alpine edge	redis	7.0.5-r0

Show all 18 entries from 16 sources

Source	Package	Fixed in
bitnami::Bitnami Vulnerability Database	keydb	7.0.5
bitnami::Bitnami Vulnerability Database	redis	7.0.5
bitnami::Bitnami Vulnerability Database	valkey	7.0.5
Photon OS 4.0	redis	7.0.0-4.ph4
alpine 3.16	redis	7.0.5-r0
alpine 3.17	redis	7.0.5-r0
alpine 3.18	redis	7.0.5-r0
alpine 3.19	redis	7.0.5-r0
alpine 3.20	redis	7.0.5-r0
alpine 3.21	redis	7.0.5-r0
alpine 3.22	redis	7.0.5-r0
alpine 3.23	redis	7.0.5-r0
alpine 3.24	redis	7.0.5-r0
alpine edge	redis	7.0.5-r0
debian 12	redis	5:7.0.5-1
debian 13	redis	5:7.0.5-1
debian 14	redis	5:7.0.5-1
echo	redis	5:7.0.5-1

References

What Attestkeep does with this

Inside your cluster, without you opening a spreadsheet.

KnowsThe scanner refreshes its vulnerability database every six hours.

FindsEvery admitted image is rescanned every 24 hours by default (scan.rescanInterval). When Trivy rates this vulnerability critical for the image's package source, it appears in the image's findings by name. Findings without a fix are left out unless includeUnfixed is on.

Tells youA critical_finding event goes to the channels subscribed to it: e-mail, Slack, Teams, a webhook, Jira, GitLab or GitHub.

RefusesWith a policy that blocks critical findings, a pod with this image is refused at admission, a rollback to it included. Pods already running are not evicted.

RecordsEach decision is recorded with the policy that ran and its hash, then sealed under a signed checkpoint.

Try Attestkeep

Read the docs