Welcome to the first edition of our Open Source Monthly Updates! We are launching this series of blog posts to share the most relevant open-source developments, critical security updates, and practical architecture insights every month.
Staying ahead in cloud-native infrastructure means filtering through dozens of monthly releases to find what actually impacts production stability and security. In this edition, we examine a security-heavy PostgreSQL release, a critical unauthenticated account-takeover in Keycloak, tenant isolation in OpenBao 2.6, LLM cost tracking with OpenCost, privilege escalation vectors in Red Hat ACM, Mistral's new guardrails model, and a big month for DuckDB — a v2.0 preview and an AWS acquisition.
PostgreSQL: This is more than a routine update
PostgreSQL released 18.6, 17.11, 16.15, 15.19 and 14.24 on August 13. Together, the releases fix 28 security vulnerabilities and more than 110 bugs.
That alone makes this a release worth prioritizing.
Several vulnerabilities are particularly concerning because they allow users with basic SQL execution permissions to escape role boundaries and execute native code as the PostgreSQL operating-system user.
There is also a vulnerability in pg_dump. A malicious or compromised PostgreSQL server can attack the client machine running the dump. This expands the security boundary beyond the database server itself to backup infrastructure, admin workstations, and CI/CD runners.
More details can be found on PostgreSQL's release announcement. If you run PostgreSQL in production, treat this as a critical security update rather than normal maintenance.
And if you are still running PostgreSQL 14, keep a proven deadline in mind: community support ends in November 2026.
Keycloak: An unauthenticated path to any account, including admins
If you run Keycloak on an internet-reachable login endpoint, this is the story of the month to act on. On August 18, 2026, Red Hat and the Keycloak project disclosed CVE-2026-18963, a critical flaw in the reset-credentials flow of the keycloak-services component. It carries a CVSS 9.1 rating and requires no authentication, no existing session, and no victim interaction.
The root cause is improper state validation in the password-recovery flow. Normally, Keycloak emails a one-time action token, and only whoever opens that link reaches the screen that sets a new password — the mailbox is the proof of ownership. With a crafted request to the reset endpoint, the authentication session jumps straight to the password-update phase and the emailed token is never required. The result is a full account takeover of any user the server holds, administrators included.
The fix is to upgrade to upstream Keycloak 26.7.2 (released August 19, 2026) or the corresponding Red Hat build of Keycloak streams 26.4.15 and 26.6.6. If you cannot patch immediately, Red Hat's temporary mitigation is to disable "Forgot password" under Realm Settings → Login in every realm. Note that this is per-realm — there is no global switch — and it will send users who genuinely forget their password to an admin-assisted reset in the meantime.
Two things make this more than a routine CVE. First, the blast radius: an identity provider sits under every application that trusts it, so a takeover here unlocks everything behind the login. That is precisely the position Keycloak occupies for banks, insurers, healthcare providers, and public administrations running federated login. Second, the pace: CVE-2026-18963 was one of eight CVEs fixed in 26.7.2, and version 26.7.1 two weeks earlier (August 5) had already closed twelve — roughly twenty security fixes in three weeks. A quarterly patch ticket is not a viable cadence for software sitting at the center of authentication.
As of late August there was no confirmed exploitation in the wild, but public proof-of-concept exploits already exist and NVD classifies the flaw as automatable, so the window between disclosure and mass scanning is short. To check whether you were hit during the exposure window, review admin event logs for UPDATE_PASSWORD events that were not preceded by an email-verification step in the same authentication session, and for repeated reset initiations against different accounts from a single source. Details and the full advisory are on the Red Hat CVE page, the GitHub Security Advisory, and the upstream Keycloak issue.
OpenBao 2.6: Cryptographic isolation between tenants
OpenBao 2.6 introduces one of its most compelling security features yet: namespace sealing.
Namespaces already provide logical separation between tenants. However, a sufficiently privileged OpenBao operator still controls the underlying system. Sealable namespaces introduce a hard cryptographic boundary.
A namespace can now maintain its own encryption key hierarchy. When sealed, its keys are purged from memory. Even an operator with global OpenBao root privileges cannot read tenant secrets without unsealing that namespace with its specific key material. This solves a major pain point for multi-tenant platform teams who cannot allow platform admins to become ultimate trust anchors.
There is a proven operational trade-off: each independently sealed namespace adds key-management overhead. In OpenBao 2.6, namespace sealing relies on Shamir keys; the external KMS plugin architecture does not yet offer automatic unsealing for individual namespaces.
For teams building sovereign or strongly isolated environments, this is a major architectural improvement. Details are available in the official release notes.
OpenCost: What does your self-hosted LLM actually cost?
Calculating raw GPU cluster costs is straightforward. Determining the exact cost of an individual request to your self-hosted LLM is much harder.
OpenCost 1.121.0 solves this pain point by introducing inference-cost accounting. By combining Kubernetes infrastructure costs with metrics from inference engines like vLLM, it tracks:
- Hourly cost per model
- Cost per million tokens
- Input vs. output token cost breakdown
- Allocation-based vs. actual usage-based cost
The distinction between allocation and usage is the real game-changer.
Imagine a GPU node costs CHF 12 per hour. If your model processes continuous inference requests, token output remains high and the cost per token stays low. If the model sits idle for half an hour, you still pay CHF 12, but your effective cost per token doubles.
This distinction is crucial when evaluating self-hosted models against commercial APIs. SaaS API providers charge per million tokens, whereas internal platforms present raw infrastructure bills. OpenCost provides a proven method to approximate token costs for on-premise GPU clusters as hardware costs amortize.
Read the technical deep-dive on the CNCF blog.
Red Hat ACM: When controllers become privilege amplifiers
While cost tracking secures budget, controlling privileged automation secures cluster boundaries. Several vulnerabilities disclosed around Red Hat Advanced Cluster Management (ACM) highlight a recurring Kubernetes security risk: controller privilege escalation.
Kubernetes controllers run with high privileges. Unprivileged users may lack permission to create cluster-wide resources directly, but they can often create custom resources processed by a privileged controller.
If the controller fails to rigorously validate incoming resource definitions, security boundaries break. In CVE-2026-10090, users with limited permissions could craft ACM resources that forced a root-level controller to act on their behalf, achieving full cluster-admin escalation.
Unless you rely on the deprecated ACM Application Subscription model, your specific clusters may not be vulnerable. However, this serves as a reminder for platform engineers: every controller consuming user-controlled input forms part of your attack surface.
Mistral AI: Shieldstral is a new 3.8B model for guardrails
In the open-weights space, Mistral AI released Shieldstral, a 3.8B multimodal safety classifier. Designed specifically for input/output guardrails, the model evaluates prompts and documents against customizable safety taxonomies, returning a calibrated yes/no probability.
For more information read the offical Mistral annoucement.
DuckDB: AWS buys the company
On August 26, DuckLabs, the Amsterdam-based company behind DuckDB, announced it will join AWS as a subsidiary, with the deal expected to close in early September. Amazon confirmed the definitive agreement; financial terms were not disclosed. DuckLabs is an unusual acquisition target: founded roughly five years ago, grown to around thirty engineers, never funded by venture capital, and owned by its founders and staff. Co-founders Hannes Mühleisen and Mark Raasveldt will continue leading the team and the project's technical direction, now from inside AWS. The move fits Amazon's broader push to make S3 a place to analyze data rather than only store it, building on prior collaboration around S3 Tables and SageMaker Lakehouse.
The reassurance is real but worth reading carefully. DuckDB, DuckLake, and Quack stay under the permissive MIT license and under the non-profit DuckDB Foundation, and MIT cannot be revoked retroactively — the code remains forkable and portable, and DuckDB still runs anywhere as a single embedded binary. That is a genuinely different situation from a source-available relicensing. The caveat is governance: the "independent" Foundation is currently led by the same two founders who are now AWS employees, and Mühleisen has openly framed the acquisition as a reason to expand the Foundation's role precisely to avoid conflicts of interest with large technology vendors, a candid signal that the concern is not hypothetical. Expect the roadmap's center of gravity to tilt further toward S3, S3 Tables, and lakehouse integration.
Projects we're watching
Alongside the main updates, here are two open-source projects worth tracking:
Cloud Native Buildpacks remains a key tool for platform engineering and supply chain security. It converts source code into OCI-compliant images without requiring dev teams to maintain custom Dockerfiles. While there were no major releases this month, it remains vital for balancing developer experience with build-time security.
k8gb is gaining rapid traction. This Kubernetes-native global load-balancing project recently reached CNCF Incubating status. Its DNS-based, vendor-neutral traffic routing enables multi-cluster failover without single-cloud vendor lock-in.
Top comments (0)