リリース

Kubescape v4.0.10 is a feature and hardening release: it closes an SSRF gap in the scan-completion webhook, tightens config.json permissions and validation, and removes a dead CRD, alongside a large batch of bug fixes and new capabilities like `operator remediate` and encrypted report decryption. No CVE-tracked vulnerabilities are disclosed in this release.

• securitySSRF hardening on scan-completion webhook

  The scan-completion webhook callback now hardens against SSRF. Applies to users of the webhook callback feature; upgrade if you rely on it to avoid outbound requests being abused via crafted callback URLs.

• breakingconfig.json permissions restricted to owner-only

  config.json is now written with owner-only permissions instead of broader access. Applies unconditionally; review any tooling or automation that reads this file as a different user, since it may now fail to access it.

• breakingRemoval of orphan SecurityException CRD

  The orphan SecurityException CRD, which was never installable, has been removed. Applies only if you had references to this CRD in manifests or docs; it has no functional impact since it never worked.

• enhancementStricter validation on --format and VAP controls

  The --format flag now rejects invalid values before a scan starts, and VAP configurable controls now require params. Applies if you script scans with an unchecked --format value or run VAP controls without required params; these calls will now fail fast instead of proceeding silently.

v1.18.1 is a routine patch that fixes CIDR matching behavior and serialization determinism while extending an experimental flag to BatchCheck. No breaking changes or CVEs are reported, though the in_cidr fix does change matching behavior for IPv4-mapped IPv6 addresses.

• breakingin_cidr now matches IPv4-mapped IPv6 addresses against IPv4 CIDRs

  Applies unconditionally: the in_cidr condition now normalizes IPv4-mapped IPv6 addresses (e.g. ::ffff:192.168.1.1) to their IPv4 form before matching, so they can now match IPv4 CIDRs like 192.168.1.0/24. Review any authorization models relying on in_cidr if you expect these addresses to be excluded from IPv4 ranges.

v1.18.0 is a bugfix rollup with one operator-facing behavior change: the outbound User-Agent header is now hyphenated to conform to RFC 9110. The remaining changes are runtime improvements, formatter and coverage tool fixes, and a Go toolchain bump.

• breakingUser-Agent header format changed (RFC 9110 conformance)

  The outbound User-Agent header OPA sends on HTTP requests changed from 'Open Policy Agent/<version> (<os>, <arch>)' to 'Open-Policy-Agent/<version> (<os>, <arch>)' (hyphen added between 'Open' and 'Policy'). Any server-side log filters, WAF rules, or access policies that exact-match the old string must be updated after upgrading to v1.18.0.

v1.19.6 is a security patch fixing a HIGH severity RBAC privilege escalation in the cert-manager-edit ClusterRole that let users create ACME Challenge and Order resources directly, plus a Go toolchain update closing three CVEs. The RBAC fix includes a documented breaking permission change.

• securityRBAC privilege escalation via ACME Challenge/Order creation

  Applies to v1.19.6: the default cert-manager-edit aggregate ClusterRole previously let namespace users create ACME Challenge and Order resources directly, bypassing Issuer solver selectors. This is fixed by removing create for challenges.acme.cert-manager.io and create/patch/update for orders.acme.cert-manager.io from that role. Upgrade to v1.19.6 to close this HIGH severity RBAC gap (GHSA-8rvj-mm4h-c258).

• securityGo toolchain updated to 1.25.11 for three CVEs

  Applies unconditionally in v1.19.6: Go is updated to 1.25.11, fixing CVE-2026-27145, CVE-2026-42504, and CVE-2026-42507. No action needed beyond upgrading.

• breakingcert-manager-edit ClusterRole loses Challenge/Order create permissions

  If any tooling or workflow creates Challenge or Order resources directly, outside the normal Certificate to CertificateRequest to Order to Challenge flow, it will lose that access after upgrading and needs those permissions granted explicitly.

v1.20.3 is a security release primarily addressing a HIGH-severity RBAC over-permission (GHSA-8rvj-mm4h-c258) in the cert-manager-edit ClusterRole, and updating Go to v1.26.4 for three CVEs. Operators should audit any workflows that create Challenge or Order resources directly before upgrading, as those permissions are now removed.

• securityRBAC over-permission in cert-manager-edit ClusterRole (GHSA-8rvj-mm4h-c258)

  GHSA-8rvj-mm4h-c258 (HIGH): the cert-manager-edit aggregate ClusterRole previously allowed namespace users to create Challenge and Order resources directly, bypassing Issuer solver selectors. Fixed in v1.20.3. Upgrade immediately if untrusted namespace users exist in your cluster.

• securityGo runtime updated to v1.26.4 (3 CVEs)

  Go updated to v1.26.4, patching CVE-2026-27145, CVE-2026-42504, and CVE-2026-42507. No additional configuration is required; upgrading cert-manager picks up the fix.

• breakingBreaking RBAC change: direct Challenge and Order creation removed from cert-manager-edit

  cert-manager-edit no longer grants create on challenges.acme.cert-manager.io, or create/patch/update on orders.acme.cert-manager.io. If any tooling or CI workflow creates Challenge or Order objects directly (outside the normal Certificate → CertificateRequest → Order → Challenge flow), those calls will fail after upgrading. Review and update any such automation before rolling out v1.20.3.

v1.18.0 patches two auth security bugs and fixes MySQL case-sensitivity. MySQL users must plan a maintenance window before upgrading — auto-migration will lock tuple/changelog tables.

• securitySilent OIDC audience bypass — check your auth config before upgrading

  If authn.oidc.audience was previously omitted, any validly-signed token from your trusted issuer was accepted regardless of intended audience. After upgrading, OpenFGA will refuse to start without both issuer and audience set. Verify your deployment config has authn.oidc.audience explicitly set, or the service will not come up.

• securityPreshared key timing side-channel fixed — no action needed if you rotate keys

  The prior map lookup for preshared key auth could reveal valid key bytes via timing differences. Now fixed with constant-time comparison. No immediate action required, but if this key has been exposed to untrusted network paths for a long time, rotating the preshared key is a reasonable precaution.

