Knowledge Base

Problem:

A client planned a rolling patch upgrade of a 5-node Apache Cassandra 4.1.x cluster running on cloud VMs, combined with a minor RHEL 9.x OS update. They submitted their runbook for review and asked whether the OS update affected JVM and Python support, whether there were known compatibility issues, and whether the plan carried any risks.

Process:

Step 1: Review the runbook

We reviewed the client’s procedure: pre-upgrade config backups and snapshots, a per-node drain/stop/replace/start cycle, a manual config merge, repair, health checks, and a final sstable upgrade.

Step 2: Check the target version

A newer patch release was available in the 4.1 line, so we recommended targeting the latest patch instead of the version originally planned.

Step 3: Assess compatibility

We found no reported breaking changes between the current and target Cassandra patch versions, and no known issues with the RHEL 9.x minor update.

Step 4: Correct the upgrade order

The plan upgraded non-seed nodes first and seed nodes last, which is the opposite of the official guidance. We recommended starting with the seed node.

Step 5: Simplify config handling

Because this was a patch upgrade with no config changes, a line-by-line merge was unnecessary. We advised keeping a copy of the new default configs for reference and reusing the existing config set as is.

Step 6: Refine post-upgrade maintenance

We clarified that the sstable upgrade is optional for a patch release but recommended running it node by node once the whole cluster is upgraded. We also advised running routine repair after the upgrade on one node at a time.

Step 7: Validate the revised plan

The client updated the runbook with these recommendations and added a rollback procedure. We reviewed the revised version and confirmed it.

Solution:

The client received a validated runbook covering: an upgrade to the latest 4.1.x patch, a seed-first rolling order with health verification before each next node, reuse of the existing configuration, sequential repair after the upgrade, a node-by-node sstable upgrade once the cluster is stable, and a rollback path.

Conclusion:

The review fixed the node order, removed an unnecessary and error-prone config merge, and enforced sequential maintenance operations. The client now has a lower-risk, confirmed upgrade plan, and standby support was offered for the implementation window.

In Appwrite versions up to 2.3.0 a medium severity vulnerability CVE-2026-108770 was detected. This vulnerability allows a remote attacker to perform Server-Side Request Forgery (SSRF) attacks, potentially gaining unauthorized access to internal network resources or services. This occurs due to a flaw in the PublicHostname function within the src/Appwrite/Platform/Modules/Avatars/Http/Screenshots/Get.php file of the Browser Screenshot Service component. By manipulating the url argument, an attacker can trick the server into making unintended outbound HTTP requests on their behalf. To address this issue, users should upgrade Appwrite to version 2.4.0 or later, or apply the official patch (commit 393255e7302ae5503331d45802e2eee01c6a47fe). For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-108770.

In Django versions from 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7 a low severity vulnerability CVE-2025-59682 was detected. This vulnerability allows for partial directory traversal, potentially leading to unauthorized file writes outside the intended target directory. This occurs due to a flaw in the django.utils.archive.extract() function, which is utilized when developers run the startapp --template and startproject --template management commands. If a developer uses a maliciously crafted archive where file paths share a common prefix with the target directory, the extraction process can escape the intended extraction path. To address this issue, users should upgrade Django to versions 4.2.25, 5.1.13, 5.2.7, or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2025-59682.

In Argo Workflows versions prior to 3.6.12, and from 3.7.0 before 3.7.3 a high severity vulnerability CVE-2025-62157 was detected. This vulnerability allows an attacker with permissions to read pod logs in the Argo Workflows namespace to obtain plaintext credentials to the artifact repository, potentially leading to unauthorized access and data compromise. This occurs because the workflow-controller improperly exposes sensitive artifact repository credentials in plaintext within its pod logs. By inspecting these logs, an attacker can extract the exposed secrets. There are no known workarounds for this issue. To address this vulnerability, users must upgrade Argo Workflows to versions 3.6.12, 3.7.3, or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2025-62157.

In Budibase versions prior to 3.41.3 a high severity vulnerability CVE-2026-82240 was detected. This vulnerability allows an authenticated app-scoped builder to escalate their privileges and gain unauthorized builder access to unrelated applications within the same tenant. This occurs due to inadequate validation of app-scoped builder role assignments in the public user create and update API endpoints. By submitting a specially crafted request containing manipulated builder.apps fields to the user update API, an attacker can bypass intended access controls and improperly grant builder rights to other applications. To address this issue, users should upgrade Budibase to version 3.41.3 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-82240.

In Argo CD versions from 2.10.0 prior to 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2 a critical severity vulnerability CVE-2026-77459 was detected. This vulnerability allows an attacker with write access to an Application’s Git repository to bypass destination and resource authorization checks, potentially creating unauthorized resources within the Kubernetes cluster. This occurs because Argo CD creates PostDelete resource hooks without applying the standard AppProject allow/deny lists used during normal synchronization. By committing a maliciously crafted delete hook targeting a forbidden namespace, server, group, or kind, the attacker can force the application-controller to create that resource using its destination-cluster credentials when the Application is deleted. While the impact is bounded by the controller’s own access rights, it can lead to the compromise of cluster-scoped resources and disallowed namespaces. To address this issue, users should upgrade Argo CD to versions 3.3.15, 3.4.10, 3.5.4, 3.6.0-rc2, or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-77459.