Most enterprise data leaders I talk to face pressure from two sides. The business expects real-time data to flow without interruption. Security and audit teams expect every component in that data path to be patched, governed, and accounted for. Caught between the two, point releases usually get deferred, and risk quietly builds in the meantime.
Striim Platform 5.4.4 removes that trade-off. It closes four High CVEs in a bundled component that rarely appears on a vulnerability register. It fixes a PostgreSQL data loss defect. It also brings mainframe Db2 for z/OS pipelines under the same governance as every other source. Here is what changed, who it affects, and how to plan the upgrade.
TL;DR: Striim Platform 5.4.4 closes four High CVEs in its bundled Kafka, brings Db2 for z/OS change data capture into the Striim UI, and resolves 54 customer-reported issues. If you run Striim Platform 5.4.x, plan the upgrade this quarter.
Briefly: What Changed, Who It Affects, What to Do
| Area | What changed in 5.4.4 | Who it affects | Action required |
|---|---|---|---|
| Security | Bundled Kafka moves from 3.9.1 to 4.3.1, resolving four High CVEs. ZooKeeper is retired; internal Kafka runs in KRaft mode only. | Security and platform teams with remediation windows | Migrate internal Kafka to KRaft before upgrading |
| Governance | Db2 for z/OS pipelines are managed in the Striim UI with Vault credentials, role-based access, and existing monitoring. | Teams replicating from Db2 for z/OS | Configure the Striim Agent for Db2 for z/OS |
| Reliability | 54 customer-reported fixes, including a PostgreSQL Reader data loss scenario on restart (DEV-57127). | Teams running PostgreSQL, BigQuery, or Kafka Writer pipelines | Review the notable fixes below |
| Spanner | UUID and UUID array columns are detected automatically in GoogleSQL and PostgreSQL dialects, including as primary keys. | Teams replicating with Google Cloud Spanner | Validate in a lower environment |
| Alerting | Email, Slack, and Microsoft Teams notifications now include the product and cluster name. | Organizations running multiple clusters | Update alert-parsing rules |
Full details: What’s New in Striim Platform 5.4.4 and the release notes.
Deferring Striim 5.4.4 Carries More Risk Than Most Point Releases
Most data platform teams defer point releases to protect stable pipelines, and usually that is the right call. Striim Platform 5.4.4 is an exception because earlier 5.4.x releases include a bundled component with four known High vulnerabilities and a documented data loss defect in PostgreSQL replication.
Both issues now have published fixes. Once a fix exists, staying on the earlier release becomes a documented risk decision that auditors and security leaders will ask you to justify.
Striim 5.4.4 Closes Four High CVEs in Its Bundled Kafka
Striim Platform 5.4.4 upgrades its bundled Kafka from 3.9.1 to 4.3.1, resolving four High CVEs reported against the earlier version. The internal Kafka server that supports persisted streams now runs only in KRaft mode, which removes ZooKeeper from the Striim footprint and reduces the number of services your team must patch and monitor.
Embedded components are a common blind spot in vulnerability management. Security teams track what they install directly, while components that ship inside another platform often surface only when a scanner flags them. Use the table below to match scanner findings against this release.
| CVE | Severity | Component | Status in 5.4.4 |
|---|---|---|---|
| CVE-2026-35554 | High | Bundled Kafka 3.9.1 | Resolved (Kafka 4.3.1) |
| CVE-2026-44249 | High | Bundled Kafka 3.9.1 | Resolved (Kafka 4.3.1) |
| CVE-2026-45416 | High | Bundled Kafka 3.9.1 | Resolved (Kafka 4.3.1) |
| CVE-2026-50010 | High | Bundled Kafka 3.9.1 | Resolved (Kafka 4.3.1) |
The change to the internal Kafka footprint, at a glance:
| Before 5.4.4 | Striim 5.4.4 | |
|---|---|---|
| Bundled Kafka version | 3.9.1 | 4.3.1 |
| Internal Kafka mode | ZooKeeper mode | KRaft mode only |
| Services to patch and monitor | Kafka plus ZooKeeper | Kafka only |
For organizations with formal remediation windows, this is the most time-sensitive reason to prioritize the release. Kafka does not support a direct move to 4.x, so complete the KRaft migration in the Upgrade Readiness section below before scheduling the change. Source: What’s New in Striim Platform 5.4.4.
Striim 5.4.4 Manages Db2 for z/OS Change Data Capture in the Striim UI
Striim Platform 5.4.4 brings Db2 for z/OS change data capture into the Striim UI. Once the Striim Agent for Db2 for z/OS is configured, teams create, modify, start, stop, and troubleshoot mainframe pipelines alongside every other source, using the same credential vault, role-based permissions, and monitoring.
Mainframe replication has traditionally operated as a separate discipline, with its own tooling, credentials, and specialists. That model concentrates both knowledge and risk. This is what changes in 5.4.4:
| Governance area | In Striim 5.4.4 |
|---|---|
| Credentials | Db2 credentials are stored in Striim Vault rather than in configuration files |
| Access control | Striim roles and permissions apply to Db2 pipelines |
| Monitoring | Agent error messages appear in the Striim UI and in existing monitoring systems |
| Failure handling | Db2 process failures propagate to Striim, so applications halt or terminate based on severity rather than failing silently |
| Syntax | DESCRIBE supports Agent properties, and SCHEMA.TABLE syntax matches Striim’s other relational adapters |
How to Bring a Db2 for z/OS Pipeline Under Striim Governance
- Configure the Striim Agent for Db2 for z/OS.
- Store the Db2 credentials in Striim Vault instead of configuration files.
- Assign Striim roles and permissions to the people who manage the pipeline.
- Create the pipeline in the Striim UI, using SCHEMA.TABLE syntax and DESCRIBE to inspect Agent properties.
- Start the pipeline and watch Agent errors in the UI and your existing monitoring.
Also in 5.4.4: Google Cloud Spanner UUID Detection
Teams replicating with Google Cloud Spanner also benefit. UUID and UUID array columns are now detected automatically in both GoogleSQL and PostgreSQL dialects, including as primary keys.
Striim 5.4.4 Resolves 54 Customer-Reported Issues, Including a PostgreSQL Data Loss Scenario
Striim Platform 5.4.4 resolves 54 customer-reported issues in addition to every fix delivered in 5.4.2. The fixes address data integrity on restart, stalled targets, applications that fail to stop cleanly, Kafka Writer backpressure, and how the UI handles backslash characters in passwords, regular expressions, and table properties. These fixes merit specific attention:
| Ticket | Area | What was fixed |
|---|---|---|
| DEV-57127 | PostgreSQL Reader | Data loss on restart when transactions from multiple sessions commit out of LSN order |
| DEV-58844 | BigQuery target | No data written to BigQuery for more than six days |
| DEV-58038, DEV-58265 | Kafka Writer | Backpressure and missing events related to Amazon MSK ACLs |
| Seven tickets | UI | Backslash escaping, including passwords that contain a backslash |
Alert notifications sent through email, Slack, or Microsoft Teams now also include the product and cluster name, which helps organizations with multiple clusters route incidents faster. This changes alert subject lines, so see the Upgrade Readiness section for what to update.
Full list: Striim Platform release notes.
Upgrade Readiness: Six Checks Before Moving to Striim 5.4.4
Most upgrades to Striim Platform 5.4.4 are routine, but several changes affect automation and environment requirements. The internal Kafka must already run in KRaft mode, ZooKeeper scripts and retired Kafka properties must be removed, alert-parsing rules must account for new subject lines, and the operating system must be certified for 5.4.x.
| # | Check | Action | Applies to |
|---|---|---|---|
| 1 | Internal Kafka mode | Migrate Striim’s internal Kafka from ZooKeeper mode to KRaft before upgrading. Kafka does not support a direct move to 4.x. | Environments running internal Kafka in ZooKeeper mode |
| 2 | ZooKeeper scripts and monitoring | Update scripts and monitoring that start, stop, or check ZooKeeper. | Teams with ZooKeeper-based automation |
| 3 | Kafka properties in TQL | Remove kafkaversion and zk.address from Kafka property sets in TQL maintained outside Striim. | Teams that manage TQL in source control or external tooling |
| 4 | Alert integrations | Update mailbox rules and Slack or Teams integrations that parse alert subjects or messages. | Teams that route alerts by parsing subject lines |
| 5 | Operating system | Confirm the OS is certified. RHEL 7.9, RHEL 9.4, and Ubuntu 18.04 LTS are not certified for 5.4.x. | All environments |
| 6 | Java version | Install JDK 17 first if you are on a release earlier than 5.4.0.2. There is no downgrade path after that upgrade. | Environments on releases earlier than 5.4.0.2 |
None of these items is complex, but each is far easier to address during planning than during a change window. Validate the upgrade in a lower environment before production. Source: What’s New in Striim Platform 5.4.4 and the release notes.
Why the 5.4.4 Upgrade Matters to Your Organization
Striim Platform 5.4.4 delivers three outcomes leaders can report on: reduced security exposure, stronger separation of duties for mainframe data access, and lower operational risk from fixes to known production defects. Each strengthens your position with auditors, security leadership, and the business stakeholders who depend on your data.
| Outcome | What delivers it | Who cares |
|---|---|---|
| Reduced security exposure | Four High CVEs closed in bundled Kafka; ZooKeeper retired | Security leadership, auditors |
| Audit readiness | Db2 credentials in Striim Vault; access follows Striim roles | Auditors, mainframe and platform teams |
| Operational confidence | Db2 failures surface promptly; fixes for data loss and stalled targets | Platform operators, business stakeholders |
Next Steps: How to Plan the Striim 5.4.4 Upgrade
- Review What’s New in Striim Platform 5.4.4 and the release notes
- Complete the six-upgrade readiness checks above
- Validate the upgrade in a lower environment
- Schedule the production upgrade within your remediation window
The question is not whether your current release will keep running. It will. The question is whether your organization can defend four open High CVEs and a known data loss defect when the remediation is already available.
If you want to talk through how 5.4.4 fits your roadmap, I am happy to share what we are seeing across customer environments. Contact us.
Publishing Package
Post Metadata
| Field | Value |
|---|---|
| Title | Striim Platform 5.4.4: Why This Point Release Belongs on Your Roadmap |
| Author byline | Bobby Curtis |
| Estimated read time | 4 minutes |
| Suggested slug | striim-platform-5-4-4-upgrade |
| Canonical URL (proposed) | https://www.dbasolved.com/striim-platform-5-4-4-upgrade/ |
SEO tags: Striim Platform 5.4.4 upgrade · Striim 5.4.4 release notes · Kafka 4.3.1 KRaft migration · Kafka ZooKeeper to KRaft upgrade · Kafka 3.9.1 High CVE remediation · Db2 for z/OS change data capture · mainframe CDC pipeline governance · Google Cloud Spanner UUID replication · PostgreSQL CDC data loss fix · Smart Alert Slack and Teams notifications · streaming data pipeline upgrade planning · real-time data integration security patching
Visual assets: Keep the original featured image prompt. Capture two real UI screenshots to replace the placeholders: (1) a Db2 for z/OS pipeline in the Striim UI alongside other sources, and (2) an alert notification showing the product and cluster name.