• breakingMySQL users: do not auto-migrate on startup

  Migration 008 acquires a shared lock on tuple and changelog tables. On large datasets this can block Write operations for an extended period. Read the operator runbook at the collation_migrations.md guide, schedule a maintenance window, and run the migration manually rather than letting OpenFGA auto-migrate on startup.

Falco 0.44.1 adds BPF iterator control and fixes multiple BPF-related issues via a libs bump. Minimal release focused on stability for deployments using kernel-level tracing.

• breakingUpdate libs and kernel driver together

  This release bumps libs to 0.25.4 and driver to 10.2.0+driver. If you pin kernel driver versions separately from Falco, ensure you update both in the same maintenance window. Mismatched versions can cause syscall capture failures or silent data loss.

• enhancementControl BPF iterator behavior if you hit performance or compatibility issues

  Falco 0.44.1 introduces a config option to disable BPF iterators. If you run Falco on kernels with problematic BPF iterator implementations or see high CPU usage tied to iterator overhead, test disabling them. Check your Falco logs and metrics after upgrading to confirm the fix resolves any BPF-related instability you were seeing in 0.44.0.

v1.17.1 is a focused patch fixing two correctness bugs: stale cache reads and broken continuation tokens with pipe characters in type names.

• securityStale cache reads could return incorrect authorization decisions — patch now

  The iterator cache was using write time rather than query start time as the LastModified anchor, meaning cached entries could persist beyond the intended validity window and serve stale data. In an authorization system, a stale 'allow' decision is a real risk. This is fixed in v1.17.1; upgrade immediately if you run with caching enabled.

• breakingAudit type names with '|' if pagination was silently breaking

  If your FGA model uses type names containing the pipe character '|', continuation tokens were being deserialized incorrectly. This could cause ListObjects or similar paginated calls to return incomplete or wrong results without throwing obvious errors. Upgrade to v1.17.1 and re-test any pagination flows that touch those type names.

• enhancementv2Check throttling fallback removed — verify your error handling

  Previously, v2Check would fall back to v1 behavior under throttling or validation errors, masking the actual problem. Now it surfaces those errors directly. If your application swallows check errors silently or assumes fallback behavior, you may start seeing errors that were previously hidden. Test under load before rolling out to production.

Kubescape v4.0.9 is a large maintenance release fixing scan accuracy bugs (partial resource collection, coverage reporting, Prometheus output), hardening data exposure in scan reports, and changing the patch command's default push behavior.

• securityReview secret exposure fixes and new anonymization flag

  Multiple fixes landed for secret/data leakage in scan output: EnvFrom and Env[].ValueFrom are now cleared in removeContainersData (commits acc3280, 0c68cca), an IDOR in /v1/results was hardened (commit 0fe6a0f), and a new --hide/anonymization pipeline was added to scrub resource names, namespaces, labels, annotations, and container metadata from scan reports. If you share or export Kubescape reports outside your team, review the new --hide flag and confirm your CI artifacts aren't exposing secret references from container env vars.

• breakingPatch command no longer pushes images by default

  Kubescape's `kubescape fix` command now defaults to not pushing patched images (commit b10cbb1). If your CI pipelines relied on the old default push behavior, add an explicit `--push` flag or equivalent opt-in, or your patch pipeline will silently stop pushing images after upgrading.

• enhancementAdopt new coverage-gate and diff commands in CI

  New flags let you gate CI pipelines on scan coverage and control results: --fail-coverage-below sets a minimum coverage threshold (commit 4ae7b87), and scan coverage gaps/not-evaluated controls are now reported explicitly (commit 5876d2b). A new `kubescape diff` command compares two scan reports (commit 00682ee). Add --fail-coverage-below to CI gates where partial resource collection could previously pass silently, and use `kubescape diff` to track posture drift between scans.

0.9.51.0 is a broad feature release adding new AWS AI/ML and agent resources, fixing a breaking iam-access-key schema change, and significantly expanding GCP label management coverage across ~15 resource types.

• breakingRemove json-diff filter from iam-access-key policies before upgrading

  The `json-diff` filter has been removed from `aws.iam-access-key`. Any policies using this filter will fail at runtime. Audit your policy files for `iam-access-key` resources before upgrading and remove or replace any `json-diff` filter references.

• enhancementAdopt new cross-account org path support for IAM policy checks

  AWS cross-account policy evaluation now supports `aws:PrincipalOrgPaths` and whitelisted accounts. If you run cross-account governance policies, review this new support — it may let you replace custom workarounds you've built for org-path-based principal checks.

• enhancementExtend GCP label compliance policies to cover newly supported resource types

  GCP label coverage has expanded significantly: Cloud Run services/jobs, Pub/Sub topics/subscriptions, Redis, Secrets Manager secrets, snapshots, DNS managed zones, interconnects, load balancer addresses and forwarding rules, and Cloud Functions all now support `set-labels` and `mark-for-op`. If you run GCP tagging compliance policies, this release lets you extend label enforcement to most of these resource types without workarounds. Update your GCP policies to cover the newly supported resources.

OPA v1.17.0 fixes a semantic bug in negation handling and improves decision log label reporting. Most changes are enhancements; one dependency removal requires manual GOMAXPROCS configuration in some environments.

• breakingRemoved automaxprocs and x/net dependencies; configure GOMAXPROCS manually if needed

  OPA v1.17.0 removes the automaxprocs and x/net dependencies, reducing the runtime footprint and eliminating potential conflicts with applications that also manage those libraries. No action is required unless your deployment explicitly depends on automaxprocs behavior (automatic CPU detection and GOMAXPROCS tuning). If you rely on that behavior, you may need to configure GOMAXPROCS explicitly in your environment or deployment. Most users will see no impact.

