Back to all use cases

CVE PatchingHealthcare / Benefits

Patching the version you validated, not the version upstream wants you on

Benefits Administration Provider

A regulated provider could not move its on-premises Valkey 7.2 clusters for another year. AceMQ assessed each security advisory against its configuration and backported the fixes through OSSeva.

Overview

A benefits administrator ran Valkey 7.2 behind its member portal and claims pipeline, on virtual machines in two data centres. Every application release went through a long validation cycle, and a move to Valkey 8 was scheduled for the following year.

Challenge

Security advisories kept arriving for a version the team could not upgrade in time, and every one needed an answer for the compliance team: does this affect us, and when is it fixed. Upgrading early meant revalidating client libraries and failover behaviour in the middle of an audit cycle.

Environment

Valkey 7.2 with Sentinel on RHEL virtual machines, two data centres, TLS between clients and servers, ACLs per application, Java clients on a pinned library version.

Approach

AceMQ engineers reviewed each advisory against the cluster's real configuration: the commands and scripting each ACL user could reach, whether the affected feature was enabled, and what a network attacker could actually do. Fixes for the advisories that did apply were backported to the 7.2 line through OSSeva, tested in staging with the production failover tests, and rolled out replica first.

Solution

  1. Triaged each advisory against ACL users, enabled features and network exposure, with a written exposure note per advisory
  2. Backported the fixes that applied to the 7.2 line through OSSeva and built them for the customer's operating system
  3. Ran the production failover and client test suite against each patched build in staging
  4. Rolled out replica first under the customer's existing change process, with a rehearsed rollback
  5. Applied interim mitigations, such as tighter ACLs on scripting, while a build was being tested
  6. Built the Valkey 8 upgrade plan alongside, with client library checks, so the move could be scheduled instead of forced

Outcome

Each advisory had a written answer within the compliance team's review window, and the patched builds went in through normal change control. The Valkey 8 upgrade stayed on its own schedule rather than being pulled forward by a security notice.

Technologies

ValkeyLinuxRedis Sentinel

Have a Valkey Challenge Like This?

AceMQ's senior Valkey engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.