Thinkst Patches Canary Redis Denial of Service
Tech GuruQuick Answer
Thinkst's TC-2026-01 addresses CVE-2026-85220, an unauthenticated denial of service in the Canary honeypot's Redis service. Canaries with Redis disabled are not affected. Use the platform-specific fix below: GCP requires 5.4.2, while AWS and Tailscale use 5.3.2; Docker requires a new image and redeployment.
Confirm Scope And Apply The Supported Fix
What to do now: Check whether Redis is enabled on each Canary, record its platform and version, and confirm the corresponding update is installed. Automatic update distribution is not proof of installation; verify device status in the Console. Docker operators must deploy the fixed image.
Last verified: 2026-09-21 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | Thinkst Canary platforms with Redis enabled, beginning at the platform-specific first vulnerable releases |
|---|---|
| Advisory | TC-2026-01 |
| CVE | CVE-2026-85220 |
| CVE record publication | 2026-09-21 13:13:53.053 UTC |
| CVE record revision (snapshot) | 2026-09-21 14:48:17.169 UTC |
| First affected versions (Redis enabled) | AWS EC2 2.0.2; Docker 3.7.1; GCP 2.2.3; Hardware 1.0; Azure 2.2.9; Hyper-V 2.3.2; Nutanix 4.9.0; OCI 3.11.10; OpenStack 3.8.9; Tailscale 2.2.1; VMware ESXi 2.0.2. Each interval ends before that platform's first fixed version below. |
| Fixed version | AWS/Tailscale 5.3.2; GCP 5.4.2; Docker 5.7.2; Hardware 5.1.2; Azure 5.6.4; Hyper-V 5.5.2; Nutanix 5.9.2; OCI 5.11.2; OpenStack 5.8.2; VMware 5.2.2 |
| CVSS base score | 3.7 (CVSS v3.1) |
| CVSS severity | Low |
| Exploitation status | Thinkst's September 21 advisory states that it was unaware of public announcements or malicious use. This is the vendor's report, not proof that no exploitation has occurred. |
What Changed
During an attack, the Canary can become unresponsive and then reboot itself within several minutes; continued disruption requires continued attack traffic. The affected component is the honeypot's Redis service, not a general advisory for all Redis servers. A Canary with Redis disabled is not affected.
Thinkst first published this advisory on September 21, 2026. Update files are supplied for supported non-Docker platforms; Docker uses a replacement image. Where an update cannot yet be applied, disabling Redis is the stated workaround. Verify the actual installed version and monitoring state rather than assuming that an update being distributed has completed.
What To Validate Now
- Inventory. Record each Canary's platform, running version, Redis service setting, automatic-update setting, and monitoring owner.
- Establish applicability. Redis must be enabled. Compare the platform's first affected version and first fixed version; do not compare version numbers across platforms.
- Remediate. For non-Docker Canaries, confirm automatic installation or use Console Updates for manual installation. For Docker, update the configured image tag to
5.7.2and redeploy through the supported process. If updating must wait, the vendor workaround is to disable Redis; record the resulting loss of that honeypot service. - Validate. Confirm the device shows up-to-date in the Console and the running platform version matches the fix. For Docker, verify the replacement container uses the fixed image. Check approved monitoring and alert-delivery functions.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
The first fixed version is platform-specific; GCP's fix is not the AWS build. Disabling Redis avoids this vulnerability but removes that service from the honeypot. Coordinate the monitoring change and preserve outage evidence; a Low score does not mean an unresponsive Canary can still provide detection.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