• enhancementImport future.keywords.not to fix negation semantics in composite expressions

  OPA v1.17.0 introduces a new `future.keywords.not` import that fixes a long-standing semantic bug where negation of composite expressions (`not f(g(input.x))`) would fail silently if any intermediate value was undefined, instead of correctly succeeding. With the import enabled, undefined intermediates no longer cause rule failure. If your policies rely on negation of complex expressions where inputs or function results might be undefined, import `future.keywords.not` to fix unintuitive failures. This is a behavioral change that may affect policy evaluation, but in the direction of correctness.

• enhancementUpdate decision log parsing for new rule_labels array format

  Decision logs now include a new top-level `rule_labels` array that collects labels from all successfully evaluated rules in a single entry, with inner-scope-wins precedence (rule > document > package > subpackages). This replaces the previous behavior of one log entry per label-contributing scope. If you parse or query decision logs by rule labels, update your log parsing logic to read from `rule_labels` as an array of merged label maps rather than individual scope-level entries. This change simplifies label aggregation and is now processed by default in both runtime and Go SDK.

Falco 0.44.0 drops three long-deprecated features (gRPC output, gVisor engine, legacy BPF probe) and adds expressive rule engine improvements. Deployments using any of these must migrate before upgrading.

• securityfalco-webui restricted to local access — check external tooling

  The falco-webui Docker service now restricts access to localhost only. If you had it exposed on a broader interface, that changes on upgrade. This is a net positive for most deployments, but verify any tooling or dashboards that reached the webui over the network still work after the upgrade.

• breakingThree features dropped — check your config before upgrading

  Three major removals land in this release: gRPC output/server, gVisor engine, and the legacy BPF probe. If you rely on gRPC-based output consumers, you need an alternative output path (e.g., JSON over HTTP, or a sidecar) before upgrading. gVisor users must switch to a supported engine. Legacy BPF users should move to the modern eBPF probe. Audit your current config for any of these before touching 0.44.0 in production.

• enhancementRicher rule syntax — review custom rules for validation errors

  The rule engine now supports oneof/allof/anyof string comparator modifiers, and rules can use list transformer exceptions. These let you write tighter, more expressive detection rules without duplicating conditions. If you maintain custom rules, review whether these can replace existing workarounds. Also, Falco now validates unknown keys in rules — so rule files with typos or unsupported fields will produce warnings or errors instead of silently being ignored.

v1.16.0 patches a critical OIDC token rejection bug after key rotation, fixes two correctness bugs in experimental weighted_graph_check, and updates Go to address stdlib CVEs.

• securityUpdate immediately if using OIDC auth or any Go stdlib CVEs apply

  Two separate security concerns here. First, the OIDC JWKS refresh fix means deployments that rotate issuer keys were silently rejecting valid tokens — if you've seen 401s after a key rotation, this is why. Second, the Go 1.24.3 update patches stdlib vulnerabilities; review the Go 1.24.3 release notes to assess exposure. Upgrade to v1.16.0 promptly in both cases.

• breakingweighted_graph_check users: validate results after upgrading

  Two correctness bugs were fixed in the experimental weighted_graph_check feature. Cache key collisions and false-negative caching from cancelled goroutines mean prior versions could return incorrect 'false' results. If you're running this in any meaningful capacity, run a validation pass against known-good authorization scenarios after upgrading to confirm behavior is now correct.

• enhancementConfigure PingTimeout to catch datastore connectivity issues faster

  The new PingTimeout and PingRetryMaxElapsedTime config options give you explicit control over how long OpenFGA waits to confirm datastore connectivity at startup and during health checks. Set these to values aligned with your SLOs — tighter timeouts surface infrastructure problems earlier instead of letting the server spin up against a degraded datastore.

SPIRE v1.15.0 adds HashiCorp Vault key management, rootless Podman support, and PROXY protocol rate limiting, while promoting sigstore attestation out of experimental. One CLI JSON output change requires attention before upgrading.

• breakingAudit CLI JSON consumers before upgrading

  The CLI no longer wraps objects in slices when printing JSON output. Any scripts, pipelines, or tools that parse SPIRE CLI JSON output will likely break — they expected arrays and will now get single objects. Audit all automation that calls spire-server or spire-agent CLI with JSON output flags before rolling this out. Test in a non-production environment first.

• breakingUpdate metric dashboards for 'bootstrapped' label rename

  The metric label 'bootstraped' (one 'p') was corrected to 'bootstrapped'. Any Prometheus queries, Grafana dashboards, or alerting rules referencing the old misspelled label will silently stop matching after upgrade. Find and update all references before deploying v1.15.0.

• enhancementMigrate to HashiCorp Vault Key Manager if your org already runs Vault

  If your team already operates HashiCorp Vault, the new Vault Key Manager plugin lets you consolidate key storage there instead of managing a separate AWS KMS or Azure Key Vault setup. This is particularly useful for on-prem or multi-cloud deployments where cloud-native KMS options are awkward. Review the plugin configuration docs and plan a key migration window — existing keys in other backends won't auto-migrate.

• enhancementPromote sigstore attestation to production workloads

  Sigstore-based attestation in both the k8s and docker attestors is now stable. If you've been holding off due to the experimental flag, this is the release to enable it for production. Verify your signing workflows are compatible and enable the feature in staging first to confirm selector behavior matches expectations.

Kyverno v1.18.1 is a targeted patch fixing two regressions in generate and mutate-existing policies introduced in v1.18.0.

• breakingUpgrade immediately if you use generate policies on cluster-scoped resources

  If you upgraded to v1.18.0 and have GeneratingPolicy rules targeting cluster-scoped resources (ClusterRoles, Namespaces, CRDs, etc.), generation was silently broken. v1.18.1 restores correct behavior. Validate that expected resources were actually generated after upgrading — anything that should have been generated during the v1.18.0 window may need manual remediation or a policy re-trigger.

• breakingMutate-existing policies on v1.18.0 may have produced incorrect results

  The AdmissionRequest context was not being forwarded to UpdateRequests in mutate-existing policies. This means any rule relying on request context (user info, object, oldObject) for conditional logic or patches would have behaved incorrectly. Audit mutations applied while running v1.18.0 and verify affected resources are in the expected state after upgrading to v1.18.1.

• enhancementTreat v1.18.0 as effectively broken for generate and mutate-existing users

  Both fixes were cherry-picked from main, meaning v1.18.0 should be skipped entirely if you rely on either feature. Skip straight to v1.18.1. If you are still on v1.17.x and evaluating the v1.18 line, start your testing against v1.18.1 instead.

v7.0.0 fixes a Windows-specific security vulnerability in delegation path matching and tightens the ngclient API with one breaking constructor change.

• securityPatch Windows deployments immediately for GHSA-qp9x-wp8f-qgjj

  Delegation path matching was broken on Windows, meaning a malicious or misconfigured repository could match targets it shouldn't. If any of your TUF clients run on Windows, upgrade to v7.0.0 now. Linux/macOS deployments are unaffected, but upgrading is still the right move before paths diverge further.

• breakingUpdate all Updater() call sites to use the named bootstrap argument

  The Updater() constructor signature changed: 'bootstrap' is now a required keyword argument. Any code calling Updater() without explicitly passing 'bootstrap' will break. Audit your code for Updater instantiations — if you weren't passing a bootstrap value before, add bootstrap=None to restore the previous behavior. This is a one-line fix per call site, but it will cause an immediate TypeError if missed.

• enhancementWatch for securesystemslib.hash removal in upcoming releases

  This release starts phasing out the securesystemslib.hash dependency. If your codebase or any custom TUF extensions directly import or rely on securesystemslib.hash, start planning a migration now rather than scrambling when a future release drops it entirely.

Kubescape v4.0.8 is a focused patch release that fixes several VAP (Validating Admission Policy) bugs and adds a --timeout flag to the deploy-library command.

• breakingVAP label selector parsing was silently wrong — verify your policies

  The old code split label selectors on '=' directly instead of using Kubernetes' label parser. DoubleEquals (==) selectors were also incorrectly accepted. If you've generated VAP policies with Kubescape and used complex label selectors, re-generate and re-validate those policies with v4.0.8. Don't assume previously generated output was correct.

• enhancementUse --timeout with VAP deploy-library in slow clusters

  The new --timeout flag on the deploy-library command lets you tune how long Kubescape waits during VAP library deployment. If your cluster has slow API server response times or you're running in CI with strict time limits, set this explicitly rather than relying on the default. Test in staging first to find a safe value before enforcing it in pipelines.

• enhancementConnector URL back-propagation fix matters for cloud API setups

  A bug where connector URLs weren't back-propagated to the config object during cloud API initialization is now fixed. If you use Kubescape's cloud integration and noticed inconsistent scan result submissions, this patch addresses the root cause. Upgrade and re-run a scan to confirm results are reaching your backend correctly.

Kubescape v4.0.7 is a broad bug-fix and usability release: better input validation, safer concurrency in the HTTP handler, a new ControlInput CRD, and service discovery without a sidecar.

• breakingThreshold flags now fail fast — check your CI pipelines

  Severity-threshold, compliance-threshold, and fail-threshold flags are now validated before the scan starts. Scripts or CI jobs that pass invalid threshold values will now exit immediately with an error rather than completing the scan and ignoring the flag. Review your scan invocations to confirm all threshold flags are valid before upgrading.

• enhancementDrop the sidecar for service discovery

  Service discovery now queries the Kubernetes API directly. If you've been running a sidecar specifically to support Kubescape's service discovery, you can remove it. Audit your deployments before upgrading to avoid unexpected behavior from redundant sidecars.

• enhancementDeploy the ControlInput CRD for in-cluster tuning

  The new ControlInput CRD lets you configure control inputs directly in the cluster rather than through external files. This only activates during live cluster scans, so file-scan workflows are unaffected. Apply the CRD after upgrading if you want to centralize scan policy configuration in-cluster.

v1.15.1 is a stability patch fixing two serious runtime bugs — a potential deadlock in Check and a semaphore leak under context cancellation — plus a cache collision in the experimental weighted graph check.

• securityCache key collision in `weighted_graph_check` could return incorrect authorization results

  If you're running the experimental `weighted_graph_check` feature, the cache collision bug means Check could return stale or wrong results for relationships in unions with direct types, wildcards, TTU paths, or intersections. This is an authorization correctness issue — wrong answers on permission checks. Upgrade before relying on this feature in any environment where correctness matters. If you can't upgrade immediately, disable the experimental feature flag.

• breakingUpgrade immediately — deadlock and semaphore leak bugs affect production stability

  Two bugs here can quietly degrade running services. The deadlock in Check (message streams held open on error) can starve request processing over time. The semaphore leak in the bounded tuple reader under context cancellation means goroutine/resource exhaustion under load or timeout-heavy workloads. Neither requires config changes — just upgrade. If you've seen unexplained Check hangs or increasing resource pressure after cancellations, these are the culprits.

• enhancementListObjects now handles short-circuit errors correctly

  A subtle bug was causing expected errors (non-fatal path short-circuits) to bubble up incorrectly in ListObjects responses. If you've seen unexpected errors returned from ListObjects queries that should have silently short-circuited, this fix resolves that. No action needed beyond upgrading — but worth re-validating ListObjects behavior in your test suite after the upgrade.

in-toto v3.1.0 migrates away from sslib's hash functions, switches to ruff for code style, and refreshes Debian packaging — mostly maintenance, but the sslib change has dependency implications.

• breakingAudit your sslib dependency if you use it alongside in-toto

  in-toto has internalized sslib's hash functions because sslib is being deprecated. If your project independently depends on sslib for other functionality, start planning a migration now — don't assume sslib will remain maintained. Check your dependency tree for anything that transitively pulls in sslib and evaluate whether those paths need updating.

• enhancementUse the new `in-toto-run` return code passthrough in CI pipelines

  Previously, `in-toto-run` would swallow the wrapped command's exit code, which could mask failures in CI. With passthrough now enabled, the return code of the wrapped command propagates correctly. If you have shell scripts or CI steps that check exit codes after `in-toto-run`, verify your error handling still works as intended — behavior has changed and some pipelines may now surface previously hidden failures.

• enhancementIf you contribute to or package in-toto, update your dev tooling to ruff

  The codebase now enforces ruff-based style rules. If you maintain a fork, downstream package, or contribute PRs, your existing flake8/pylint setup will likely flag false conflicts. Align your local dev environment with ruff before opening PRs against this version or later.

v4.0.6 tackles a wave of false negatives, silent errors, and correctness bugs in scanning — namespace filters, exception matching, and OPA eval failures all get fixes that change scan results.

• securityAudit vulnerability exception lists for case inconsistencies

  Exception matching for image scan CVE IDs was case-sensitive before this fix, meaning 'ghsa-xxxx' and 'GHSA-xxxx' were treated as different identifiers. Any exceptions defined with lowercase CVE/GHSA IDs were silently not applied. After upgrading, check that your exception lists use consistent casing and re-verify which vulnerabilities are actually being excepted.

• securityRaw request bodies are no longer logged — review your log retention

  Kubescape's HTTP handler was logging full scan request bodies, which could include sensitive resource manifests or configuration data. That logging is now removed. If you've been collecting these logs, review and rotate any stored log data that may contain manifest content.

• breakingExpect scan result changes after upgrading — false negatives are now real failures

  Two distinct bugs caused resources to silently disappear from scan results: OPA eval errors were swallowed, and partial GVR collection failures were suppressed. Both are fixed. If your baseline compliance scores looked suspiciously clean, re-run scans after upgrading and treat new failures as real findings that were always there, not regressions introduced by the upgrade.

v1.16.0 brings new URI builtins, Data API metadata support, OTLP metrics export, and critical fixes for log dropping and log buffer eviction bugs introduced in v1.15.x.

• securityunits.parse_bytes exponent cap prevents timeout bypass

  Extremely large exponent values in units.parse_bytes could be used to cause evaluation timeouts, potentially bypassing policy enforcement. This is fixed in v1.16.0 by capping the exponent size. If your policies accept user-controlled input that gets passed to units.parse_bytes, this fix is directly relevant — upgrade and review any policies that parse byte strings from untrusted sources.

• breakingUpgrade from v1.15.x immediately — logs are silently dropped

  A BufferedLogger bug in v1.15.x caused bundle download logs, print() debug output, and plugin logs to be dropped after the first flush. This is silent data loss in your observability stack. If you're running v1.15.x in any environment where decision logs or debug output matter, upgrade to v1.16.0 now. Check your log pipeline for gaps if you've been running v1.15.x in production.

• enhancementUse new uri.parse / uri.is_valid builtins to replace fragile regex-based URL validation

  Many OPA policies today use regex or string manipulation to validate or decompose URLs — a brittle approach. The new uri.parse builtin returns structured RFC 3986 components (scheme, host, path, query, etc.), and uri.is_valid does a clean true/false structural check. If you have policies handling redirect URIs, webhook URLs, or any URL-bearing input, replace your custom parsing logic with these builtins. The structured output makes it easier to write precise, readable rules.

v1.16.4 is a security-focused patch release addressing 15+ CVEs across Kyverno's dependency chain, plus a critical behavioral change that disables HTTP in namespaced policies by default.

• securityUpgrade immediately — 15+ CVEs patched, including supply chain components

  This release patches CVEs across sigstore/rekor, go-tuf, docker/cli, Go stdlib, and Kyverno's own code. Several of these touch the image verification and policy fetch paths. If you're running any image signing workflows with Kyverno, the rekor and go-tuf bumps are directly relevant. Plan an upgrade in your next maintenance window — do not wait for the next major cycle.

• breakingHTTP disabled by default in namespaced policies (CVE-2026-4789) — test before upgrading

  Namespaced policies that fetch external data over plain HTTP will silently stop working after this upgrade. If you use URL context sources or external data fetches in namespaced ClusterPolicy or Policy resources, audit them for HTTP (non-HTTPS) endpoints before upgrading. This is a security hardening change, but it will break existing policies that relied on insecure endpoints. Switch those endpoints to HTTPS or migrate to HTTPS-capable data sources first.

• breakingRestricted ConfigMap access for namespaced policies — RBAC may need review

  Namespaced policies now have reduced ConfigMap access scope. If your policies rely on reading ConfigMaps outside their namespace for context or configuration, those reads will fail post-upgrade. Review your policy definitions for cross-namespace ConfigMap references and adjust either the policy logic or the access grants accordingly before rolling out this version.

v1.17.2 is a security-heavy patch release addressing multiple CVEs and fixing critical bugs in MutatingPolicy, ValidatingPolicy, webhook reconciliation, and namespaced policy handling.

• securityUpgrade immediately — 6+ CVEs fixed in this release

  This release patches at least six CVEs across dependencies and Go stdlib, plus CVE-2026-4789 which disables HTTP in namespaced policies by default. If you run namespaced policies that rely on HTTP-based external data sources or webhooks, audit those configurations before upgrading — they will stop working silently. Upgrade path: update your Helm chart or manifests to v1.17.2 and validate policy behavior in a staging environment first.

• breakingNamespaced policies: HTTP disabled and ConfigMap access restricted

  Two separate hardening changes affect namespaced policies. HTTP is now disabled by default (CVE-2026-4789), and ConfigMap access has been scoped down. If your namespaced policies fetch context from HTTP endpoints or read ConfigMaps outside their namespace, those policies will fail silently or error post-upgrade. Run a dry-run or audit scan against your namespaced policies before deploying to production.

• enhancementWebhook reconciliation loop fix — reduces controller churn in large clusters

  Inconsistent webhook rule ordering was causing repeated reconciliation loops, which generates excess API server load and noisy controller logs. This is fixed. If you've been seeing constant webhook object churn in your audit logs or elevated kyverno-controller CPU, this release resolves it. No action needed post-upgrade, but worth monitoring controller metrics after rollout to confirm stabilization.

26.6.1 is a security patch release fixing two CVEs — blind SSRF and user enumeration — plus a critical migration bug that broke authentication flows when upgrading from older versions.

• securityPatch immediately for SSRF and user enumeration CVEs

  Two CVEs in 26.6.0 (and earlier) need your attention. CVE-2026-4366 allows blind SSRF through HTTP redirect handling — a real risk if Keycloak can reach internal services. CVE-2026-4633 leaks user existence through identity-first login, which aids credential stuffing. Upgrade to 26.6.1 now. If you can't upgrade immediately, consider disabling identity-first login as a short-term mitigation for CVE-2026-4633.

• breakingIf you upgraded to 26.6.0, check your custom authentication flows immediately

  The MigrateTo26_6_0 migration script had a bug that modified custom browser flows, potentially breaking realm authentication silently. If you upgraded to 26.6.0 and noticed login failures or unexpected flow behavior, this is why. Upgrading to 26.6.1 fixes the migration, but you may need to manually review and repair any already-affected custom flows in your realms. Audit them before upgrading in production.

• breaking26.6.0 JS/Java admin clients were broken — use 26.6.1 packages

  Both @keycloak/keycloak-admin-client (JS) and the Java admin client had packaging issues in 26.6.0 that prevented installation or sync. If your pipelines or applications depend on these libraries and you pinned to 26.6.0, they are likely broken. Update your dependency references to 26.6.1 immediately.

Patch release fixing a Helm chart YAML generation bug when webhook.config and webhook.volumes are both set, plus Go 1.26.2 upgrade to address dependency vulnerabilities.

• securityDependency vulnerabilities patched — upgrade to get the fixes

  The Go runtime and dependencies were bumped specifically to address reported CVEs. The release notes don't call out specific CVE IDs, but don't let that slow you down — cert-manager sits in a privileged position in your cluster handling certificate issuance, so keeping it current on security patches is non-negotiable. Schedule an upgrade in your next maintenance window.

• breakingUpgrade immediately if you use both webhook.config and webhook.volumes

  If your Helm values set both webhook.config and webhook.volumes, the chart has been generating invalid YAML — meaning your webhook may have silently deployed with incorrect configuration. Upgrade to v1.20.2 and redeploy, then verify the webhook pod is running with the expected volume mounts and config.

Keycloak 26.6.0 graduates several preview features to fully supported — JWT Authorization Grant, Federated Client Auth, Workflows, and zero-downtime patch releases — while fixing a notable set of security bugs across UMA, SCIM, and Organizations.

• securityPatch SCIM and UMA vulnerabilities immediately

  Two separate SCIM bugs allowed IDOR-style resource modification and authorization bypass in group management. UMA permission grant accepted expired ID tokens and tokens issued to other clients. These are fixed in 26.6.0. If you use SCIM or UMA, upgrade now — no config change needed, but verify your SCIM plugin/extension is compatible with the new validation.

• breakingSwitch to KCRAW_ prefix if secrets contain $ characters

  If you inject passwords or secrets via environment variables and they contain $ characters (e.g., from a secrets manager), the KC_ prefix silently mangles them via SmallRye expression evaluation. Use KCRAW_<KEY> instead of KC_<KEY> to preserve literal values. Audit your current env var injection before upgrading — any secrets with ${ or $$ patterns may have been silently broken in prior versions.

• enhancementEnable zero-downtime rolling updates in your Operator deployments

  Zero-downtime patch releases are now on by default. If you run Keycloak via the Operator, explicitly set the update strategy to Auto to benefit. Also review the new graceful HTTP shutdown defaults (1s delay, 1s timeout) — adjust these upward if your reverse proxy takes longer to drain connections, especially in non-Kubernetes setups with longer-lived connections.

v1.14.0 fixes a potential deadlock in ListObjects, improves intersection algorithm performance, and adds BatchCheck caching — plus a SQL serialization bug fix that affects PostgreSQL users.

• securityPostgreSQL users: apply the SQL serialization fix

  The TupleOperation serialization and pgx.ErrNoRows fixes could cause silent data inconsistencies or incorrect error handling in PostgreSQL deployments. If you're running OpenFGA on Postgres, this fix alone justifies upgrading. Verify your tuple write/read behavior post-upgrade.

• breakingReview CVE-2026-33729 and upgrade immediately

  The changelog explicitly references CVE-2026-33729. The release notes don't detail the full scope, but a CVE update in a patch/minor release demands immediate attention. Upgrade to v1.14.0 now and audit your deployment's exposure before the CVE details become widely known.

• enhancementListObjects deadlock fix is critical for high-concurrency workloads

  A deadlock in the ListObjects pipeline is the kind of bug that only shows up under real production load. If you use ListObjects extensively — especially with concurrent callers — this fix is essential. After upgrading, stress-test ListObjects under your typical concurrency patterns to confirm stability.

• enhancementBatchCheck caching reduces authorization latency at scale

  If your application calls BatchCheck repeatedly with overlapping tuples or conditions, the new caching layer will cut latency and backend load. No configuration changes are mentioned, so the benefit should be automatic — but monitor cache behavior through the new tuple iterator query stats to validate the improvement in your environment.

v1.20.1 is a targeted patch fixing an OpenShift upgrade blocker, a Gateway API duplicate parentRef bug, and a scanner-flagged gRPC dependency bump.

• securitygRPC bump is cosmetic — but clear your scanner alerts

  The gRPC dependency was bumped purely to satisfy vulnerability scanners. The reported CVE does not affect cert-manager's code paths. No runtime risk, but if your supply chain tooling (Trivy, Grype, etc.) was flagging v1.20.0, this update will resolve those alerts. Good reason to upgrade, but no urgency beyond scanner hygiene.

• breakingOpenShift users: upgrade to v1.20.1, skip v1.20.0

  v1.20.0 introduced a regression where the order controller lacked the necessary finalizer RBAC, breaking upgrades on OpenShift due to stricter RBAC enforcement. If you're on OpenShift and held back from v1.20.0, go straight to v1.20.1. If you somehow applied v1.20.0, verify that the ClusterRole for the order controller now includes the issuer finalizer permissions after upgrading.

• enhancementGateway API users: fix parentRef duplication before it causes routing issues

  If you're using Gateway API integration with cert-manager and specify parent references in both the issuer config and via annotations, v1.20.0 would generate duplicate parentRef entries. This can cause unpredictable behavior depending on your gateway implementation. Upgrading to v1.20.1 resolves this — review any existing certificates using both mechanisms to confirm they're clean post-upgrade.

OPA v1.15.0 adds a pluggable logging system with file rotation, breaks custom HTTPAuthPlugin implementations, and extends AWS signing to support web identity credentials.

• breakingAudit and fix custom HTTPAuthPlugin implementations before upgrading

  If you've built a custom HTTPAuthPlugin, NewClient() is now called once per Client instance, not per request. Any per-request logic (counters, transport wrapping, logging side effects) sitting in NewClient() will now execute exactly once and silently produce wrong behavior. Before upgrading, audit your plugin and move all per-request logic to Prepare(). OPA's own built-in plugins are already updated, so this only affects teams with custom plugins.

• enhancementAdopt the file logger plugin to consolidate OPA log management

  The new file_logger plugin writes structured JSON logs with automatic rotation, covering both runtime and decision logs through a single configuration block under server.logger_plugin. If you're currently tailing OPA stdout or piping to an external log shipper, switching to the file logger reduces operational complexity and gives you rotation out of the box. Decision log plugin output via the same logger plugin is a clean alternative to the HTTP bundle endpoint for low-latency environments.

• enhancementEnable web identity credentials for AWS-backed OPA deployments on EKS

  OPA running on EKS with IRSA (IAM Roles for Service Accounts) can now use Web Identity tokens directly for Assume Role credential flows in AWS Signing. If you've been working around this with instance profile credentials or manual token injection, you can now configure this natively. Update your REST plugin AWS signing config to use the web identity provider and align with standard EKS IAM patterns.

OpenFGA v1.13.0 ships AuthZen v1.0 support, separates Check v1/v2 caches, and hardens the resolver pipeline against panics.

• securityUpgrade to stop resolver panics from taking down the server

  Unhandled panics in the pipeline base resolver previously had the potential to crash the OpenFGA process entirely. The fix converts these to returned errors, keeping the server running. If you've seen unexpected OpenFGA restarts under complex authorization graph evaluations, this is likely why. Upgrade promptly — this is a reliability fix with meaningful availability implications.

• breakingSeparate Check v1/v2 caches may change cache hit behavior — review your cache sizing

  Previously, Check v1 and v2 shared a single cache, which could lead to cross-contamination but also inadvertent cache hits. Now they're isolated. If you're running both API versions concurrently, your effective cache hit rate may drop and memory usage could shift. Revisit your cache capacity configuration after upgrading and monitor cache hit ratios in your observability stack.

• enhancementEvaluate AuthZen v1.0 for cross-system authorization interop

  AuthZen v1.0 is the emerging standard for authorization API interoperability across CNCF and broader ecosystem tools. If you're integrating OpenFGA with other policy engines or building a multi-system authz layer, test the new AuthZen endpoint now. Early adoption means your integration patterns align with where the ecosystem is heading rather than needing a retrofit later.

v1.12.1 is a focused maintenance release fixing OTLP endpoint URI parsing and improving ListObjects pipeline internals with Go native channels.

• breakingOTLP https:// scheme now forces TLS regardless of your config flag

  If you set OTEL_EXPORTER_OTLP_ENDPOINT with an https:// scheme, TLS will be enabled even if trace.otlp.tls.enabled is false. Audit your observability configs before upgrading — any environment using https:// endpoints with TLS explicitly disabled will now have TLS enabled. This is almost certainly the correct behavior, but verify your collector setup accepts TLS connections.

• enhancementOTLP endpoint URIs with schemes finally work — clean up your workarounds

  Previously, passing a full URI like http://host:4317 to OTEL_EXPORTER_OTLP_ENDPOINT would break because the scheme wasn't stripped before reaching the gRPC exporter. If you've been working around this by omitting the scheme, you can now use standard URI formats. Update your deployment configs and remove any manual scheme-stripping logic.

• enhancementListObjects performance improvement — no action needed, just upgrade

  Replacing the custom Pipe implementation with Go native channels reduces internal complexity and can improve throughput for ListObjects calls under concurrent load. No API changes, no config changes needed. The tuple validation refactor compounds this. If you're running OpenFGA at scale with heavy ListObjects usage, this patch is worth taking.

Keycloak 26.5.6 is a critical security release patching 8 CVEs spanning SSRF, token reuse, IDOR, privilege escalation, and multiple information disclosure vulnerabilities. Upgrade immediately.

• securityPatch all 8 CVEs — upgrade to 26.5.6 now

  This release fixes eight CVEs covering SSRF, token replay, privilege escalation, IDOR, and multiple information disclosure paths. Three of these (SSRF via jwks_uri, privilege escalation via manage-clients, and auth session contamination) are particularly dangerous in multi-tenant or public-facing deployments. There is no workaround — upgrade is the only fix. If you're on any 26.x version, treat this as an emergency patch.

• securityAudit manage-clients grants and OIDC Dynamic Client Registration usage

  CVE-2026-3121 (privilege escalation via manage-clients) and CVE-2026-1180 (SSRF via jwks_uri in dynamic client registration) both require reviewing your current permission grants and feature flags. After upgrading, audit which users/service accounts hold manage-clients. If you don't use OIDC Dynamic Client Registration, disable it at the realm level to eliminate the SSRF attack surface entirely.

• breakingVerify Operator DB config and multi-realm startup behavior post-upgrade

  The 26.5.0 Operator regression for DB targetServerType=primary (affecting master-replica failover) and the O(N²) startup scan introduced in 26.5.4 are both fixed here. If you hit either of these bugs, validate your DB connection failover behavior and startup times after upgrading. Large deployments with many realms should see noticeably faster restarts.

v1.14.3 patches a TLS session resumption bypass that could skip certificate chain validation, plus fixes node cache rebuild and several reliability issues in AWS and federation scenarios.

• securityUpgrade immediately to fix TLS session ticket bypass

  TLS session resumption on SPIRE Server's TCP endpoint was allowing reconnecting clients to skip SPIFFE certificate chain validation — meaning a client with an expired or revoked cert could potentially reconnect without re-validation against the current trust bundle. This is a meaningful trust boundary violation. Upgrade to v1.14.3 now. No config change needed; the fix disables session tickets server-side automatically.

• securitySelector data no longer leaks into agent logs

  Selectors can encode workload identity details (e.g., Kubernetes pod labels, Unix UIDs, AWS metadata) that you may not want in logs. Previously, these were logged at agent level. After upgrading, audit your existing log pipelines and retention policies — any historical logs may still contain this data.

• breakingPQC users must migrate from Kyber draft to X25519MLKEM768

  If you've enabled RequirePQKEM TLS policy, the underlying algorithm changes from the draft x25519Kyber768Draft00 to the standardized X25519MLKEM768. Both peers must be running v1.14.3+ before this takes effect, otherwise TLS handshakes will fail. Plan a coordinated upgrade of agents and server if you're using this policy.

• enhancementNode cache rebuild fix is critical for long-running agents

  The periodic node cache rebuild was executing only once after startup instead of on its configured interval. Over time, agents in environments with frequent workload changes would serve stale cache data. This is silently fixed in v1.14.3 — no config changes needed, but you should upgrade agents promptly, especially in dynamic environments.

Kubescape v4.0.3 is a small patch release adding a --grype-db-url flag for offline/airgapped Grype database usage, plus a bug fix for missing host errors and dependency bumps.

• securitygo-git updated to v5.16.5 — pull this upgrade promptly

  go-git patch releases frequently address vulnerabilities in git protocol parsing. Review the go-git v5.16.5 changelog to confirm whether any CVEs are addressed, and prioritize this upgrade if your Kubescape usage involves scanning git repositories or if you embed Kubescape as a library.

• breakingMissing host now returns an error — check your error handling

  Previously, a missing host in scan targets silently returned nil instead of an error. If your pipelines or scripts were treating a zero-exit-code as success in these cases, they may now surface failures they were previously ignoring. Test your scan workflows after upgrading to make sure error handling behaves as expected.

• enhancementUse --grype-db-url for airgapped or private mirror setups

  If you run Kubescape in environments without direct internet access, the new --grype-db-url flag lets you point image scans at an internal Grype DB mirror. Set this in your CI pipelines or operator configs now rather than patching environment variables or workarounds you may have hacked together previously.

cert-manager v1.20.0 introduces Gateway API ListenerSet support, Azure Private DNS integration, and promotes OtherNames to Beta, while fixing several ACME and DNS-related bugs.

• securityUpdate for DNS DoS vulnerability fix

  A moderate security issue allowed attackers to cause controller denial-of-service through malformed DNS responses. Update immediately if your cert-manager controllers are exposed to untrusted DNS servers or networks where DNS traffic could be manipulated.

• breakingContainer UID/GID changes affect security contexts

  Default container user changed from UID 1000 to 65532, and group from GID 0 to 65532. Review your pod security policies, security contexts, and file permissions if you've hardcoded these values or rely on root group access.

• enhancementEnable Azure Private DNS for internal certificate management

  New Azure Private DNS support allows DNS-01 challenges for private zones. Configure your Azure DNS issuer with private zone settings to manage certificates for internal services without exposing DNS records publicly.

OPA v1.14.1 is a patch release that reverts rule indexer changes causing lookup failures and fixes a plugin manager deadlock, while updating dependencies for security vulnerabilities.

• securitySecurity updates in dependencies

  This release includes Go 1.26.1 and updated dependencies that patch known vulnerabilities. Schedule this upgrade as part of your regular security maintenance cycle, especially if you're running OPA in production.

• breakingUpgrade immediately if using v1.14.0

  The rule indexer changes in v1.14.0 cause policy lookup failures for some configurations. Deploy v1.14.1 to restore reliable policy evaluation. The optimization will return in v1.15.0 with proper fixes.

• enhancementPlugin manager stability improved

  The deadlock fix resolves intermittent hangs during configuration operations. If you've experienced unexplained OPA freezes during plugin configuration, this release should eliminate those issues.

Kyverno v1.17.1 is a focused patch release fixing a CVE, multiple crash/panic conditions, race conditions, and image verification bugs that could silently misbehave in production.

• securityPatch CVE-2025-68121 now

  CVE-2025-68121 is fixed in this release. Details on scope are limited in the notes, but any CVE fix in an admission controller warrants immediate attention. If you're on v1.17.0, upgrade to v1.17.1 before doing anything else. Don't wait for your next maintenance window.

• breakingVerify your policy exclusion rules if you use empty lists

  A bug was fixed where an empty list in a policy exclusion would silently exclude ALL resources instead of none. If you have any ClusterPolicy or Policy with exclusion blocks, audit them now. If you were unknowingly relying on empty-list-as-exclude-all behavior (unlikely but possible), your policies will now behave correctly — meaning resources that were previously skipped will now be evaluated.

• enhancementImage verification with TSA and private registries is now reliable

  Two separate ivpol fixes land here: signed timestamp verification is now correctly enabled when a TSACertChain is provided, and private registry secrets in the Kyverno namespace are now used during background report scanning. If you've been seeing unexpected verification failures in background scans or with TSA-based signature policies, upgrade and re-run your report scans to get accurate results.